[mitreid-connect] JWT Signatures - which public key?

Tue Oct 11 17:09:29 EDT 2016

Our RS is running inside Node.js (JavaScript server side) and we coded this particular check ourselves. We thought that somehow the signing kid was a global configuration, not on a per JWS basis. In any case, using the kid from the JWS header works for us. Thanks!

Regards,
Luiz

From: Yannick Béot <yannick.beot at gmail.com>
Date: Tuesday, October 11, 2016 at 4:59 PM
To: Justin Richer <jricher at mit.edu>
Cc: Luiz Omori <luiz.omori at duke.edu>, "mitreid-connect at mit.edu" <mitreid-connect at mit.edu>
Subject: Re: [mitreid-connect] JWT Signatures - which public key?

If you use JWSVerificationKeySelector from Nimbus to check the JWT (as stated http://connect2id.com/products/nimbus-jose-jwt/examples/validating-jwt-access-tokens<https://urldefense.proofpoint.com/v2/url?u=http-3A__connect2id.com_products_nimbus-2Djose-2Djwt_examples_validating-2Djwt-2Daccess-2Dtokens&d=CwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=R6m41WT3w_KtulQAsSIxc_C2mwuKoWSycEMpss0QQJA&m=6F7yjN0wgEl_CYid2eWsI8xveHuVk4RE3NYQxcjdSoM&s=tFDYtn7C5PUKcbusa9DPhhy7Ko1MuRUZR85J12mqRww&e=>), you should be fine..

JWSKeySelector is filtering keys with a JWKMatcher which checks the kid (https://bitbucket.org/connect2id/nimbus-jose-jwt/src/3810eb0a96565e7768cd54bf734dfea373ecc561/src/main/java/com/nimbusds/jose/jwk/JWKMatcher.java?at=4.15&fileviewer=file-view-default#JWKMatcher.java-562<https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_connect2id_nimbus-2Djose-2Djwt_src_3810eb0a96565e7768cd54bf734dfea373ecc561_src_main_java_com_nimbusds_jose_jwk_JWKMatcher.java-3Fat-3D4.15-26fileviewer-3Dfile-2Dview-2Ddefault-23JWKMatcher.java-2D562&d=CwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=R6m41WT3w_KtulQAsSIxc_C2mwuKoWSycEMpss0QQJA&m=6F7yjN0wgEl_CYid2eWsI8xveHuVk4RE3NYQxcjdSoM&s=laj0o_YVQJh6OzgvRqLpHyzluSrcC4ZIjvrQpelH92U&e=>)

JWSVerificationKeySelector is responsible for creating the JWKMatcher based on information from the signature, and especially the kid (https://bitbucket.org/connect2id/nimbus-jose-jwt/src/3810eb0a96565e7768cd54bf734dfea373ecc561/src/main/java/com/nimbusds/jose/proc/JWSVerificationKeySelector.java?at=4.15&fileviewer=file-view-default#JWSVerificationKeySelector.java-70<https://urldefense.proofpoint.com/v2/url?u=https-3A__bitbucket.org_connect2id_nimbus-2Djose-2Djwt_src_3810eb0a96565e7768cd54bf734dfea373ecc561_src_main_java_com_nimbusds_jose_proc_JWSVerificationKeySelector.java-3Fat-3D4.15-26fileviewer-3Dfile-2Dview-2Ddefault-23JWSVerificationKeySelector.java-2D70&d=CwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=R6m41WT3w_KtulQAsSIxc_C2mwuKoWSycEMpss0QQJA&m=6F7yjN0wgEl_CYid2eWsI8xveHuVk4RE3NYQxcjdSoM&s=ljwFpDh_GbDtxpk2ZAElJXa9gHzdbY9Bq9MADOknGPA&e=>)

@Luiz: what are you using to validate the token?

On Tue, Oct 11, 2016 at 9:13 PM, Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>> wrote:
The “kid” will be in the header of the JWT you’re validating. I think we’ve got a long-standing issue to enforce that check in the client library, but it should still work as-is.

 — Justin

On Oct 11, 2016, at 12:27 PM, Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>> wrote:

Well, which “kid” value should we look for? I checked the <root>/.well-known/openid-configuration and although it lists the jwk endpoint we couldn’t find the “kid” anywhere. Does it mean this info has to be transmitted offline?

{
  "keys":[
    {
      "alg":"RS256",
      "e":"xxx",
      "n":"xxx”,
      "kty":"RSA",
      "use":"enc",
      "kid":"mc.duke.edu<http://mc.duke.edu/>"
    },
    {
      "e":"xxx",
      "n":"xxx”,
      "kty":"RSA",
      "kid":"Test1"
    },
    {
      "e":"xxx",
      "n":"xxx”,
      "kty":"RSA",
      "kid":"Test2"
    },
    {
      "e":"xxx",
      "n":"xxx",
      "kty":"RSA",
      "kid":"rsa1"
    }
  ]
}

From: "yannick.beot at gmail.com<mailto:yannick.beot at gmail.com>" <yannick.beot at gmail.com<mailto:yannick.beot at gmail.com>>
Date: Tuesday, October 11, 2016 at 12:16 PM
To: Luiz Omori <luiz.omori at duke.edu<mailto:luiz.omori at duke.edu>>, "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: RE: [mitreid-connect] JWT Signatures - which public key?

There is a key id present in the header that is interpreted by Nimbus: https://tools.ietf.org/html/rfc7515#section-4.1.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7515-23section-2D4.1.4&d=CwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=R6m41WT3w_KtulQAsSIxc_C2mwuKoWSycEMpss0QQJA&m=946nVG8V76cufZ4NS83yWjsqNfm4xIW2uP9rsciX32I&s=HLXHrA80eziVyXZG3UyPxIKg-x7A1JpFPBB-62UILWw&e=>

You should use it to differentiate the keys.

Envoyé de mon téléphone Windows 10

De : Luiz Omori<mailto:luiz.omori at duke.edu>
Envoyé le :mardi 11 octobre 2016 18:04
À : mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
Objet :[mitreid-connect] JWT Signatures - which public key?

Hi,

In our implementation, the RS upon receiving a request it first validates the access token signature locally before introspecting it. To perform the signature validation we use a previously retrieved public key. The issue we are facing is that in our case the <root>/jwk endpoint is returning multiple keys. How do we figure out which one should be used? Should we check the “use” field? If yes, is there a standard value to check for?

Regards,
Luiz

_______________________________________________
mitreid-connect mailing list
mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>
http://mailman.mit.edu/mailman/listinfo/mitreid-connect<https://urldefense.proofpoint.com/v2/url?u=http-3A__mailman.mit.edu_mailman_listinfo_mitreid-2Dconnect&d=CwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=R6m41WT3w_KtulQAsSIxc_C2mwuKoWSycEMpss0QQJA&m=6F7yjN0wgEl_CYid2eWsI8xveHuVk4RE3NYQxcjdSoM&s=7ejLTX6oRpokbqgf2zKEwsyh0_vbbBcW4c8HJgyMWZM&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20161011/463f234b/attachment-0001.html