Refresh token issued before the client session started

[Niko Köbler]

Hi folks,

I'm encountering a strange behavior and I don't know where it might come from. I'm not primarily looking for a technical explanation, but I want to know _why_ this might happen:

During a refresh_token grant, I get the error message invalid_token and the detail message refresh token issued before the client session started. This is coming from the TokenManager.validateToken(...) method. So far, this is clear to me.
But how can this functionally happen? Might this be an error from the client implementation?

Yet, I have never encountered this error, only in one environment, this occasionally happens. And I don't know why.
Only SSO session idle/max are configured, no deviating client session times, not globally, not in the specific client.

Has anybody any ideas about this? Any solution approaches?

Thanks

[Alexander Schwartz]

Hi Niko,

Those times on the refresh token are created on the server side. 

possible idea: Clocks are not synchronized between Keycloak nodes. Note that JsonWebToken.isIssuedBeforeSessionStart() is allowing for a time difference of 1 second. Using modern time sync / NTP, the time should be synchronized well below one second. 

The recent versions of Keycloak should log with their events a lot of details including the user session ID. Collecting the whole history of a user session up until this point might reveal additional information. 

Best,

Alexander 

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/f6e1bc87-6617-49e0-a280-c6239b0b5310n%40googlegroups.com.

--

Alexander Schwartz, RHCE

He/Him

Principal Software Engineer, Keycloak Maintainer

Red Hat - Germany remote

asch...@redhat.com   

Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany 
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross

[Niko Köbler]

Hi Alexander,

thanks for your response.

We already investigated the time sync of the servers and couldn't observe any difference (2 pods in K8s, thus configured completely identically).

Yet, the success events are not logged/recorded, so we only have the error event(s). We will try to log also the success events and see if we can deviate anything from this extended data.

Cheers

- Niko