What's new?
All the changes introduced in this release can be found on GitHub, but here's a recap of the most important ones:
OpenIddict now supports response type permissions
In previous versions, the response_type
values an application was allowed to use were always inferred from the grant types. For instance, if a client was granted the authorization_code
grant type permission, it was automatically allowed to use response_type=code
(that corresponds to the "pure" authorization code). If it was granted the implicit
permission, it was also allowed to use response_type=id_token
and depending on its type (confidential or public), response_type=id_token token
and response_type=token
.
While convenient, this approach lacked granularity. In OpenIddict 3.0 beta6, this mechanism is replaced by explicit response type permissions. Response type permissions are granted exactly the same way as the other permissions:
1 | await manager.CreateAsync(new OpenIddictApplicationDescriptor |
Introducing response type permissions was also a good opportunity for removing the OpenIddict-specific hybrid
client type, that was used by confidential clients that also wanted to retrieve an access token directly from the authorization endpoint. In beta6, the hybrid
type is no longer supported and must be replaced by explicit Permissions.ResponseTypes.CodeIdTokenToken
or Permissions.ResponseTypes.CodeToken
permissions.
Users who have many clients to migrate can use this script to infer the "best" response type permissions based on the already allowed grant types:
1 | using System; |
The hybrid flow is no longer enabled when enabling both the authorization code and implicit flows
In previous versions, the hybrid flow was automatically enabled when enabling both the authorization code and implicit flows. In beta6, it now must be enabled explicitly, like the other flows:
1 | services.AddOpenIddict() |
Rolling refresh tokens are now enabled by default and allow for a configurable leeway
In 3.0 beta6, refresh tokens were revamped and the following changes were made:
The rolling refresh tokens mechanism now allows for a small leeway to avoid revoking entire token chains when concurrent requests are received (by default, it is set to 15 seconds but can be changed using
OpenIddictServerBuilder.SetRefreshTokenReuseLeeway()
).The rolling refresh tokens mechanism no longer revokes previously issued tokens, it just marks refresh tokens as redeemed when they are used.
Rolling refresh tokens are now enabled by default to make OpenIddict compliant with the OAuth 2.0 best current practices, that require implementing either rotation or sender-constrained tokens. Developers who prefer disabling rolling refresh tokens can do so by calling
OpenIddictServerBuilder.DisableRollingRefreshTokens()
.The refresh token lifetime extension mechanism was removed: even when rolling refresh tokens are disabled, a new refresh token will now be generated and returned for each refresh token request, which guarantees that the client application always gets a refresh tokens (and subsequent access tokens) containing the latest claims.
The EF Core and EF 6 entities now use DateTime
instead of DateTimeOffset
Due to incomplete support in the Oracle MySQL and Npgsql Entity Framework providers, the EF Core and EF 6 entities no longer use DateTimeOffset
. Developers migrating to OpenIddict 3.0 beta6 will need to add a migration to move from DateTimeOffset
to DateTime
.
Proof Key for Code Exchange (PKCE) can now be enforced globally
Previous versions of OpenIddict 3.0 already allowed making PKCE mandatory per-client, but in beta6, there's now a global option:
1 | services.AddOpenIddict() |
Tokens no longer contain a jti
claim
To make tokens lighter, a jti
claim is no longer generated and persisted in the tokens generated by OpenIddict 3.0 beta6.
Special thanks to Johann Wimmer for his great contribution to the tests projects, that are now compiled with nullable reference types enabled!