UseJwtBearerAuthentication signing key

I’m trying to implement the JWT Bearer Authentication in my AspNetCore MVC app (Web API only) using the JwtBearerMiddleware but am getting a 401 response with header:

WWW-Authenticate: Bearer error="invalid_token", error_description="The signature key was not found"

The relevant code in Startup.cs looks like this:

app.UseJwtBearerAuthentication(new JwtBearerOptions
{
    Authority = "https://example.okta.com",
    Audience = "myClientId"
});

With the Authority URL I’d expect the middleware to query my Identity Provider metadata from https://example.okta.com/.well-known/openid-configuration to get the jwks_uri to then get the signature keys from https://example.okta.com/oauth2/v1/keys. I don’t think this is happening. What do I need to do to get it to find and use the signature keys? Thanks

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

After following references and digging into the AspNet Security repo (specifically the JwtBearerHandler and JwtBearerMiddleware classes), which led me to the Microsoft.IdentityModel namespace which is in an Azure Extensions repo (first the ConfigurationManager<T> class, then to the OpenIdConnectConfigurationRetriever class (GetAsync method), then to the JsonWebKeySet.GetSigningKeys() method), I finally discovered that the JwtBearerMiddleware does indeed get the keys from the jwks_uri in the metadata. Phew.

So why wasn’t it working? What I should’ve checked earlier is that the kid in the header of the Bearer JWT did not in fact match either of the kid‘s from the jwks_uri, hence it wasn’t found. It was the access_code that I was sending as the bearer token. The id_token on the other hand does have a kid that matches, so using that instead it worked!

I’ve since read:

The OIDC Access Token is applicable only for the Okta
/oauth2/v1/userinfo endpoint and thus should be treated as opaque by
the application. The application does not need to validate it since it
should not be used against other resource servers. The format of it
and the key used to sign it are subject to change without prior
notice.
source

…so I can’t use the access token.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0