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

Open
kevinchalet opened this issue Apr 4, 2019 · 23 comments
Open

OpenIddict 3.0 roadmap #736

kevinchalet opened this issue Apr 4, 2019 · 23 comments
Labels

Comments

@kevinchalet
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor 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: https://github.com/openiddict/openiddict-core/labels/help%20wanted 😄

Thanks!

@marc-mueller

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

Copy link
Contributor 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 kevinchalet mentioned this issue Oct 5, 2019
1 of 3 tasks complete
@kevinchalet

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

Copy link

@refactoredmarc refactoredmarc commented Oct 14, 2019

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

@kevinchalet

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor Author

@kevinchalet kevinchalet commented Oct 15, 2019

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

@refactoredmarc

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor Author

@kevinchalet kevinchalet commented Oct 16, 2019

@refactoredmarc what version do you use?

@yogster

This comment has been minimized.

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

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Copy link

@heeyahnuh heeyahnuh commented Oct 17, 2019

Thanks, I am good to go now

@kevinchalet

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

Copy link

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

@PinpointTownes
Any update on OpenIdDist 3.0?

@kevinchalet

This comment has been minimized.

Copy link
Contributor 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

This comment has been minimized.

Copy link
Contributor 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.

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

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.