AWS ALB OIDC error "AuthInvalidStateParam" on about 5% of requests

Getting advice
1

Hi, I have an AWS ALB doing OIDC auth with Keycloak on a new service.
We went live this morning (whoop!) and have been seeing a very occasional problem (16 from 209 logins) where the user logs in and the ALB reports a 401 error when it should 302 on to the application.
The “text” of the error is AuthInvalidStateParam.
(URL like : GET https://site.uk:443/oauth2/idpresponse?state=QvOwWFKiVQwpWkED…%3D&session_state=496a1080…69c5&code=183ac…8ea-bff9b9e82c05 with …s added by me to make it short!)

If the user goes back to the root of the application (site.uk), they are redirected back to keycloak, which detects their existing session, passes them back to the ALB and they have a new state, same “session_state” and new “code” up to the first . and they are allowed in fine.

There are no errors being logged by Keycloak. There is only a single KC node at present, although we do have DNS_ping etc. set up to allow for scaling.

Any ideas??

2

OK, this is looking like a timing issue. If people get to the login page and take less than 5 mins to login, it’s OK. If they take more than 30, it gets a 401. (I haven’t yet tested intermediate durations but it must be somewhere nearer 10 minutes)
The Keycloak “Login timeout” or “Login Action timeout” doesn’t seem to help, that doesn’t appear to refresh the “state” that I’m assuming the ALB has decided is not valid any more. (I saw the “took too long to login” message and logged in and got the error)

3

Response from AWS :

by AWS Implementation the ALB will hold the state only for 900 seconds or 15 minutes. Any requests that return back to the ALB from the AUTH endpoint after this time period will not be processed as the state will no longer be active.

However, the Keycloak maximum time to login timeouts do not refresh the state from the ALB, so almost totally useless. Is this a bug??