-
-
Notifications
You must be signed in to change notification settings - Fork 502
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 3.0 roadmap #736
Comments
FYI, the first 3.0 bits were pushed to the repository. If you're interested in contributing, there are many "help wanted" tickets waiting for you: help wanted 😄 Thanks! |
Hi @PinpointTownes Great to see the new version is evolving. As mentioned in your comments above, we should still be able to use openiddict-core as a replacement for ASOS. Since we have a pretty large solution based on ASOS, we'd like to start initial migration as soon as possible. Is there any detailed information on how to replace ASOS with the openiddict-core in bare mode? Thanks, |
Hey @marc-mueller,
Nope, it's too early for that, as there are still many things to re-implement. Documentation is pretty much at the end of the todo-list. If it's important for you, consider contributing (there are many tasks you could help with) or sponsoring the project, so I can dedicate more time to it 😄 |
Thanks for your feedback, I almost expected this answer ;-) We can definitely contribute to this project, since this update is important for us. What we are currently looking for is something like an impact analysis for our code which is based on ASOS. But currently, we do not know where to start with this analysis. Is there any sample for bare mode planned? any roadmap? We basically need a starting point to get our hands dirty. |
Well, it's something you'll have to figure out yourselves (unless your project is OSS?). But the main promise remains: everything that was possible with ASOS will still be possible with OpenIddict's bare mode. Every report indicating something cannot be done with 3.0 will be treated as a regression and progressively addressed. There'll be differences, tho'. The most notable one is the event model, that got an overhaul in OpenIddict 3.0: instead of a unique You can take a look at the built-in handlers to see how this pattern is leveraged by OpenIddict itself. For instance, here's the handler responsible of validating the
It's planned. It will be probably part of a blog post I plan to write.
Things to do as part of 3.0 are listed here: https://github.com/openiddict/openiddict-core/milestone/12 I can't give any date as it largely depends on external contributions I have no control over: the more you guys contribute, the sooner we'll have viable packages for a first public 3.0 preview and the sooner I'll be able to write a sample and a blog post to explain how it works 😄 |
A quick update to say I'm a bit disappointed as I haven't seen any actual contribution, even from long-time OpenIddict users. It's unfortunate because .NET Core 3.0 is expected to officially ship in approximately 3 weeks, which is a very short window. While I'll likely have a first alpha version available for my clients by then, I strongly doubt I'll be able to dedicate more time to write blog posts or migration documentation, so you guys - who benefit from OSS projects but don't contribute back - will be pretty much on your own. |
Multiple customers informed me they were interested in using OpenIddict 3.0 in ASP.NET Core 2.1 and 2.2 applications. While 2.2 will reach end of support in December, supporting ASP.NET Core and .NET Core 2.1 would be particularly useful, as .NET Framework applications that can't move to .NET Core could stay on ASP.NET Core 2.1 (that will be supported indefinitely) while still being able to use the most recent OpenIddict bits. This scenario was made possible by lowering the version of the Compatibility with ASP.NET Core 2.1 and 2.2 will be tested extensively within the next few weeks with select customers to ensure everything works flawlessly. If you're interested in testing it, let me know. |
I'm working on a patch for OpenIddict 2.0 that would allow using it on 3.0 - even the EF Core stores - and that would backport a few fixes from 3.0. Let me know if you're interested in giving it a try. |
What version of OpenIdDict is necessary for using .NET Core 3.0? |
@refactoredmarc either the preview bits of |
@PinpointTownes Where is the 2.0.1 preview-package? Don't find it in nuget and only 3.0.0 packages in myget |
@toralux it's on the OpenIddict MyGet feed, whose address is mentioned in the README. |
Has anyone else encountered the following problem? I am trying to migrate a project to .NET Core 3.0 and am getting the following exception: "Method not found: 'Microsoft.EntityFrameworkCore.Metadata.Builders.IndexBuilder Microsoft.EntityFrameworkCore.Metadata.Builders.EntityTypeBuilder This is happening inside of OpenIddict.EntityFrameworkCore. This is the stack trace.: " OpenIddict.EntityFrameworkCore.OpenIddictApplicationConfiguration |
@refactoredmarc what version do you use? |
@refactoredmarc @PinpointTownes I had the same problem when migrating to EF Core 3.0 but using OpenIddict 2.0.0. Upgrading OpenIddict to 2.0.1-preview1-1298 stops the issue. I'm assuming it's because OpenIddict 2.0.0 still uses EF Core 2.x pakages, as suggested here. |
Then yes, it's expected: the OpenIddict 2.0.0 bits rely on APIs that were impacted by breaking changes in EF Core 3.0. The OpenIddict 2.0.1 patch will still reference EF Core 2.x, but I removed the problematic calls so that things don't break when using EF Core 3.x. |
Thanks @PinpointTownes for all your hard work with OpenIddict and sorry you're having trouble finding contributors for 3.0. Where's the best place to get notified when 2.0.1 is ready? |
See the comment above and the answer directly below it. You'll need to add the MyGet feed (https://www.myget.org/F/openiddict/api/v3/index.json) to your NuGet.config |
Thanks, I am good to go now |
The 2.0.1 packages are now on NuGet.org. You can find the changelog here: https://github.com/openiddict/openiddict-core/releases/tag/2.0.1 |
@PinpointTownes |
@a-patel it's still being actively developed. Unfortunately, due to the lack of contributions, it's not going as fast as I'd like. That said, @IgorHrabrov started to contribute recently and did a great job porting the primitives tests, so thanks a lot to him! 👏 We're still looking for contributors, so don't hesitate. |
…curity.OpenIdConnect.Server** is an **advanced OAuth2/OpenID Connect server framework** for both ASP.NET Core 1.x/2.x and OWIN/Katana 3.x/4.x, designed to offer a low-level, protocol-first approach. **The latest official release can be found on [NuGet](https://www.nuget.org/packages/AspNet.Security.OpenIdConnect.Server) and the nightly builds on [MyGet](https://www.myget.org/gallery/aspnet-contrib)**. [![Build status](https://ci.appveyor.com/api/projects/status/tyenw4ffs00j4sav/branch/dev?svg=true)](https://ci.appveyor.com/project/aspnet-contrib/aspnet-security-openidconnect-server/branch/dev) [![Build status](https://travis-ci.org/aspnet-contrib/AspNet.Security.OpenIdConnect.Server.svg?branch=dev)](https://travis-ci.org/aspnet-contrib/AspNet.Security.OpenIdConnect.Server) > **As part of the ASP.NET Core 3.0 migration, this project has been merged into OpenIddict. For more information, read the [OpenIddict 3.0 roadmap](openiddict/openiddict-core#736. ## Get started Based on `OAuthAuthorizationServerMiddleware` from **Katana**, **AspNet.Security.OpenIdConnect.Server** exposes similar primitives and can be directly registered in **Startup.cs** using the `UseOpenIdConnectServer` extension method: ```csharp public void ConfigureServices(IServiceCollection services) { services.AddAuthentication().AddOpenIdConnectServer(options => { // Enable the token endpoint. options.TokenEndpointPath = "/connect/token"; // Implement OnValidateTokenRequest to support flows using the token endpoint. options.Provider.OnValidateTokenRequest = context => { // Reject token requests that don't use grant_type=password or grant_type=refresh_token. if (!context.Request.IsPasswordGrantType() && !context.Request.IsRefreshTokenGrantType()) { context.Reject( error: OpenIdConnectConstants.Errors.UnsupportedGrantType, description: "Only grant_type=password and refresh_token " + "requests are accepted by this server."); return Task.CompletedTask; } // Note: you can skip the request validation when the client_id // parameter is missing to support unauthenticated token requests. // if (string.IsNullOrEmpty(context.ClientId)) // { // context.Skip(); // // return Task.CompletedTask; // } // Note: to mitigate brute force attacks, you SHOULD strongly consider applying // a key derivation function like PBKDF2 to slow down the secret validation process. // You SHOULD also consider using a time-constant comparer to prevent timing attacks. if (string.Equals(context.ClientId, "client_id", StringComparison.Ordinal) && string.Equals(context.ClientSecret, "client_secret", StringComparison.Ordinal)) { context.Validate(); } // Note: if Validate() is not explicitly called, // the request is automatically rejected. return Task.CompletedTask; }; // Implement OnHandleTokenRequest to support token requests. options.Provider.OnHandleTokenRequest = context => { // Only handle grant_type=password token requests and let // the OpenID Connect server handle the other grant types. if (context.Request.IsPasswordGrantType()) { // Implement context.Request.Username/context.Request.Password validation here. // Note: you can call context Reject() to indicate that authentication failed. // Using password derivation and time-constant comparer is STRONGLY recommended. if (!string.Equals(context.Request.Username, "Bob", StringComparison.Ordinal) || !string.Equals(context.Request.Password, "P@ssw0rd", StringComparison.Ordinal)) { context.Reject( error: OpenIdConnectConstants.Errors.InvalidGrant, description: "Invalid user credentials."); return Task.CompletedTask; } var identity = new ClaimsIdentity(context.Scheme.Name, OpenIdConnectConstants.Claims.Name, OpenIdConnectConstants.Claims.Role); // Add the mandatory subject/user identifier claim. identity.AddClaim(OpenIdConnectConstants.Claims.Subject, "[unique id]"); // By default, claims are not serialized in the access/identity tokens. // Use the overload taking a "destinations" parameter to make sure // your claims are correctly
FYI: a functional breaking change was introduced in the latest 3.0 nightly builds: access tokens will now be encrypted by default (which matches OpenIddict 2.x's behavior, where Data Protection tokens are always encrypted). If you only have a "local API" (i.e in the same project as the OpenIddict server), this change will be completely transparent, as OpenIddict imports the encryption keys from the server configuration when you use If your APIs are hosted in separate apps, you'll need to register the encryption keys using the Developers who prefer or need to disable access token encryption (e.g when issuing tokens used by third-party APIs) can easily do so by calling |
We're getting very close to the release of In the meantime, please keep testing the beta1 nightly builds, to ensure there's no last minute bug 😃 |
@kevinchalet |
Today's the day! https://kevinchalet.com/2020/06/11/introducing-openiddict-3-0-beta1/ 🎉 |
OpenIddict 3.0 beta2 is out. Read https://kevinchalet.com/2020/07/08/openiddict-3-0-beta2-is-out/ for more information. |
OpenIddict 3.0 beta3 is out: https://kevinchalet.com/2020/08/03/introducing-localization-support-in-openiddict-3-0-beta3/ |
@kevinchalet I figured out that beta3 has changes on the ef models, should I update the migrations for my projects? |
Beta3 indeed includes a few schema changes (a few columns are now nullable to match the entities that were decorated with nullable annotations), but applying the changes is not required for things to keep working properly. You can wait if you prefer. |
FYI, I just joined the GitHub Sponsors program, so if you are interested in sponsoring OpenIddict and helping with its development, please don't hesitate: https://github.com/sponsors/kevinchalet Every contribution counts, even small ones! |
OpenIddict 3.0 beta4 is out: https://kevinchalet.com/2020/10/02/introducing-quartz-net-support-and-new-languages-in-openiddict-3-0-beta4/ |
Do you have an idea of when openiddict 3.0 will be out, not beta |
@Gillardo when it's ready 😃 If you want it to happen ASAP, consider contributing, sponsoring me so I can dedicate more time to this project and encouraging your employer to do so. |
@kevinchalet thats fine, i was just wondering if you have a time frame. I maybe able to get sponsorship for it and able to contribute some time to this project but i need to convince the boss first and he will then ask the exact question i have..... If i go to him saying, i dont know that wont go down well. I am only asking as we have updated to net5 and although v2 works, i would like to upgrade to v3 but since this is for a production site, i dont really want to implement something that is currently in beta, sure you can understand that. |
A behavior change was introduced in the latest 3.0 beta6 nightly builds that will now require listing the response types a client is allowed to use. For more information, read #1138. |
OpenIddict 3.0 beta6 is out - https://kevinchalet.com/2020/10/27/openiddict-3-0-beta6-is-out/ |
3.0 rc1 was released earlier today: https://kevinchalet.com/2020/11/17/introducing-openiddict-3-0-s-first-release-candidate-version/ With RTM expected to be released mid-December, I encourage ASOS and OpenIddict 2.x users to start evaluating 3.0 as soon as possible so potential issues that may affect their scenarios are fixed in RTM. |
3.0 rc2 was just pushed to NuGet.org: no major/breaking change in this release, mostly bug fixes and improvements. If you haven't started evaluating 3.0, it's the perfect time to do so: the next release will be the RTM version. |
For those who missed the announcement, OpenIddict 3.0 was officially released yesterday: https://kevinchalet.com/2020/12/23/openiddict-3-0-general-availability/ Merry Christmas everyone! 🎄 |
Does OpenIdDict Core support SLI ? If yes, where can i find a sample or documentation ? We use OIDC client in Vue.js application. Thank's |
However, if we set @kevinchalet is it because encryption certificate is used internally to encrypt other tokens other than access token? |
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
andredirect_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
withoutOpenIddict.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 likeValidateAuthorizationRequest
orValidateTokenRequest
.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
andOpenIddict.Validation.AspNetCore
).The main
OpenIddict.Server
andOpenIddict.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
andOpenIddictServerProvider
) 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
andOpenIddict.Validation
, some of them will be provided by the host-specializedOpenIddict.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
andOpenIddict.Validation.DataProtection
packages, that will both target .NET Standard 2.0 (since Data Protection 3.0 is notnetcoreapp3.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!
The text was updated successfully, but these errors were encountered: