Skip to content
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

Closed
kevinchalet opened this issue Apr 4, 2019 · 42 comments
Closed

OpenIddict 3.0 roadmap #736

kevinchalet opened this issue Apr 4, 2019 · 42 comments

Comments

@kevinchalet
Copy link
Member

@kevinchalet kevinchalet commented Apr 4, 2019

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
Copy link
Member Author

@kevinchalet kevinchalet commented Aug 19, 2019

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!

@marc-mueller
Copy link

@marc-mueller marc-mueller commented Aug 20, 2019

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,
Marc

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Aug 20, 2019

Hey @marc-mueller,

Is there any detailed information on how to replace ASOS with the openiddict-core in bare mode?

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 😄

@marc-mueller
Copy link

@marc-mueller marc-mueller commented Aug 20, 2019

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Aug 20, 2019

What we are currently looking for is something like an impact analysis for our code which is based on ASOS.

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 OpenIdConnectServerProvider class with properties to set or methods to override, you'll now have multiple IOpenIddictServerHandler<TContext> forming a chain of handlers.

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 grant_type in a token request: https://github.com/openiddict/openiddict-core/blob/dev/src/OpenIddict.Server/OpenIddictServerHandlers.Exchange.cs#L364

Is there any sample for bare mode planned?

It's planned. It will be probably part of a blog post I plan to write.

any roadmap?

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 😄

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Sep 6, 2019

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 5, 2019

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 Microsoft.Extensions.* packages we use to 2.1.0 on .NET Standard 2.0, .NET Framework and .NET Core 2.1 and by using cross-compilation to allow the ASP.NET Core packages to be used on .NET Core 2.1, .NET Core 2.2 and .NET Framework 4.6.1 and higher. The EF Core stores were tweaked to deal with the older AsyncEnumerable/IAsyncEnumerable from EF Core/IX, that were not compatible with the new IAsyncEnumerable from the BCL.

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 9, 2019

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.

@refactoredmarc
Copy link

@refactoredmarc refactoredmarc commented Oct 14, 2019

What version of OpenIdDict is necessary for using .NET Core 3.0?

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 15, 2019

@refactoredmarc either the preview bits of 2.0.1 (e.g 2.0.1-preview1-1298) or the nightly builds of 3.0.0.

@toralux
Copy link

@toralux toralux commented Oct 15, 2019

@PinpointTownes Where is the 2.0.1 preview-package? Don't find it in nuget and only 3.0.0 packages in myget

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 15, 2019

@toralux it's on the OpenIddict MyGet feed, whose address is mentioned in the README.

@refactoredmarc
Copy link

@refactoredmarc refactoredmarc commented Oct 16, 2019

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.EntityTypeBuilder1.HasIndex(System.Linq.Expressions.Expression1<System.Func`2<System.__Canon,System.Object>>)'."

This is happening inside of OpenIddict.EntityFrameworkCore. This is the stack trace.:

" OpenIddict.EntityFrameworkCore.OpenIddictApplicationConfiguration4.Configure(EntityTypeBuilder1 builder)\r\n at Microsoft.EntityFrameworkCore.ModelBuilder.ApplyConfiguration[TEntity](IEntityTypeConfiguration1 configuration)\r\n at Microsoft.EntityFrameworkCore.OpenIddictEntityFrameworkCoreHelpers.UseOpenIddict[TApplication,TAuthorization,TScope,TToken,TKey](ModelBuilder builder)\r\n at OpenIddict.EntityFrameworkCore.OpenIddictEntityFrameworkCoreCustomizer5.Customize(ModelBuilder builder, DbContext context)\r\n at Microsoft.EntityFrameworkCore.Infrastructure.ModelSource.CreateModel(DbContext context, IConventionSetBuilder conventionSetBuilder)\r\n at Microsoft.EntityFrameworkCore.Infrastructure.ModelSource.<>c__DisplayClass5_0.b__1()\r\n at System.Lazy1.ViaFactory(LazyThreadSafetyMode mode)\r\n at System.Lazy1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)\r\n at System.Lazy1.CreateValue()\r\n at System.Lazy1.get_Value()\r\n at Microsoft.EntityFrameworkCore.Infrastructure.ModelSource.GetModel(DbContext context, IConventionSetBuilder conventionSetBuilder)\r\n at Microsoft.EntityFrameworkCore.Internal.DbContextServices.CreateModel()\r\n at Microsoft.EntityFrameworkCore.Internal.DbContextServices.get_Model()\r\n at Microsoft.EntityFrameworkCore.Infrastructure.EntityFrameworkServicesBuilder.<>c.b__7_3(IServiceProvider p)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitFactory(FactoryCallSite factoryCallSite, RuntimeResolverContext context)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitCache(ServiceCallSite callSite, RuntimeResolverContext context, ServiceProviderEngineScope serviceProviderEngine, RuntimeResolverLock lockType)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScopeCache(ServiceCallSite singletonCallSite, RuntimeResolverContext context)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor2.VisitCallSite(ServiceCallSite callSite, TArgument argument)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitConstructor(ConstructorCallSite constructorCallSite, RuntimeResolverContext context)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor2.VisitCallSiteMain(ServiceCallSite callSite, TArgument argument)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitCache(ServiceCallSite callSite, RuntimeResolverContext context, ServiceProviderEngineScope serviceProviderEngine, RuntimeResolverLock lockType)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScopeCache(ServiceCallSite singletonCallSite, RuntimeResolverContext context)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor2.VisitCallSite(ServiceCallSite callSite, TArgument argument)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.Resolve(ServiceCallSite callSite, ServiceProviderEngineScope scope)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine.<>c__DisplayClass1_0.b__0(ServiceProviderEngineScope scope)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngine.GetService(Type serviceType, ServiceProviderEngineScope serviceProviderEngineScope)\r\n at Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(Type serviceType)\r\n at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService(IServiceProvider provider, Type serviceType)\r\n at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetRequiredService[T](IServiceProvider provider)\r\n at Microsoft.EntityFrameworkCore.DbContext.get_DbContextDependencies()\r\n at Microsoft.EntityFrameworkCore.DbContext.get_InternalServiceProvider()\r\n at Microsoft.EntityFrameworkCore.DbContext.Microsoft.EntityFrameworkCore.Infrastructure.IInfrastructure<System.IServiceProvider>.get_Instance()\r\n at Microsoft.EntityFrameworkCore.Infrastructure.Internal.InfrastructureExtensions.GetService[TService](IInfrastructure1 accessor)\r\n at Microsoft.EntityFrameworkCore.Infrastructure.AccessorExtensions.GetService[TService](IInfrastructure1 accessor)\r\n at Microsoft.EntityFrameworkCore.Infrastructure.DatabaseFacade.get_Dependencies()\r\n at Microsoft.EntityFrameworkCore.Infrastructure.DatabaseFacade.Microsoft.EntityFrameworkCore.Internal.IDatabaseFacadeDependenciesAccessor.get_Dependencies()\r\n at Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.GetFacadeDependencies(DatabaseFacade databaseFacade)\r\n at Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.GetDbConnection(DatabaseFacade databaseFacade)\r\n at Arc.AuthDal.DatabaseInitializer.d__4.MoveNext() in C:\Source\ARC\arc5\Arc5Source\Arc.AuthDal\DatabaseInitializer.cs:line 39"

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 16, 2019

@refactoredmarc what version do you use?

@yogster
Copy link

@yogster yogster commented Oct 16, 2019

@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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 16, 2019

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.

@yogster
Copy link

@yogster yogster commented Oct 16, 2019

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?

@yogster
Copy link

@yogster yogster commented Oct 16, 2019

Where do I find 2.0.1-preview1-1298?

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

@openiddict openiddict deleted a comment from heeyahnuh Oct 17, 2019
@openiddict openiddict deleted a comment from heeyahnuh Oct 17, 2019
@heeyahnuh
Copy link

@heeyahnuh heeyahnuh commented Oct 17, 2019

Thanks, I am good to go now

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 17, 2019

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

@a-patel
Copy link
Contributor

@a-patel a-patel commented Dec 13, 2019

@PinpointTownes
Any update on OpenIdDist 3.0?

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Dec 14, 2019

@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.

mohsenTalal added a commit to mohsenTalal/Security.OpenIdConnect that referenced this issue Dec 27, 2019
…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
@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Jan 15, 2020

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 options.UseLocalServer().

If your APIs are hosted in separate apps, you'll need to register the encryption keys using the options.AddEncryptionKey()/options.AddEncryptionCertificate() helpers.

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 options.DisableAccessTokenEncryption() from the OpenIddict server configuration delegate.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Jun 2, 2020

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 😃

@a-patel
Copy link
Contributor

@a-patel a-patel commented Jun 2, 2020

@kevinchalet
Also, share the blog post/doc link here.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Jun 11, 2020

Today's the day! https://kevinchalet.com/2020/06/11/introducing-openiddict-3-0-beta1/ 🎉

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Jul 8, 2020

OpenIddict 3.0 beta2 is out. Read https://kevinchalet.com/2020/07/08/openiddict-3-0-beta2-is-out/ for more information.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Aug 3, 2020

@kinosang
Copy link
Contributor

@kinosang kinosang commented Aug 4, 2020

@kevinchalet I figured out that beta3 has changes on the ef models, should I update the migrations for my projects?

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Aug 4, 2020

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Sep 18, 2020

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!

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 2, 2020

OpenIddict 3.0 beta4 is out: https://kevinchalet.com/2020/10/02/introducing-quartz-net-support-and-new-languages-in-openiddict-3-0-beta4/

@Gillardo
Copy link

@Gillardo Gillardo commented Oct 9, 2020

Do you have an idea of when openiddict 3.0 will be out, not beta

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 9, 2020

@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.

@Gillardo
Copy link

@Gillardo Gillardo commented Oct 9, 2020

@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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 21, 2020

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Oct 27, 2020

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

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Nov 18, 2020

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Dec 7, 2020

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.

@kevinchalet
Copy link
Member Author

@kevinchalet kevinchalet commented Dec 24, 2020

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! 🎄

@kevinchalet kevinchalet unpinned this issue Dec 24, 2020
@Vicnat35
Copy link

@Vicnat35 Vicnat35 commented Mar 3, 2021

@kevinchalet

Does OpenIdDict Core support SLI ?

https://oa.dnc.global/web/-OpenID-Connect-SSO-management-de-session-etc-.html#ssoetconnexionuniquesingleloginidentificationsli

If yes, where can i find a sample or documentation ?

We use OIDC client in Vue.js application.
We have a front portal fot authenticate users againt's our OpenIdDict server and we want to call client applications whithout neceesity to re_authenticate ....

Thank's

@pfaustinopt
Copy link

@pfaustinopt pfaustinopt commented Apr 7, 2021

If your APIs are hosted in separate apps, you'll need to register the encryption keys using the options.AddEncryptionKey()/options.AddEncryptionCertificate() helpers.

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 options.DisableAccessTokenEncryption() from the OpenIddict server configuration delegate.

However, if we set options.DisableAccessTokenEncryption() and remove options.AddEncryptionKey()/options.AddEncryptionCertificate() from the startup we get the following error:
InvalidOperationException: At least one encryption key must be registered in the OpenIddict server options.

@kevinchalet is it because encryption certificate is used internally to encrypt other tokens other than access token?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests