Error validating Token generated by IdentityServer4

[diogodamiani]

I'm migrating our STS solution to .NET Core with IS4 but I have some Web APIs that won't be migrated right now. These APIs use IdentityServer3.AccessTokenValidation.

When I request my API I get the error: IDX10500: Signature validation failed. Unable to resolve SecurityKeyIdentifier.

That`s the full message:

IDX10500: Signature validation failed. Unable to resolve SecurityKeyIdentifier: 'SecurityKeyIdentifier( IsReadOnly = False, Count = 1, Clause[0] = System.IdentityModel.Tokens.NamedKeySecurityKeyIdentifierClause)', token: '{"alg":"RS256","kid":"6B7ACC520305BFDB4F7252DAEB2177CC091FAAE1","typ":"JWT"}.{"nbf":1467394685,"exp":1467398285,"iss":"http://localhost:5000","aud":"http://localhost:5000/resources","client_id":"js.simple","scope":"write","sub":"88421113","auth_time":1467394679,"idp":"idsvr"}'.

Stack Trace:

em System.IdentityModel.Tokens.JwtSecurityTokenHandler.ValidateSignature(String token, TokenValidationParameters validationParameters) na c:\workspace\WilsonForDotNet45Release\src\System.IdentityModel.Tokens.Jwt\JwtSecurityTokenHandler.cs:linha 943 em System.IdentityModel.Tokens.JwtSecurityTokenHandler.ValidateToken(String securityToken, TokenValidationParameters validationParameters, SecurityToken& validatedToken) na c:\workspace\WilsonForDotNet45Release\src\System.IdentityModel.Tokens.Jwt\JwtSecurityTokenHandler.cs:linha 671 em Microsoft.Owin.Security.Jwt.JwtFormat.Unprotect(String protectedText) em Microsoft.Owin.Security.Infrastructure.AuthenticationTokenReceiveContext.DeserializeTicket(String protectedData) em Microsoft.Owin.Security.OAuth.OAuthBearerAuthenticationHandler.d__0.MoveNext()

My access token:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjZCN0FDQzUyMDMwNUJGREI0RjcyNTJEQUVCMjE3N0NDMDkxRkFBRTEiLCJ0eXAiOiJKV1QifQ.eyJuYmYiOjE0NjczOTQ0MTUsImV4cCI6MTQ2NzM5ODAxNSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo1MDAwIiwiYXVkIjoiaHR0cDovL2xvY2FsaG9zdDo1MDAwL3Jlc291cmNlcyIsImNsaWVudF9pZCI6ImpzLnNpbXBsZSIsInNjb3BlIjoid3JpdGUiLCJzdWIiOiI4ODQyMTExMyIsImF1dGhfdGltZSI6MTQ2NzM5MTg2NSwiaWRwIjoiaWRzdnIifQ.kaTun1hPvnlJziTtFmA6y8m2EB_loO2DDe_QboG_U4WsQptqe6-cvriSgzqXqX2V4s2c0QLxgcW-SNmTJ3WH4KMcpWjbkBae7l3WX9731eBKdU2N_7KatNrzMPjFVK4Rs0Ha_EOb1Vdr4fzOEF0fVqVSfISxJTzYDoXxgsrcrJL-iPzZuJQ9cKu04aXrfz054u-Lhox7zGREwrTZiutQmsK7DPAErL-WSZwjp70TE7S9LvGtf-skyt1lin1erIHKtQjKTHajF2tvRFFCftTPJ85brP9Yn_lpjbCJshCXvpGRAuHuALxu0FTfVu9Bo0LrwaRCewY1giXBOQIPQLPDkA",
  "token_type": "Bearer",
  "expires_in": "3600",
  "scope": "write",
  "state": "14673944138580.011846233980380982"
}

I have tested with samples: Server: IdentityServer project in MVC and API solution (IS4 samples) Client: JavaScript OAuth only in Clients solution. (IS3 samples) API: Sample Web API in Clients solution. (IS3 samples)

[leastprivilege]

Can you verify that your discovery document contains a key with that kid:

6B7ACC520305BFDB4F7252DAEB2177CC091FAAE1

[diogodamiani]

@leastprivilege Yes. I've checked the discovery document and it contains the key. Look at the result: http://localhost:5000/.well-known/openid-configuration/jwks

{
   "keys":[
      {
         "kty":"RSA",
         "use":"sig",
         "kid":"6B7ACC520305BFDB4F7252DAEB2177CC091FAAE1",
         "x5t":"a3rMUgMFv9tPclLa6yF3zAkfquE",
         "e":"AQAB",
         "n":"qnTksBdxOiOlsmRNd-mMS2M3o1IDpK4uAr0T4_YqO3zYHAGAWTwsq4ms-NWynqY5HaB4EThNxuq2GWC5JKpO1YirOrwS97B5x9LJyHXPsdJcSikEI9BxOkl6WLQ0UzPxHdYTLpR4_O-0ILAlXw8NU4-jB4AP8Sn9YGYJ5w0fLw5YmWioXeWvocz1wHrZdJPxS8XnqHXwMUozVzQj-x6daOv5FmrHU1r9_bbp0a1GLv4BbTtSh4kMyz1hXylho0EvPg5p9YIKStbNAW9eNWvv5R8HN7PPei21AsUqxekK0oW9jnEdHewckToX7x5zULWKwwZIksll0XnVczVgy7fCFw",
         "x5c":[
            "MIIDBTCCAfGgAwIBAgIQNQb+T2ncIrNA6cKvUA1GWTAJBgUrDgMCHQUAMBIxEDAOBgNVBAMTB0RldlJvb3QwHhcNMTAwMTIwMjIwMDAwWhcNMjAwMTIwMjIwMDAwWjAVMRMwEQYDVQQDEwppZHNydjN0ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqnTksBdxOiOlsmRNd+mMS2M3o1IDpK4uAr0T4/YqO3zYHAGAWTwsq4ms+NWynqY5HaB4EThNxuq2GWC5JKpO1YirOrwS97B5x9LJyHXPsdJcSikEI9BxOkl6WLQ0UzPxHdYTLpR4/O+0ILAlXw8NU4+jB4AP8Sn9YGYJ5w0fLw5YmWioXeWvocz1wHrZdJPxS8XnqHXwMUozVzQj+x6daOv5FmrHU1r9/bbp0a1GLv4BbTtSh4kMyz1hXylho0EvPg5p9YIKStbNAW9eNWvv5R8HN7PPei21AsUqxekK0oW9jnEdHewckToX7x5zULWKwwZIksll0XnVczVgy7fCFwIDAQABo1wwWjATBgNVHSUEDDAKBggrBgEFBQcDATBDBgNVHQEEPDA6gBDSFgDaV+Q2d2191r6A38tBoRQwEjEQMA4GA1UEAxMHRGV2Um9vdIIQLFk7exPNg41NRNaeNu0I9jAJBgUrDgMCHQUAA4IBAQBUnMSZxY5xosMEW6Mz4WEAjNoNv2QvqNmk23RMZGMgr516ROeWS5D3RlTNyU8FkstNCC4maDM3E0Bi4bbzW3AwrpbluqtcyMN3Pivqdxx+zKWKiORJqqLIvN8CT1fVPxxXb/e9GOdaR8eXSmB0PgNUhM4IjgNkwBbvWC9F/lzvwjlQgciR7d4GfXPYsE1vf8tmdQaY8/PtdAkExmbrb9MihdggSoGXlELrPA91Yce+fiRcKY3rQlNWVd4DOoJ/cPXsXwry8pWjNCo5JD8Q+RQ5yZEy7YPoifwemLhTdsBz3hlZr28oCGJ3kbnpW0xGvQb3VHSTVVbeei0CfXoW6iz1"
         ]
      }
   ]
}

[leastprivilege]

OK - i need to repro that here. I wouldn't be surprised if this is some inconsistent behavior between v4 and v5 of Microsoft's JWT handler (actually I am pretty sure it is).

[diogodamiani]

So am I. :) If you need more information, don't hesitate to contact me! Thank you!

[leastprivilege]

OK - I tracked it down. It is as I thought.

v4 of the MS JWT lib requires an 'x5t' in the JWT header (we did that in idsrv3) v5 does it right and looks for a 'kid' in the header (we don't emit x5t right now in idsrv4).

So either I need to change idsrv4 to emit an additional and wrong header - or I need to find an easy way to make the JWT v4 look for kid instead.

investigating

[leastprivilege]

the path of least resistance is to add the x5t in idsrv4. I pushed a beta4-update2 package - give it a go.

[diogodamiani]

Thanks @leastprivilege! It worked fine.

[ghost]

Hi, Is this fix solely available in the beta4-update2 package or is it in a formal version now? Thanks