OpenIddict 3.0 roadmap

[kevinchalet]

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]

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 :smile:

Thanks!

[marc-mueller]

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]

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]

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]

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]

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]

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]

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]

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

[kevinchalet]

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

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

[kevinchalet]

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

[refactoredmarc]

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.<>cDisplayClass5_0.b1()\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.b7_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.<>cDisplayClass1_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.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]

@refactoredmarc what version do you use?

[yogster]

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

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]

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]

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

[heeyahnuh]

Thanks, I am good to go now

[kevinchalet]

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]

@PinpointTownes Any update on OpenIdDist 3.0?

[kevinchalet]

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

[kevinchalet]

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]

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]

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

[kevinchalet]

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

[kevinchalet]

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

[kevinchalet]

OpenIddict 3.0 beta3 is out: https://kevinchalet.com/2020/08/03/introducing-localization-support-in-openiddict-3-0-beta3/

[kinosang]

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

[kevinchalet]

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]

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]

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]

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

[kevinchalet]

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

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

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 https://github.com/openiddict/openiddict-core/issues/1138.

[kevinchalet]

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

[kevinchalet]

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]

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]

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

[Vicnat35]

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

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?