Keycloak - Parallel refresh token

[GFlo69]

Hi,

In the wiki documentation you talk about management by lock system of parallel requests for tokens by the refresh token.

Today, I'm working on a single Apache instance which is connected to a keycloak IDP. The keycloak is configured to accept the use of a refresh token once (Revoke Refresh Token active and the value of Refresh Token Max Reuse at 0)

At my level, I cannot demonstrate the correct functioning of the locks.
My example is the following:
4 simultaneous calls to resources under “AuthType openid-connect” protection

• The first refresh token request goes well on my keycloak instance
• The other three are KO because they always use the same refresh token.

Any subsequent refresh token calls are KO because, in my opinion, the cache of the Apache instance could not be refreshed with the new refresh token.

note: as a reminder that in the continuous refresh token situation, keycloak provides a new refresh token for each request

The only possibility I have, to date, is to configure my keycloak instance to accept the use of 8 refresh tokens. This configuration in terms of security is a global configuration at the level of the keycloak kingdom and which therefore opens up security risks in the event of interception.

Do you have any ideas to share with me to validate the expected operation?

My conf :

    OIDCCryptoPassphrase xx
    OIDCCookie NameCookie
    OIDCSSLValidateServer Off
    OIDCProviderMetadataURL https://keycloak.mycompanytest.com/auth/realms/mycompany-app-dev/.well-known/openid-configuration
    OIDCScope "openid email profile"
    OIDCClientID myapp-proxy
    OIDCClientSecret xx
    OIDCRedirectURI https://myapp.dev.mydomain.com/login/redirect_uri
    OIDCRefreshAccessTokenBeforeExpiry 60
    OIDCSessionInactivityTimeout 3600
    OIDCPKCEMethod S256
    OIDCRemoteUserClaim preferred_username
    OIDCPassUserInfoAs "claims"
    OIDCPassClaimsAs headers
    OIDCClaimPrefix "mycompany-"
    LogLevel debug
    OIDCOAuthVerifyJwksUri https://keycloak-dev.mycompanytest.com/auth/realms/mycompany-app-dev/protocol/openid-connect/certs
    OIDCCacheEncrypt On
    <Location />
            AuthType None
            Satisfy Any
            Require all granted
            Allow from all
    </Location>
    <Location /login>
            AuthType openid-connect
            OIDCUnAuthAction auth
            Satisfy All
            Require valid-user
            Redirect temp /login https://myapp.dev.mydomain.com/
    </Location>
    <Location /api/>
            AuthType openid-connect
            OIDCUnAuthAction 401
            Satisfy All
            Require valid-user
    </Location>

[zandbelt]

it appears indeed that it is not working as documented; the only thing you can do is to set the OIDC_PARALLEL_REFRESH_NOT_ALLOWED environment variable so the subsequent calls with the same refresh token will fail but will not request new refresh tokens that may or may not be written into the session; i.e. treat a single Apache server (with multiple processes on the same machine) as a cluster

depending on what you're trying to do with the access token, it may be better to issue longer lived access tokens and/or not use OIDCRefreshAccessTokenBeforeExpiry at all

[zandbelt]

We are re-considering our approach wrt. parallel token refresh grant handling: would you be able to test from a branch or could you so so with a build provided by us?

[GFlo69]

Hi,
If you provide me with a RHEL7 rpm version I could test it

Note : your approach of generating errors by disabling the parallel calls capability cannot be implemented on my side (too much impact).
Using longer-lived access tokens simply postpones the problem. In addition, the access tokens being in principle highly sensitive, this strategy is subject to too high a risk in my opinion.

[zandbelt]

we'll work on a RHEL 7 test version; so what are you using the access token for?

[zandbelt]

please try https://www.mod-auth-openidc.org/downloads/mod_auth_openidc-2.4.15.2dev-1.el7.x86_64.rpm

[GFlo69]

Hi,

please try https://www.mod-auth-openidc.org/downloads/mod_auth_openidc-2.4.15.2dev-1.el7.x86_64.rpm

This morning's tests which are OK. Thanks
I notice a single refresh token at the IDP level despite the parallel calls

we'll work on a RHEL 7 test version; so what are you using the access token for?

I use the access token to
Provide identity and access information to the application front under the protection of the Apache module (FRONT)
Provide identity and rights information at the back of the application (not necessarily under the protection of the module you are offering)

In addition, the access token is used by the application to query other APIs on behalf of the user (OIDC scopes allowing all user rights for all applications of the necessary perimeter)

[GFlo69]

Hi,
I have just detected that on the delivered version I have an error on the cjose library which appears.

Please note that I am in cjose version cjose-0.6.1.5-1

[auth_openidc:error] oidc_util_jwt_create: oidc_jose_compress failed: [src/jose.c:838: oidc_jose_zlib_compress]: deflate failed: -5, referer:

[zandbelt]

we also ran into this as we were developing CI tests for this scenario; it will be fixed in the upcoming release

[GFlo69]

Hi,

Do you have an estimated date for the release of the new version correcting the above anomaly?

[zandbelt]

it is in https://github.com/OpenIDC/mod_auth_openidc/releases/tag/v2.4.15.3