The "state" is just meant to provide more security. See OAuth2 / OpenID
Connect specification around this.
For example if we don't require OAuth_Token_Request_State cookie and we
won't mandate "state" check, then attacker just can pass you somehow URL
with his own code "http://www.app.com?code=attackers-own-code" and you
will be logged automatically to the application with an attacker identity.
BTV. If the default behaviour is not suitable for you, you can probably
configure error handling in web.xml of your application and handle 400
error with the state cookie message to automatically do another redirect
to your application. Then users won't see any error page.
Another option is to just instruct your users to not bookmark login page ;)
On 06/10/16 08:05, Sarp Kaya wrote:
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
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:
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
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.
keycloak-user mailing list