The nature of cookie based sessions and state parameter handling in OAuth2 Auth Code Flow expose a problem, when new browser session is started with multiple tabs trying to concurrently open several links on a "Secure Server" ( our Oauth2 confidential client).
When the browser is started it discards all previous session cookies. Multiple tabs may be opened at once by the browser in case of crash recovery, or by the user, from bookmarks folder or history.
In such cases all tabs will simultaneously send unauthenticated requests to Secure Server. Each request will start a new session and a new Auth Code Flow, with new state param, that will be saved in this session.
All Secure Server's redirect-to-Identity-Provider responses will bear a session cookie with the same name, but a different value. They will overwrite each other in browser, and only the last one will be kept by browser as the Session ID.
Each tab will continue down the Authorization Code flow to Identity-Provider login page and back to Secure Server, bearing different state param, but same session cookie (set by the last tab).
Those state params were saved in now lost sessions and cannot be verified. State param validation failure is forbidden, and error 403 is issued.
The result is that all tabs except the last one end on 403 page.
Are there any known practices to handle this problem ?
Thanks
Interesting question and in most cases this will be a challenge to get working and will be a combination of support from:
COMPLIANT LIBRARY
The oidc-client-js library demonstrates the required technique, via a state store per redirect. Last man will then win, as you say, without any errors for end users.
It is one of those usability areas where a client side Web UI has greater control than redirects triggered by server side web stacks, such as ASP.Net / Spring Boot.
VISUALISING THE BEHAVIOUR
Run my Online OAuth SPA and trigger 2 redirects, but do not log onto either. Then browse to this URL and look in the browser's local storage tools at the redirect state:
The last man to win will then update the user store, whose data is used for subsequent renewal redirects and token validation (note that my SPA stores the actual tokens in memory rather than in this user store):
NON COMPLIANT AUTHORIZATION SERVER
Unfortunately my Online Authorization Server (AWS Cognito) does not like receiving 2 logins like this and the second login fails.