本文介紹了無(wú)法使用Nimbus驗(yàn)證來(lái)自Azure的訪問(wèn)令牌簽名的處理方法，對(duì)大家解決問(wèn)題具有一定的參考價(jià)值，需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)吧！
問(wèn)題描述
在此example之后，我編寫了一些代碼來(lái)驗(yàn)證從Azure隱式流返回的訪問(wèn)令牌。
RemoteJWKSet remoteJWKSet = new RemoteJWKSet(new URL(jwksUri));
JWSKeySelector keySelector = new JWSVerificationKeySelector(JWSAlgorithm.RS256, remoteJWKSet);
ConfigurableJWTProcessor jwtProcessor = new DefaultJWTProcessor<>();
jwtProcessor.setJWTClaimsSetVerifier(new DefaultJWTClaimsVerifier(
new JWTClaimsSet.Builder().issuer("https://sts.windows.net/3283e312-f73b-47d0-81c6-75e3ac726c21/").build(),
new HashSet<>(Arrays.asList("sub", "iat", "exp", "scp"))));
jwtProcessor.setJWSKeySelector(keySelector);
JWTClaimsSet claimsSet = jwtProcessor.process(accessToken.getValue(), null);
但驗(yàn)證失敗，我得到：
com.nimbusds.jose.proc.BadJWSException: Signed JWT rejected: Invalid signature
at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:378)
at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:303)
at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:294)
我認(rèn)為我不需要DefaultJWTClaimsVerifier部分，但刪除它不會(huì)改變?nèi)魏问虑椤Ｎ抑幌Ｍ軋?jiān)持這個(gè)例子。
您知道為什么會(huì)發(fā)生這種情況嗎？
感謝您的幫助。
PS：無(wú)法使用jwt.io進(jìn)行驗(yàn)證。我粘貼了Access_Token和來(lái)自jwk的"；key"；部分的第一個(gè)條目。
推薦答案
您需要expose an API scope在Azure中，并讓客戶端使用它。還要確保訪問(wèn)令牌的JWT報(bào)頭中沒(méi)有nonce字段。我的blog post有更多信息。
Azure AD行為
以上行為完全特定于Microsoft，并且在將Azure AD用作提供程序時(shí)是必需的：
JWT標(biāo)頭中帶有隨機(jī)數(shù)字段的令牌僅針對(duì)MS API(如Graph)設(shè)計(jì)，并使用內(nèi)部驗(yàn)證機(jī)制。其目的是使這些應(yīng)用程序始終無(wú)法通過(guò)自定義API的驗(yàn)證。
您自己的自定義API的令牌必須通過(guò)請(qǐng)求自定義作用域的客戶端檢索。請(qǐng)注意，在Azure AD中配置的OAuth客戶端可以是一個(gè)邏輯條目，而不需要為每個(gè)單獨(dú)的API維護(hù)一個(gè)。
我認(rèn)為MS的行為是基于OAuth resource indicators的，雖然我個(gè)人傾向于在API中接收訪問(wèn)令牌時(shí)使用更主流的scopes、claims和受眾檢查技術(shù)。
這篇關(guān)于無(wú)法使用Nimbus驗(yàn)證來(lái)自Azure的訪問(wèn)令牌簽名的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，
