-
Notifications
You must be signed in to change notification settings - Fork 7.3k
After migrating to newer Keycloak, token refreshes using inherited offline sessions return access tokens with invalid exp value #39021
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Update from @ynojima: Testing with Keycloak 26.0 returns the following error instead of a token response with an invalid
It still can't handle valid offline sessions created by RH-SSO 7.4, but I'm leaving this note here to avoid confusion when reproducing the issue. |
Closes keycloak#39021 Signed-off-by: rmartinc <rmartinc@redhat.com>
The initial problem was introduced very long ago in keycloak 14 (this commit) so I think that the issue cannot be tested in the migration. I suppose the user was using a previous version before using RH-SSO 7.6 and the offline sessions were moved from version to version several times. Nevertheless I was able to create an ad-hoc test removing the notes in the server. |
Closes keycloak#39021 Signed-off-by: rmartinc <rmartinc@redhat.com> (cherry picked from commit 11b032f)
Closes keycloak#39021 Signed-off-by: rmartinc <rmartinc@redhat.com>
Closes keycloak#39021 Signed-off-by: rmartinc <rmartinc@redhat.com> (cherry picked from commit 11b032f)
Closes keycloak#39021 Signed-off-by: rmartinc <rmartinc@redhat.com> (cherry picked from commit 11b032f)
Closes keycloak#39021 Signed-off-by: rmartinc <rmartinc@redhat.com>
Uh oh!
There was an error while loading. Please reload this page.
Before reporting an issue
Area
oidc
Describe the bug
This is for migration from RH-SSO 7.6 to Keycloak 24.0.
After they migrated their production environment to Keycloak 24.0.z, they attempted to refresh a token for an offline session migrated from RH-SSO, and the following was returned as the token response.
As you can see, the
expires_in
value is negative, which is invalid.The value is derived from the
exp
claim of the access token, and the issued access token has anexp
value of157680000
(1974-12-31 00:00:00 UTC), which is also invalid.The
exp
value of the access token is, roughly speaking, calculated as (session start time) + offlineSessionMaxLifespan.In this realm,
offlineSessionMaxLifespan
is set to 157680000 seconds (5 years), so it appears the result is from 0 + offlineSessionMaxLifespan.In other words, for some reason, the session start time is being treated as 0.
The following is the code that likely considers the session start time to be 0:
keycloak/server-spi/src/main/java/org/keycloak/models/AuthenticatedClientSessionModel.java
Lines 36 to 40 in 81aa588
For recently created sessions, it seems that a note called
startedAt
is added to the offline session. However, in the customer's case, the session was created with an older version, so it appears that thestartedAt
note is not included [1].Therefore,
clientSession.getStarted()
in the following code becomes0
, leadingSessionExpirationUtils.calculateClientSessionMaxLifespanTimestamp()
to return0
+offlineSessionMaxLifespan
, which caused the access token's exp to be157680000
.keycloak/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java
Lines 1039 to 1042 in b9bd644
Version
24.0.z
Regression
Anything else?
Consideration
Is it possible that if
clientSession.getStarted()
is 0, then we use theiat
of the offlineToken, which was sent to the endpoint? We should make sure to setstartedAt
, so that it is correctly set in the DB for the next time.Alternative is to update all client sessions at startup and set
started_at
in case that it is not set. But not sure if still possible and it can take long time as bulk updates could be long and people can have millions of sessions in the DB...Testing note
There is
AbstractMigrationTest.testOfflineTokenLogin()
for testing migration of offline-token from the older version. Currently it is tested from Keycloak 19 or earlier, which I am not 100% sure if can be used to simulate the issue (as the issue is for migration from RH-SSO 7.6, which is Keycloak 18), but maybe yes. Hopefully we can maybe add calling the "introspection endpoint" to thattestOfflineTokenLogin()
to doublecheck if access-token has correctexp
times (as introspection for such access-token would probably fail).The text was updated successfully, but these errors were encountered: