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
There are situations where an OAuth client may be maintaining multiple copies of a refresh token, such as when the client is implemented in a clustered fashion. If the tokens aren't distributed in an immediately consistent way, and refreshing tokens are configured for single use, one client node can refresh an access token, receiving a new refresh token, allowing for a window during which the other nodes' refresh tokens are invalid. If one of those nodes attempts an access token refresh, it will receive an error and the session will be revoked. This requires re-authentication to establish a new session, which is especially difficult when the client is a third-party client operating in an offline_access mode without the authorizing party present.
Solution
All for a grace period for single-use refresh tokens, during which the previous refresh token is still considered valid. When performing a refresh with an old refresh token, the same new refresh token will be returned.
This grace period should be settable as a tenant-wide default value, and be overridable at the application.
The grace period should default to zero, and have a reasonable maximum value.
Alternatives/workarounds
None
Documentation
Release notes, we should mention the length of the refresh token will increase from 54 to 64 characters. (40 bytes to 48 bytes) I don't expect this to impact anyone, but if anyone was making assumptions based upon the length of this opaque token, that assumption will no longer be correct.
Added UI config for Application and Tenant JWT configuration, grace period for one time use, and revocation on token re-use
Update to the Application and Tenant API for JWT configuration, grace period for one time use
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
The text was updated successfully, but these errors were encountered:
Support a refresh token grace period
Problem
There are situations where an OAuth client may be maintaining multiple copies of a refresh token, such as when the client is implemented in a clustered fashion. If the tokens aren't distributed in an immediately consistent way, and refreshing tokens are configured for single use, one client node can refresh an access token, receiving a new refresh token, allowing for a window during which the other nodes' refresh tokens are invalid. If one of those nodes attempts an access token refresh, it will receive an error and the session will be revoked. This requires re-authentication to establish a new session, which is especially difficult when the client is a third-party client operating in an
offline_access
mode without the authorizing party present.Solution
All for a grace period for single-use refresh tokens, during which the previous refresh token is still considered valid. When performing a refresh with an old refresh token, the same new refresh token will be returned.
This grace period should be settable as a tenant-wide default value, and be overridable at the application.
The grace period should default to zero, and have a reasonable maximum value.
Alternatives/workarounds
None
Documentation
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
The text was updated successfully, but these errors were encountered: