Handling OpenID session timeouts / stale refreshToken

[dasantonym]

I have an instance of Directus running with Keycloak OpenID authentication enabled. Everything is working fine, except that there is a problem with expired tokens being stored in the DB.

Here's what's happening:

• I log in initially using the Keycloak provider and the auth_data for the user is set using the refreshToken from Keycloak.
• There is a session timeout of 30 minutes set for Keycloak which invalidates tokens.
• After 30 minutes of inactivity, I log in again and Directus uses the refreshToken from the DB, which then fails.
• The invalid token is kept in the DB and every subsequent attempt of logging in fails.

I added code to the refresh(user) function in the OpenIDAuthDriver class that removes the stale auth_data, if an invalid_grant error occurs and now I no longer have this problem.

I am not sure if I've got something set up wrong here or if this is a bug... Should this go into an issue or should I do something differently?

[aidenfoxx]

There is code that should handle this, but it's possible there is an edge case with Keycloak.

When attempting to login with an invalid refresh token, the provider should trigger an "invalid_grant" error which is caught and re-triggers a login with a "prompt=consent" parameter, which should in theory trigger a full re-authorization which should return a new refresh token.

https://github.com/directus/directus/blob/main/api/src/auth/drivers/openid.ts#L331

I guess Keycloak isn't returning a refresh token on prompt. A temporary fix would be to increase the keycloak lifetime on refresh tokens by increasing the idle limits.

[adussarps]

Hello @dasantonym , I'm running into the same issue as you are.

Could you possibly provide the workaround that you implemented on the OpenIDAuthDriver?

Best

[dasantonym]

Hi @adussarps , sure, this is the commit: motionbank@c97fb0d

[dasantonym]

Hi @aidenfoxx, I'd like to raise this issue again since I think this is not really addressed so far.

The problem is, that once your refresh token expires, it still remains in the DB. The login attempt fails with an "invalid grant" error, but there is no code that clears the stale auth_info from the database.

This is why I added the code above, but shouldn't this generally be the behaviour on an expired refresh token?

[aidenfoxx]

There is code to handle this case here. When an invalid token is detected, we retry authentication with a "prompt=consent" parameter to trigger the consent flow, which should return a new "refresh_token" (replacing the old token).

When creating the system this was validated as working with Keycloak, but of course, things can change, or you may have a different configuration. Reading the Keycloak docs, it appears the "consent" flow may not be triggered if you don't have "Consent Required" enabled. I would suggest enabling that and seeing if the flow works correctly. Alternatively, you could try enabling the "always-refresh-token" configuration in Keycloak as a workaround.

As for modifying the code: it's tricky. To remove the "refresh_token" without first getting a new one makes the system inherently less secure, as it removes the ability to remotely lock out your Directus account by revoking access on the provider side.

EDIT: After re-reading the thread I'm basically just repeating myself here. As mentioned, making a change has potential security implications that you'd have to discuss with the core team.

[dasantonym]

Thanks for the clarification and sorry for the repetition. It totally makes sense and I was a bit too hasty here and should have checked this out more thoroughly.