Changing the signing key doesn't invalidate existing tokens

Question

I'm using OpenIddict in my web app and have just replaced

.AddEphemeralSigningKey()

with

.AddSigningCertificate("my thumbprint")

I now want to confirm that the new certificate is in fact being used, but when I submit an access_token that was created whilst using the old (ephemeral) key, it is accepted with no problem. I would expect it to be refused, now that the web app is using a different signing key!

Or, am I misunderstanding the purpose of the signing key?

I found this post that indicates the signing key is not used to sign access tokens created when using the ASP.Net Core Data Protection Stack, which I believe fits my scenario, as I am not using JWT tokens or customising the token format.

In this case, what is the signing key used for and/or why is it required?

Answer 1

In this case, what is the signing key used for and/or why is it required?

As explained in the post you mentioned, the signing key is only used to sign the JWT tokens issued by OpenIddict (which includes the identity tokens + the access tokens if you opted for JWT).

If you want to replicate the "ephemeral encryption/validation key" scenario with the default token format, you can ask OpenIddict to use an ephemeral data protector:

public class Startup
{
    private readonly IDataProtectionProvider _provider =
        new EphemeralDataProtectionProvider();

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOpenIddict(options =>
        {
            // ...

            options.UseDataProtectionProvider(_provider);
        });
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseOAuthValidation(options =>
        {
            options.DataProtectionProvider = _provider;
        });

        app.UseOpenIddict();
    }
}

You can also override the Data Protection options to use an ephemeral data protector for your entire application:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDataProtection()
            .UseEphemeralDataProtectionProvider();

        services.AddOpenIddict();
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseOAuthValidation();

        app.UseOpenIddict();
    }
}

It's worth noting that the signing key requirement was relaxed in the recent bits: registering a certificate or an ephemeral key is no longer necessary, except if you decide to use JWT access tokens or enable the implicit flow. So if you're using the password flow, adding a key is no longer mandatory.