-
-
Notifications
You must be signed in to change notification settings - Fork 78
feat: add DISABLE_REFRESH_TOKEN_NBF to disable refresh_token.nbf
#653
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,35 @@ | ||
| # Changelog | ||
|
|
||
| ## UNRELEASED | ||
|
|
||
| ### Changes | ||
|
|
||
| Even though not recommended at all, it is not possible to opt-out of the `refresh_token` nbf claim, and disable it. | ||
|
|
||
| By default, A `refresh_token` will not valid before `access_token_lifetime - 60 seconds`, but some (bad) client | ||
sebadob marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| implementations try to refresh `access_tokens` while they are still valid for a long time. To opt-out, you get a new | ||
| config variable: | ||
|
|
||
| ``` | ||
| # By default, `refresh_token`s will have an `nbf` claim, making them valid | ||
| # at `access_token_lifetime - 60 seconds`. Any usage before this time will | ||
| # result in invalidation of not only the token itself, but also all other | ||
| # linked sessions and tokens for this user to prevent damage in case a client | ||
| # leaked the token by accident. | ||
| # However, there are bad / lazy client implementations that do not respect | ||
| # either `nbf` in the `refresh_token`, or the `exp` claim in `access_token` | ||
| # and will refresh early while the current access_token is still valid. | ||
|
Comment on lines
+19
to
+21
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have the impression that refresh_tokens usually are opaque (which seems to be supported by at least one of the standards), so I am not sure nbf-checking of refresh-tokens usually would be related to a projects quality 😅 AT expiry though, should probably best be checked (at least for clients like oauth2-proxy)
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed.
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I made the refresh token just another JWT to give clients the possibility to inspect it and gain further information. Even though it's non-standard, it's an additional feature. |
||
| # This does not only waste resources and time, but also makes it possible | ||
| # to have multiple valid `access_token`s at the same time for the same | ||
| # session. You should only disable the `nbf` claim if you have a good | ||
| # reasons to do so. | ||
| # If disabled, the `nbf` claim will still exist, but always set to *now*. | ||
| # default: false | ||
sebadob marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| DISABLE_REFRESH_TOKEN_NBF=false | ||
| ``` | ||
|
|
||
| []() | ||
|
|
||
| ## v0.27.1 | ||
|
|
||
| ### Bugfix | ||
|
|
||
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Uh oh!
There was an error while loading. Please reload this page.