oauth 2.0 - Upgrading IdentityServer4 to Core 3.1 - tokens are suddenly not signed correctly?

Question

We encountered an error while upgrading IdentityServer4 (2.5.3 - 3.1.0) to Core 3.1 (from 2.2). Suddenly tokens that are issued doesn't have the correct signature. We haven't changed the signing algorithm; still using the same .PFX-certificate between versions.

var idSrvBuilder = services.AddIdentityServer(opts =>
            {
                opts.Events.RaiseErrorEvents = true;
                opts.Events.RaiseFailureEvents = true;
                opts.Events.RaiseInformationEvents = true;
                opts.Events.RaiseSuccessEvents = true;
                if (_env.IsProduction())
                {
                    opts.PublicOrigin = Configuration["Globals:IdentityURL"];
                }
            }).AddSigningCredential(new X509Certificate2(Configuration["Cert:Path"], Configuration["Cert:Password"]));

When using the OWIN middleware "UseIdentityServerBearerTokenAuthentication" for an older API it fails if ValidationMode is Local but not if it's validating directly against the IdentityServer (with ValidationMode ValidationEndpoint). The API will only return "Unauthorized" but works with the older token (same certificate signing them!)

app.UseIdentityServerBearerTokenAuthentication(new IdentityServer3.AccessTokenValidation.IdentityServerBearerTokenAuthenticationOptions
            {
                Authority = AppSettings.Authority,
                ClientId = AppSettings.ApiName,
                ClientSecret = AppSettings.ApiSecret,
                EnableValidationResultCache = false,
                ValidationMode = IdentityServer3.AccessTokenValidation.ValidationMode.Local
            });

Looking at the token issued between versions there's a glaring difference:

Old (removed payload):

eyJhbGciOiJSUzI1NiIsImtpZCI6IjZCMTM4RUIzMUE4OUExQTdEQTdCNkRGNzMwOTRGMzIzREJFNzhCNjYiLCJ0eXAiOiJKV1QiLCJ4NXQiOiJheE9Pc3hxSm9hZmFlMjMzTUpUekk5dm5pMlkifQ.U3unxhW6act8fQLCLAYBJAZ-lIMiKaghVEUdA3b7iM0mI0UqGmYgYw05SvVXTAT8ZNQPuq0D-97d0Z6VVBC2wH7VAl0daF6sYJyuSUEtDiBPttNQ9MsGBNjcN1HABZ0nv-z_lgG2Z9sgp4blCvc7N8xOsja-kuk6m06I7iOfS7O_YKPtTAXA10OCzdtiJbhYijeTFsBJaWf5-J3XJCtqpp-MGXCboE0gQIlvysKz5_CRaaKYptczw-cTX3sgRIhfWn2VxVujhH7JKeSJan52X-fQ4T47PWuVcWNOrcWheeLAbVDQU1U9DiLVVua3BasnIku5Rx4XcLnqCaokCiWZhg

With the following token header:

{
  "alg": "RS256",
  "kid": "6B138EB31A89A1A7DA7B6DF73094F323DBE78B66",
  "typ": "JWT",
  "x5t": "axOOsxqJoafae233MJTzI9vni2Y"
}

New:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjZCMTM4RUIzMUE4OUExQTdEQTdCNkRGNzMwOTRGMzIzREJFNzhCNjYiLCJ0eXAiOiJhdCtqd3QiLCJ4NXQiOiJheE9Pc3hxSm9hZmFlMjMzTUpUekk5dm5pMlkifQ.RmKHRk44c6Ele-VbB8lhNsmmcvKFludaWypuBzQzYqR7AEIuLXAuZ-N4I9ooVvQLHisBJT4qA4epEK9xdtf0ELpcvfEe3Yc2dkJnKp_rjJSRuhqyNHD0hPAoxqVSWHhfaLxLiL7_17mklqLDEqwdXANnA2YCO-Q-9wqGALZorywHYucr0X9m2hYm1oVgXPitG_TAqysYVNnLCHVGZRNE7Xmug0XhkJXzQ8RpZuSHlDHFlT2cgb7psEb4NUfA8v5-q-LyqfPDk4xJZX2ia53SoPpiJbByFgscYF4xk54SkkcB9EOxCCsR-IYHJAmyYkhGRpBVWY5xU_9qb2ioIwkzZg

With the following header:

{
  "alg": "RS256",
  "kid": "6B138EB31A89A1A7DA7B6DF73094F323DBE78B66",
  "typ": "at+jwt",
  "x5t": "axOOsxqJoafae233MJTzI9vni2Y"
}

I'm guessing the issue is that "typ" from the new token is "at+jwt"? What does that mean? I've looked at IdentityServers releases, Github issues, googled, searched stackoverflow but no one seems to have noticed the mysterious new "at+jwt" "typ".

Could that be causing the issue? How can I instruct my new version to issue a standard JWT? And what is this strange at+jwt?

Answer 1

Thanks to @Ruard van Elburg in the comments for linking to explicit typed tokens.

Changing the default "at+jwt" to just "jwt" solved the issue:

var idSrvBuilder = services.AddIdentityServer(opts =>
            {
                opts.Events.RaiseErrorEvents = true;
                opts.Events.RaiseFailureEvents = true;
                opts.Events.RaiseInformationEvents = true;
                opts.Events.RaiseSuccessEvents = true;
                opts.AccessTokenJwtType = "jwt";
                if (_env.IsProduction())
                {
                    opts.PublicOrigin = Configuration["Globals:IdentityURL"];
                }
            });

I'm guessing the underlying issue is with the package IdentityServer3.AccessTokenValidation we're using in that API not being able to recognize at+jwt. We're using that so that we can potentielly support reference tokens.

We also can't upgrade this API to ASP Core and use the newer IdentityServerAuthenticationExtensions from Microsoft due to some depedencies from third parties we need to support. That package does seem to be able to handle at+jwt just fine.

EDIT:

Still didn't work. Had a look at the Github issue that Ruard linked to.

Turns out I also had to turn on EmitLegacyResourceAudienceClaim so not it looks like this:

var idSrvBuilder = services.AddIdentityServer(opts =>
            {
                opts.Events.RaiseErrorEvents = true;
                opts.Events.RaiseFailureEvents = true;
                opts.Events.RaiseInformationEvents = true;
                opts.Events.RaiseSuccessEvents = true;
                opts.AccessTokenJwtType = "JWT";
                opts.EmitLegacyResourceAudienceClaim = true;
                if (_env.IsProduction())
                {
                    opts.PublicOrigin = Configuration["Globals:IdentityURL"];
                }
            })