OIDC Parallel Refresh token requests

[Hykes888]

Version 2.4.15.3

Issue Details

#1 - In the beginning of the session, a request for token is made by the user to the Apache server. The Apache server then responds back in 5 seconds with an OIDC session "token1". As long as the next request is within 60 seconds from the last request Apache server will not trigger a token refresh call to the IDP.

#2 - A series of async calls is triggered by the browser

• In this example, request#2 takes 5 seconds to finish, while request#3 takes 150 seconds and request#4 took 10 seconds.
• Since request#3 took 150 seconds browser will set a new token (token#2)

#3 - When Request#5 is triggered it inherits the value from request#4 and the OIDC validation session to Token#3 in the browser

#4 - As request #3 gets fulfilled after 150 seconds, OIDC session is re-set to Token 2. This means Request 6 at this point will send to Token 2 leading to an anomaly where stale token is pushed back into the circulation, which starts triggering HTTP 400 bad requests.

In general there is a race condition when refresh token is called and sequence of calls coming in.

[zandbelt]

there are limitations around refresh token requests indeed see also https://github.com/OpenIDC/mod_auth_openidc/wiki/Known-Limitations#parallel-refresh-token-grants; in general I would assess the need for OIDCRefreshAccessTokenBeforeExpiry and/or OIDCUserInfoRefreshInterval because it often turns out that people enable it for no good reason or the wrong reason; the best setup is the default which requires no refresh at all...

[edit] using non-rolling refresh tokens is a way to avoid the race condition if you actually need OIDCRefreshAccessTokenBeforeExpiry and\or OIDCUserInfoRefreshInterval assuming the OP is under your control...

[Hykes888]

Thank you for the quick answer

We are revisiting the configuration and seeing how we can remove refresh token as we are using the refresh token call to update the OP session as this is the source of truth, is there another method to use to keep the OP session in sync with user activity other than using OIDC Refresh Token or OIDC User Info calls based on user activity?

We also noticed when these race conditions appear using the refresh token its noticed that the Apache server runs out of resources. The worker threads spike and cause slowness to no response. A restart is needed to bring the environment back. We found this discussion and wonder if this would be related. - #1228

[zandbelt]

keeping an OP session "updated" (for whatever that definition means) is something that is product specific and not related to any standardized protocol

I'm not sure about the resource exhaustion per se, but having multiple requests that last 150 seconds for whatever external reason (the origin server or the OP may be slow?) may easily lead to this result and I'd look to remove that bottleneck