Hello,
A use case I have noticed is:
1) User tries to use the web application. Say
http://www.app.com
2) The application redirects you to the login page
http://www.keycloaklogin.com/auth/realms/realm-name/protocol…
3) Before logging in, user bookmarks this page.
4) User logs in and then gets redirected to
http://www.app.com
5) All works fine up till now
Now user logs out, closes browser etc.
Now user starts the workflow from bookmarked page (
http://www.keycloaklogin.com/auth…)
1) User sees a login page
2) User logs in
3) User gets redirected to
http://www.app.com?state=…
4) At this point this below code:
https://github.com/keycloak/keycloak/blob/master/adapters/oidc/adapter-co...
is executed and user sees a 400 page due not having OAuth_Token_Request_State . So far you
can argue that, well we didn’t want user not to have OAuth_Token_Request_State in the
first place, but the next step that user can do is:
5) User goes to
http://www.app.com page and then gets a redirect back to the login
page
http://www.keycloaklogin.com/auth/realms/realm-name/protocol…
6) Keycloak sees that user is already logged in so redirects back to the same page
7) User now can see
http://www.app.com<http://www.app.com/> due to the
OAuth_Token_Request_State created in step 5
So to me it seems like this check is obsolete, however I’m curious whether this has a user
case or prevents anything. If not, then it might be worth fixing at the step 4 where user
actually gets to see the page (or re issue OAuth_Token_Request_State ) instead of showing
400 page.
Thanks,
Sarp