-
-
Notifications
You must be signed in to change notification settings - Fork 507
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
OpenIddict RC1 no longer issues new refresh tokens by default #462
Comments
Why is this now the default instead of opt-in for this less secure method? |
Because it's a better default: it doesn't have the race condition risk inherent to the rolling tokens option and it puts less stress on the database (fewer refresh tokens are stored as the same entry is reused when extending the token lifetime). Yet, the security level is still very good because the refresh token can still be revoked at any time if the client or the authorization server think it may have been compromised. |
Thank you for the clarification @PinpointTownes makes sense! |
Have been resolved at your prompt, thank you |
took me a while to find this after my app broke... |
Haha, but fortunately finally solved |
Starting with
1.0.0-rc1
and2.0.0-rc1
, OpenIddict will no longer issue a new refresh token when sending agrant_type=refresh_token
token request.Why this change?
In the previous betas, OpenIddict used a non-configurable mode codenamed "rolling tokens": every time a refresh token was sent as part of a
grant_type=refresh_token
request, it was automatically revoked and a new single-use refresh token was generated and returned to the client application.This approach was great from a security perspective but had a few downsides. For instance, it didn't play well with heavily distributed client applications like MVC apps implementing transparent access token renewal (e.g using Microsoft's OIDC client middleware). In such scenario, if two refresh tokens requests were simultaneously sent with the same refresh token, one of them would be automatically rejected as the refresh token would be already marked as "redeemed" when handling the second request.
How does that work now?
By default, OpenIddict will now issue a single refresh token and manage its lifetime dynamically by extending its expiration date every time it's used in a refresh token request. This refresh token is not automatically revoked and can be used until it expires.
How do I fix my code?
If you use a standard-compliant OAuth2 client, no change should be required. Returning a new refresh token is not required and mainly an implementation decision. When no new refresh token is issued, clients are expected to keep using the refresh token used to create the original refresh token request.
https://tools.ietf.org/html/rfc6749#section-6
What if I prefer the old "rolling tokens" approach?
The previous default behavior is still supported but is now an opt-in option. To enable it, call
options.UseRollingTokens()
from the OpenIddict configuration delegate, inConfigureServices()
.The text was updated successfully, but these errors were encountered: