You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In both cases, internal.RetrieveToken is called, which then performs auto-detection of authType when not explicitly configured.
The problem now is, that some providers allow to perform token refresh without additional authentication. They're perfectly happy when the refresh token is valid and thus they successfully return a valid token even when the wrong authType is used. This leads to caching the wrong authStyle when a token refresh is performed BEFORE the first token exchange.
This can happen after the application is restarted while users still have valid refresh tokens (e.g. in the browser session). If the application then issues a token refresh before a new signin is performed, the errornous caching will cause ALL future token exchanges to fail as it will keep using the wrong authStyle.
I encountered this with Azure AD and the v2.0 issuer.
The text was updated successfully, but these errors were encountered:
codablock
added a commit
to kluctl/kluctl
that referenced
this issue
Apr 5, 2024
retrieveToken
is called in two situations:In both cases,
internal.RetrieveToken
is called, which then performs auto-detection ofauthType
when not explicitly configured.The problem now is, that some providers allow to perform token refresh without additional authentication. They're perfectly happy when the refresh token is valid and thus they successfully return a valid token even when the wrong
authType
is used. This leads to caching the wrongauthStyle
when a token refresh is performed BEFORE the first token exchange.This can happen after the application is restarted while users still have valid refresh tokens (e.g. in the browser session). If the application then issues a token refresh before a new signin is performed, the errornous caching will cause ALL future token exchanges to fail as it will keep using the wrong
authStyle
.I encountered this with Azure AD and the v2.0 issuer.
The text was updated successfully, but these errors were encountered: