idTokenが有効であることを確認する方法

Question

私はweb-app-samples-for-adal4jを実行していて、/ secure/aadページを見ることができ、Azure ADによって送信されたidTokenを回復することができます。 。

私の考えは、そのトークンをさまざまなサービスに渡すことです。それぞれのトークンは、トークンが有効であることを検証できます。

要約すると、指定されたidtokenが有効であることをサービスから確認できます。私が理解している限り、トークンから回復できるJWTが証明書で署名されていることを確認する必要があります。私が間違っている？

私はこのウェブサイトhttp://jwt.calebb.net/を使用してJWTを解読できることを確認しています。最後の部分で私は署名を見ることができます。

私の質問は、外部サービスがトークンが特定の証明書でエンコードされていることを確認する方法です。そして、その証明書はどこにありますか？（それは連邦政府のメタデータ文書にありますか？）

Answer 1

私の理解に基づいて、id_tokenは、クライアントが現在のユーザー情報を確認するために使用されます。リソースの特定のアクセス権をチェックするために、通常はaccess_tokenを使用します。

OpenIDの接続プロトコルを使用してのAzureと統合アズールADから発行されたid_tokenを検証するために、我々は（OpenId specificationを参照してください）以下の手順に従うことができます：IDトークンが暗号化されている場合、キーを使用して、それを解読し、

1. をOPがIDトークンを暗号化するために使用した登録中にクライアントが指定したアルゴリズム。登録時に暗号化がOPと交渉され、IDトークンが暗号化されていない場合、RPはそれを拒否すべきです（SHOULD）。
2. OpenIDプロバイダの発行者識別子（一般に発見時に取得される）はiss（発行者）クレームの値と正確に一致しなければならない（MUST）。
3. クライアントは、aud（オーディエンス）クレームが、iss（発行者）クレームによってオーディエンスとして特定された発行者に登録されたclient_id値を含むことを検証しなければならない。 aud（オーディエンス）要求には、複数の要素を含む配列が含まれていてもよい（MAY）。 IDトークンが有効なオーディエンスとしてクライアントをリストしていない場合、またはクライアントによって信頼されていない追加のオーディエンスが含まれている場合、IDトークンは拒否されなければならない（MUST）。
4. IDトークンに複数のオーディエンスが含まれている場合、クライアントはazpクレームが存在することを確認する必要があります（SHOULD）。
5. azp（Authorized Party）クレームが存在する場合、クライアントはそのclient_idがクレーム値であることを確認すべきである（SHOULD）。
6. IDトークンがクライアントとトークンエンドポイント（このフローに含まれている）との直接通信を介して受信された場合、トークンシグネチャをチェックする代わりにTLSサーバ検証を使用して発行者を検証することができる。クライアントは、JWS alg Header Parameterで指定されたアルゴリズムを使用して、JWS [JWS]に従って他のすべてのIDトークンの署名を検証しなければならない（MUST）。クライアントは発行者によって提供された鍵を使用しなければならない（MUST）。
7. alg値は、RS256のデフォルト値、または登録時にid_token_signed_response_algパラメータでクライアントから送信されるアルゴリズムである必要があります。
8. JWT algヘッダーパラメーターがHS256、HS384、またはHS512などのMACベースのアルゴリズムを使用する場合、aud（オーディエンス）クレームに含まれるclient_idに対応するclient_secretのUTF-8表現のオクテットは、署名を検証するためのキー。 MACベースのアルゴリズムでは、audが複数の値を持つ場合、またはaud値とは異なるaz値が存在する場合、動作は指定されません。
9. 現在の時間は、exp要求によって表される時間より前でなければなりません。
10. iat要求を使用すると、現在時刻から離れすぎて発行されたトークンを拒否し、攻撃を防ぐためにnoncesを保存する必要がある時間を制限することができます。許容範囲はクライアント固有です。
11. Nonce値がAuthentication Requestで送信された場合、nonceクレームが存在し、その値が認証要求で送信されたものと同じ値であることを確認するためにチェックされていなければなりません。クライアントは、再生攻撃のナンス値をチェックすべきである（SHOULD）。リプレイ攻撃を検出する正確な方法は、クライアント固有です。
12. acrクレームが要求された場合、クライアントは、アサートされたクレーム値が適切であることを確認すべきである（SHOULD）。 ACRクレーム値の意味と処理は、この仕様の範囲外です。
13. この要求の特定の要求またはmax_ageパラメータを使用してauth_time要求が要求された場合、クライアントはauth_time Claim値をチェックし、最後のEndから経過時間が長すぎると判断した場合は再認証を要求します-ユーザ認証。

そして、あなたは、あなたが開発していたエンドポイントに基づいに位置OpenIDの接続メタデータドキュメントを使用して署名を検証するために必要な署名鍵データを取得することができる。

https://login.microsoftonline.com/common/.well-known/openid-configuration https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration