10

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

Steve
  • 1,352
  • 1
  • 14
  • 28
  • Can you post exception details(enable log and see error logs)? – adem caglin Jul 15 '16 at 12:08
  • @ademcaglin I'm having trouble trying to get to those details as it's all happening in a nuget library. And I can't see anywhere to breakpoint. – Steve Jul 15 '16 at 23:29

1 Answers1

11

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.

Steve
  • 1,352
  • 1
  • 14
  • 28