Introducing localization support in OpenIddict 3.0 beta3

Development

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:

The core, server and validation features now offer built-in localization support

As announced in a previous post, OpenIddict was fully updated to use the .NET Platform localization extensions to return localized error descriptions and validation messages, which will be particularly useful in multilingual projects like Orchard Core.

At the time of writing, OpenIddict 3.0 beta3 comes with English and French resources, but additional languages will likely be added in the next versions.

To enable localization support in ASP.NET Core, simply register the request localization middleware (ideally, put it at the top of your Configure(IApplicationBuilder app) method):

1
2
3
4
5
6
app.UseRequestLocalization(options =>
{
    options.AddSupportedCultures("en-US", "fr-FR");
    options.AddSupportedUICultures("en-US", "fr-FR");
    options.SetDefaultCulture("en-US");
});

ASP.NET 4.x users can enable globalization support in web.config by setting uiCulture and culture to auto. Alternatively, ASP.NET 4.x and OWIN users can use Owin.Localization, which is a backport of the ASP.NET Core middleware.

Conversely, developers who don't need localization support and prefer keeping their deployments as small as possible can remove the localized satellite assemblies by simply adding <SatelliteResourceLanguages>en</SatelliteResourceLanguages> in their .csproj file.

OpenIddict is now decorated with nullable reference types annotations

Following a general trend across the .NET community, all the OpenIddict libraries are now compiled with nullable reference types support enabled.

Due to a bug in the Roslyn compiler, the non-generic IOpenIddictApplicationManager, IOpenIddictAuthorizationManager, IOpenIddictScopeManager and IOpenIddictTokenManager interfaces deliberately don't expose any nullable annotation. You can track the resolution of this bug here.

Authorizations are no longer revoked when detecting a rolling refresh token replay

In previous versions of OpenIddict, sending a rolling refresh token twice always resulted in the revocation of the entire tokens chain and the revocation of the associated authorization. To make the rolling tokens option more convenient to use, the authorization associated to a refresh token is no longer revoked when it is sent multiple times.

DisableSlidingExpiration() was renamed to DisableSlidingRefreshTokenExpiration()

To make clearer the fact the sliding expiration mechanism applies to refresh tokens, the DisableSlidingExpiration() helper was renamed to DisableSlidingRefreshTokenExpiration() in OpenIddict 3.0 beta3.