-
-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
state from argument does not match state restored from session error #482
Comments
This most likely means that for some reason two authentication flows are happening concurrently in your browser. The first flow has state s1, stored it in the session cookie and redirected your browser to keycloak. Before the flow completes another request comes in and creates a second flow with state s2 getting stored in the session cookie. When the first flow completes, Keycloak sends back s1 but your session cookie contains s2 and so the states do not match. Redirect based token refreshs do not work properly if multiple flows can happen at the same time. Server side token refreshs with a refresh token are far less prone to errors here. |
@bodewig Would it cause any security vulnerabilities if rather than generating state s2 the second time the same browser comes back to authenticate, state s1 was reused (from the encrypted session cookie)? |
I believe the OAuth2 best current practices recommend against re-using state parameters (can't seem to reach the ietf.org websites right now). You may want to read the threat model as well as the latest draft of https://datatracker.ietf.org/doc/id/draft-ietf-oauth-security-topics-15.html . Independent of security issues if there are two login flows happening in parallel you might get away with using the same |
@bodewig Thank you very much for the response! I am reading through the document which you kindly linked to but haven't yet found the part which recommends not re-using the state parameter. Another option would be to store not just one, but a small number of state parameters in the encrypted session cookie, so that parallel login flows can still succeed. You are right that if parallel login flows are allowed, the one which sets the cookie last will 'win' in terms of what URL the user is redirected to after one of the flows succeeds... but this is much better than stopping the user cold with an error page. One application which uses |
Sorry for the late reply. The document I linked sees I don't really see how accepting multiple parallel login flows by accepting different state values (or reusing existing ones) is going to help, though. Users ending up in a different place than they wanted to go are probably not happy either. Even if lua-resty-openidc somehow allowed multiple login flows originating from the same session you may still run into the problem of parallel flows starting without any session being present at all. I.e. multiple requests come in and neither contains a valid session token. In that case all of them start new flows and all of them end up with different WRT your browser sending multiple requests. Can you identify what is going on there? CORS preflight requests or browsers trying to load "/favicon.ico" spring to mind. |
I did a small workaround to improve UX a bit when this happens - instead of empty page with the error, users re-directed to the root path (and since keycloak has session cookie, user comes back as logged in instantly):
|
We experience the same when sessions are timed out. We have Keycloak configured as our IDP. |
Hi! I have a problem with "state from argument does not match state restored from session" error.
Environment
Keycloak image
Openresty image
Rocks installed for Lua 5.1
lua-resty-http 0.17.1-0 (installed) - /usr/local/openresty/luajit/lib/luarocks/rocks-5.1
lua-resty-jwt 0.2.3-0 (installed) - /usr/local/openresty/luajit/lib/luarocks/rocks-5.1
lua-resty-openidc 1.7.6-3 (installed) - /usr/local/openresty/luajit/lib/luarocks/rocks-5.1
lua-resty-openssl 0.8.22-1 (installed) - /usr/local/openresty/luajit/lib/luarocks/rocks-5.1
lua-resty-session 3.10-1 (installed) - /usr/local/openresty/luajit/lib/luarocks/rocks-5.1
Keycloak settings
nginx.conf
authentication.lua
Expected behaviour
When the session is expired (4 min idle), click on the logo to go to the main page, redirect to log in page, and after successful login redirect to the main page without problem
Actual behaviour
When the session is expired, click on the logo to go to the main page, redirect to log in page, and after successful login I see the following:
Openresty logs from docker
The following code can fix it but I'm not sure that it is a good idea
The text was updated successfully, but these errors were encountered: