OpenIddict 3.0 roadmap

I recently announced on Gitter that I was working on an OpenIddict 3.0 prototype and shared some details about how I envision it. To make things a bit more formal, here’s the list of changes I’d like to make as part of the 3.0 overhaul.

Things that will change:

Merging the aspnet-contrib introspection, validation and server middleware into OpenIddict

Historically, the aspnet-contrib OIDC server middleware (aka ASOS) and OpenIddict have always had different goals and audiences, the former being a very low-level and stateless OIDC server middleware meant for advanced users and the later, a much more opinionated server based on ASOS but also taking care of things like client authentication/validation and authorizations/tokens storage (things ASOS don’t do for you).

Starting with 1.0/2.0 RC3, OpenIddict offered an event-oriented model allowing to implement advanced scenarios that were so far only possible with ASOS.

In 3.0, ASOS and OpenIddict will be merged into a single project - under the OpenIddict umbrella (in OpenIddict.Server) - offering the best of both worlds (at least, that’s the intent 😄).

To ensure OpenIddict can be used as a replacement for ASOS (for which people usually write their own persistence layer, at least to validate things like client_id and redirect_uri), a new degraded/bare mode will be introduced, allowing to use the OpenIddict server components without all the additional logic that relies on the OpenIddict managers/stores (e.g client authentication, client validation, token storage).

Concretely, this means you’ll be able to use OpenIddict.Server without OpenIddict.Core starting in 3.0, if you opt for the bare mode. In this case, you’ll have to register custom handlers to take care of validating requests, exactly like you’d do in ASOS with things like ValidateAuthorizationRequest or ValidateTokenRequest.

As part of this change, the aspnet-contrib introspection and validation middleware will also be merged into OpenIddict (in the OpenIddict.Validation package).

While it will follow the same release pace as the OpenIddict server components, the OpenIddict validation package will be compatible with any standard OAuth 2.0 deployment and will be usable without having to enable or even reference the server package.

Merging the aspnet-contrib middleware into OpenIddict will give me more flexibility and will reduce the pain of having to maintain 3 stacks in 3 different repositories.

Decoupling the OpenIddict server and validation features from ASP.NET Core

In OpenIddict 1.0 and 2.0, only the server and validation packages directly depended on ASP.NET Core (the abstractions, core and stores packages don’t, which means you can already use them in non-ASP.NET Core apps, like console apps or serverless functions, to prune the authorizations/tokens table, for instance).

In 3.0, I’ll go one step further and decouple the server and validation packages from ASP.NET Core, making them host-neutral/agnostic.

Instead, ASP.NET Core support will be provided as part of specialized companion packages (named OpenIddict.Server.AspNetCore and OpenIddict.Validation.AspNetCore).

The main OpenIddict.Server and OpenIddict.Validation packages will target .NET Standard 2.0/2.1 and the new ASP.NET Core-specific packages will cross-target .NET Framework 4.6.1, .NET Core 2.1 and .NET Core 3.0 to allow using OpenIddict 3.0 in both ASP.NET Core 2.1/2.2 and 3.0 apps.

Adding ASP.NET 4.x/OWIN support

This has been a fairly recurrent demand so starting with 3.0, we’re going to officially support using OpenIddict in ASP.NET 4.x apps by offering OWIN packages for the OpenIddict server and validation features. There will be minor differences between the ASP.NET Core and ASP.NET 4.x/OWIN versions, due to the differences between the two platforms (e.g OWIN doesn’t natively support dependency injection, which is something OpenIddict uses massively).

Introducing a revamped events model

It’s no secret that I’ve always been a huge fan of the event-oriented model introduced in the OWIN security middleware, later reused in ASP.NET Core and massively used in both ASOS and OpenIddict.

In 3.0, the events model will get a massive overhaul. As part of this overhaul, I plan to redesign how things were modeled in ASOS and OpenIddict by converting every single step of the request handling process (currently done in OpenIdConnectServerHandler and OpenIddictServerProvider) to specialized event handlers.

The idea is that each handler - taking care of a specific part of the request processing logic - will be removable, replaceable and even reorderable by advanced users, if they don’t like how OpenIddict handles things by default.

While most of the default handlers will be included in OpenIddict.Server and OpenIddict.Validation, some of them will be provided by the host-specialized OpenIddict.Server.[AspNetCore/Owin]/OpenIddict.Validation.[AspNetCore/Owin] packages (typically, the handlers dealing with request extraction or response processing).

Another core concept is that some of the default handlers would be disabled when opting for the degraded/bare mode (typically, all the handlers that would require the OpenIddict application/authorization/scope/token managers).

Changing the default token format for access tokens, authorization codes and refresh tokens to encrypted JWT

In ASOS/OpenIddict 1.x/2.x, ASP.NET Core Data Protection is used to encrypt the authorization codes, refresh tokens and access tokens (unless you explicitly opt for JWT access tokens).

In OpenIddict 3.0, the default format will now be JWT, with encryption mandatory for both authorization codes and refresh tokens (encryption is now fully supported by Microsoft’s IdentityModel library).

Support for ASP.NET Core Data Protection-based tokens will be provided by the OpenIddict.Server.DataProtection and OpenIddict.Validation.DataProtection packages, that will both target .NET Standard 2.0 (since Data Protection 3.0 is not netcoreapp3.0-only thanks to some intense lobbying 😅). You’ll have the choice between using DP for token validation only or token validation+token generation, and you’ll be able to use DP with both the OWIN and ASP.NET Core hosts.

Things that would be nice to have, but not for 3.0

Introducing an OpenIddict client

I’ve heard recurrent demands for advanced features like signed/encrypted authorizations or authorization responses using JWT as the response mode. Sadly, this is not something commonly supported in most OIDC clients. If support for these features were added in OpenIddict, we’d likely have to create our own OpenID Connect client supporting them.

If anything, this client would be usable with any standard OpenID Connect deployment (not just the OpenIddict server) and compatible with ASP.NET Core and ASP.NET 4.x/OWIN. Being able to use it in mobile, desktop or even Blazor-based browser applications would be a very cool bonus.

Making OpenIddict ready for the Authentication and Authorization for Constrained Environments protocol

With the rise of Internet of Things applications, the need for a lighter authorization protocol becomes real. To address that, the RISE Research Institutes of Sweden, Ericsson and ARM are currently working on a new OAuth2-based protocol called Authentication and Authorization for Constrained Environments (ACE).

The interesting part about this protocol is that it will typically run on top of CoAP instead of HTTP. Decoupling the OpenIddict server components from ASP.NET Core would certainly make that much easier, as we could easily run on top of a CoAP server like https://github.com/NZSmartie/CoAP.Net

Got any questions or remarks? Feel free to share them here or on Gitter!

[kevinchalet]

We’re getting very close to the release of 3.0.0-beta1, which is now feature complete. I will add more details in a blog post coming in the next few days.

In the meantime, please keep testing the beta1 nightly builds, to ensure there’s no last minute bug 😃

[kevinchalet]

OpenIddict 3.0 beta6 is out - https://kevinchalet.com/2020/10/27/openiddict-3-0-beta6-is-out/