Earlier today, I released the RC1 version of the OpenID Connect server middleware, alongside the other aspnet-contrib packages.
This version – the latest before RTM – includes a few design changes that will directly impact your own code:
Starting with RC1, ASOS no longer includes a built-in claims mapping feature, which means claims like
ClaimTypes.Role are no longer mapped to their OpenID Connect/JWT equivalents (
Concretely, if you have code like that in your authorization provider class, you should update it to use the OpenID Connect claims instead of the legacy claims exposed by the static
var identity = new ClaimsIdentity(OpenIdConnectServerDefaults.AuthenticationScheme);
// Configure ClaimsIdentity to use the OpenID Connect claims instead of
You're actually free to keep using the
ClaimTypes claims, but the OpenID Connect server middleware will throw an exception if you don't (at least) add the
InvalidOperationException: The authentication ticket was rejected because it doesn't contain the mandatory subject claim.
If you use the JWT bearer middleware, you'll also want to disable its own claims mapping feature and update the token validation parameters to use the dedicated JWT name/role claims:
In the same vein, the introspection middleware was updated to use
role as the default claim types (instead of
To support multi-valued authentication properties containing spaces, we had to tweak the token format to store these complex properties as JSON strings.
Unfortunately, this change makes old authorization codes, access and refresh tokens incompatible with the new format (and vice versa). In practice, this means that you can't use tokens issued by ASOS RC1 with old versions of the validation middleware (or with the OpenID Connect server middleware itself): such tokens will be automatically rejected.
To make sure everything runs smoothly, migrate to the latest version of the validation middleware (
Starting with RC1, ASOS now includes a "degraded mode" that allows you to use it without registering a signing key or a signing certificate (ephemeral or not) if you don't opt for JWT access tokens and don't use the implicit or hybrid flows.
AddCertificate() is no longer mandatory if you use non-interactive flows like password or client credentials AND the default access token format.
And voilà, that's all. For the complete changelist, feel free to take a look at the GitHub issues page.
No new release candidate is currently planned, which means the next version will be the RTM package.
The next (and last) step is to rework the XML documentation. Depending on how well this work item goes, the RTM bits should be published at the end of the month or in April. If you're willing to contribute to this stask, don't hesitate to ping me.