Skip to content
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

Closed
kevinchalet opened this issue Sep 18, 2017 · 7 comments
Closed

OpenIddict RC1 no longer issues new refresh tokens by default #462

kevinchalet opened this issue Sep 18, 2017 · 7 comments
Milestone

Comments

@kevinchalet
Copy link
Member

Starting with 1.0.0-rc1 and 2.0.0-rc1, OpenIddict will no longer issue a new refresh token when sending a grant_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.

The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client.

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, in ConfigureServices().

@kevinchalet kevinchalet added this to the 1.0.0-rc1 milestone Sep 18, 2017
@Bartmax
Copy link
Member

Bartmax commented Sep 18, 2017

Why is this now the default instead of opt-in for this less secure method?

@kevinchalet
Copy link
Member Author

kevinchalet commented Sep 18, 2017

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.

@Bartmax
Copy link
Member

Bartmax commented Sep 18, 2017

Thank you for the clarification @PinpointTownes makes sense!

@DaLiangLee
Copy link

Have been resolved at your prompt, thank you

@sir-boformer
Copy link

took me a while to find this after my app broke...

@DaLiangLee
Copy link

Haha, but fortunately finally solved

@amr3ssam

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants