Performance problem in oidc_refresh_token_grant

[mschmidt72]

Hi OpenIDC team + community,

Unfortunately, our hosting provider upgraded last Sunday to mod_auth_openidc version 2.4.14.4 which causes now some troubles in a clustered environment (with 4 nodes).

The problem occurs in oidc_refresh_token_grant in the very beginning

oidc_debug(r, "enter");

oidc_cache_mutex_lock(r->pool, r->server, c->refresh_mutex);

/* get the refresh token that was stored in the session */
refresh_token = oidc_session_get_refresh_token(r, session);
if (refresh_token == NULL) {
oidc_warn(r,
		"refresh token routine called but no refresh_token found in the session");
goto end;
}

// check existing refresh is going on
oidc_cache_get_refresh_token(r, refresh_token, &value);

Between oidc_debug(r, "enter"); and oidc_cache_get_refresh_token(r, refresh_token, &value); we can have a few seconds or more than one minute - we can see this in the debug mode when we have

2024-07-25 14:05:52.751350 ... oidc_refresh_token_grant: enter
2024-07-25 14:07:21.720045 ... oidc_cache_get: enter : eyJ0eX...

after that the refreshing of the token worked smoothly (so in the end the access was even granted after 90s of processing).

So, it looks like a performance problem either in
oidc_cache_mutex_lock or refresh_token = oidc_session_get_refresh_token(r, session)

I know that upgrading to a newer version is the preferred way (also for me) - unfortunately, our hosting provider is not that flexible and it takes at least one month until a new version will be deployed:

Therefore a short question - and may be you have an answer ad-hocly from your experience:
Do you have any idea why oidc_cache_mutex_lock or refresh_token = oidc_session_get_refresh_token(r, session) can have a performance problem in a clustered hosting solution with shared memory (as cache solution) and whether this can be improved by either a configuration setting (e. g. cache settings in OIDC) or Apache setting (or e. g. would Apache restart a solution, too)?

Thx for your support.

Martin

[zandbelt]

I cannot explain where the delay comes from, it seems to me that the culprit is oidc_cache_mutex_lock but I don't remember such an issue being reported before. As a workaround you may change the config to not rely on the refresh token grant by removing OIDCUserInfoRefreshInterval and/or OIDCRefreshAccessTokenBeforeExpiry.

[mschmidt72]

That was fast - thank you very much.

I will check these 2 settings OIDCUserInfoRefreshInterval / OIDCRefreshAccessTokenBeforeExpiry to understand the implications of a removal as we still want that the token is refreshed from time to time as otherwise I guess the session times out - but I'm not so deep in the module. For now thank you very much - I will follow-up on your hints and will let you know.

[zandbelt]

no, the session won't timeout, see: https://github.com/OpenIDC/mod_auth_openidc/wiki/Sessions-and-Timeouts

[mschmidt72]

Ok - understood. In the meanwhile we tried this out.

We used OIDCRefreshAccessTokenBeforeExpiry in the configuration before - but removing this setting (and because we have also not set OIDCUserInfoRefreshInterval) I can confirm that oidc_refresh_token_grant is bypassed - the session is handled than by the module directly and we don't run in this strange problem.

This fixes the problem short term - until we can upgrade to the newer version.

So, thank you very much for your hints and (++again) fast support on this.