3.1.3.7. ID Token Validationを読んだ際のざっくりメモ

更新日：2025/3/13/(木) 12:38

タグ：認証・認可、OIDC

概要

• 3.1.3.7. ID Token Validationを読む機会があったのでものすごくざっくりしたメモ https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#TokenResponseValidation

1

• ID Token が 暗号化されているならば, Client が Registration にて指定し OP が ID Token の暗号化に利用した鍵とアルゴリズムを用いて復号する.
• Registration 時に OP と暗号化が取り決められても ID Token が暗号化されていなかったときは, RP はそれを拒絶するべき (SHOULD).

メモ

• ID Token・・・OIDCの認可フローを通じて、OPから発行される。JWTが使われることが多い
• Client・・・クライアントアプリ
• Registration・・・OPにClientを登録する事前手続き的なもの
• OP・・・OpenID Provider(認証サーバー)。ID Token や Access Token を発行する
• PR・・・Relying Party (リライング パーティ)。OPを利用してログインできるサイトやサービスのこと。Clientとほぼ同じ？
• 「ID Token が暗号化されていなかったとき」とはどんな状況？

2

• (一般的に Discovery を通して取得される) OpenID Provider の Issuer Identifier は iss (issuer)
• Claim の値と正確に一致しなければならない (MUST).

メモ

• Discovery・・・ClientがOPの設定を動的取得できる仕組み。手動設定作業が削減される？
• Issuer Identifier・・・OPの識別子。違うシステムや認証基盤との区別に必要
• iss (issuer) Claim・・・OPの識別子。ID Tokenに含まれる

3

• Client は aud (audience) Claim が iss (issuer) Claim で示される Issuer にて登録された, 自身の client_id をオーディエンスとして含むことを確認しなければならない (MUST).
• aud (audience) Claim は複数要素の配列を含んでも良い (MAY).
• ID Token が Client を有効なオーディエンスとして記載しない, もしくは Client から信用されていない追加のオーディエンスを含むならば, そのID Token は拒絶されなければならない.

メモ

• aud (audience) Claim・・・ID Tokenの対象者。ID Tokenに含まれる

4

• ID Token が複数のオーディエンスを含むならば, Client は azp Claim があることを確認すべき (SHOULD).

メモ

• azp (authorized party) Claim ・・・- ID TokenがどのClientに属しているかを示す。ID Tokenに含まれる

5

• azp (authorized party) Claim があるならば, Client は Claim の値が自身の client_id であることを確認すべき (SHOULD).

メモ

• 4とほぼ同じ内容？4でazpの存在確認をしてから5のチェックに移る的な？

6

• (このフローの中で) ID Token を Client と Token Endpoint の間の直接通信により受け取ったならば, トークンの署名確認の代わりに TLS Server の確認を issuer の確認のために利用してもよい (MAY).
• Client は JWS [JWS] に従い, JWT alg Header Parameter を用いて全ての ID Token の署名を確認しなければならない (MUST).
• Client は Issuer から提供された鍵を利用しなければならない (MUST).

メモ

• JWT alg Header Parameter・・・- 署名または暗号化に使用されたアルゴリズムを記載
• 「TLS Server の確認を issuer の確認のために利用してもよい (MAY). 」はTLS証明書の確認ができればissuerの確認は不要ということ？

7

• alg の値はデフォルトの RS256 もしくは Registration にて Client により id_token_signed_response_alg パラメータとして送られたアルゴリズムであるべき (SHOULD).

メモ

• id_token_signed_response_alg・・・Clientは自身がサポートする署名アルゴリズムをOPに対して事前に設定できる

8

• JWT alg Header Parameter が HS256, HS384 および HS512 のような MAC ベースのアルゴリズムを利用するならば, aud (audience) Claim に含まれる client_id に対応する client_secret の UTF-8 表現バイト列が署名の確認に用いられる.
• MAC ベースのアルゴリズムについて, aud が複数の値を持つとき, もしくは aud の値と異なる azp の値があるときの振る舞いは規定されない.

メモ

• client_secret・・・Clientが認証されるために使う秘密鍵

9

• 現在時刻は exp Claim の時刻表現より前でなければならない (MUST).

メモ

• exp Claim・・・expiration time。ID Tokenの有効期限。ID Tokenに含まれる

10

• iat Claim は現在時刻からはるか昔に発行されたトークンを拒絶するために利用でき, 攻撃を防ぐために nonce が保存される必要がある期間を制限する.
• 許容できる範囲は Client の仕様である.

メモ

• iat Claim・・・Issued At。ID Tokenの発行時刻。ID Tokenに含まれる
• nonce・・・- ランダムな一意の値で、主にリプレイ攻撃を防ぐために使われる。ID Tokenに含まれる

11

• nonce の値が Authentication Request にて送られたならば, nonce Claim が存在し, その値が Authentication Request にて送られたものと一致することを確認するためにチェックされなければならない (MUST).
• Client は nonce の値を リプレイアタックのためにチェックすべき (SHOULD).
• リプレイアタックを検知する正確な方法は Client の仕様である.

メモ

• リプレイアタック・・・過去の通信データを再送信して不正を試みる攻撃手法

12

• acr Claim が 要求されたならば, Client は主張された Claim の値が適切かどうかをチェックすべきである (SHOULD).
• acr Claim の値と意味はこの仕様の対象外である.

メモ

• acr Claim・・・Authentication Context Class Reference。ユーザー認証の強度やコンテキストを示す。ID Tokenに含まれる

13

• auth_time Claim が要求されたならば, この Claim のための特定のリクエストもしくは max_age パラメータを用いて Client は auth_time Claim の値をチェックし, もし最新のユーザー認証からあまりに長い時間が経過したと判定されたときは再認証を要求すべきである (SHOULD).

メモ

• auth_time Claim・・・ユーザーが最後に認証された日時。ID Tokenに含まれる
• max_ageパラメータ・・・認証の有効期間

締め

• 理解度はまだ浅いのでOIDCも含めキャッチアップしていきたい
• 実装を通して理解を深めていきたい