Aut 1474 session cap reauth#137
Merged
Merged
Conversation
…icator refreshExpiresAt was computed with a *100 multiplier instead of *1000, making the refresh window appear roughly 10x shorter than the actual refresh token TTL returned by the auth API.
…token Keycloak caps a refreshed token's lifetime to whatever remains of the parent SSO session. Once a session is within 90 seconds of ending, isValid() treats every token as already expired, so each outgoing call triggers a refresh, and the refreshed token comes back capped just as short - producing a burst of refreshes tracking request rate until the session hard-expires. Authenticator.isSessionCapped() detects this case using the same 90s threshold as isValid(), and refreshOrRequestNewAccessToken() now falls through to a full re-authenticate when a refresh returns a session-capped token instead of returning it. AUT-1474
andy-radchenko
requested review from
AlexArcher and
bloy-smartling
as code owners
dimitrystd
approved these changes
Jul 6, 2026
Comment on lines
+151
to
+152
| // refreshExpiresAt must be computed with a *1000 (not *100) conversion, | ||
| // so it should still be refreshable just before the real TTL elapses. |
Contributor
There was a problem hiding this comment.
I propose to remove this comment because it makes sense only in the scope of this PR.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ksoloviov-smartling
approved these changes
Jul 6, 2026
| { | ||
| return accessToken; | ||
| } | ||
| log.info("Refreshed token has a session-capped lifetime ({}s); re-authenticating.", authentication.getRefreshExpiresIn()); |
Contributor
There was a problem hiding this comment.
minor: again I would put debug here or moved to debug log message below
dimitrystd
approved these changes
Jul 6, 2026
AlexArcher
approved these changes
Jul 7, 2026
andy-radchenko
added a commit
that referenced
this pull request
Jul 7, 2026
PR #137 was squash-merged into master as commit 5c1565f with subject "Aut 1474 session cap reauth (#137)", which does not match the conventional-commits format the release pipeline requires. As a result, conventional-commits:validate found no releasable commit type and CircleCI silently skipped the version bump and deploy. This empty commit restores a conventional "fix:" subject on master so the next CI run picks up a patch release, deploying the changes already merged in #137.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AUT-1474: Re-authenticate instead of returning a session-capped refreshed token
Problem
Background: SSO session max lifespan
Every access/refresh token pair issued by Keycloak is tied to an underlying SSO session, and that session has a max lifespan (our Keycloak realm has this set to 12h). A refresh token can be used to mint new access tokens repeatedly, but only for as long as its parent session is alive — Keycloak will never issue a refreshed token that outlives the session's max lifespan, no matter how large the client's configured refresh-token TTL is. So as a session approaches its 12h cutoff, each successive refresh returns a token whose lifetime is capped to "whatever time is left on the session," which keeps shrinking toward zero rather than resetting to the normal TTL.
What changed
This behavior is new with our Keycloak 26 migration — Keycloak 1.9 did not cap a refreshed token's lifetime to the remaining session time, so
Authenticatornever had to deal with a refresh returning a shorter-than-usual token. Keycloak 26 does cap it, which exposes a gap inAuthenticator's refresh handling:Once a session gets within 90 seconds of ending,
Authenticator.isValid()treats every access token as already expired, so each outgoing call triggers a refresh — and the refresh comes back capped just as short. This repeats on every call for as long as the session has under 90 seconds left, producing a burst of refresh calls that tracks request rate until the session hard-expires.refreshOrRequestNewAccessTokenonly fell back to a full re-authenticate when the refresh call threw — never when the refresh succeeded but returned a session-capped token, so this refresh-loop had no escape hatch.We're already observing this in the wild: a number of services are spamming the auth service with heavy bursts of refresh calls as their sessions near the 12h mark, matching this exact pattern.
While fixing this, we also found
getAccessTokenInternalandrefreshAccessTokencomputedrefreshExpiresAtusinggetRefreshExpiresIn() * 100instead of* 1000(theexpiresAtline right above each uses* 1000correctly). This made the refresh-token window appear roughly 10x shorter than it actually is.This is the
java-api-sdkcounterpart to AUT-1473, which addresses the same issue inauthentication-api-sdk.