「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- OpenID Connect で OAuth 2.0 を拡張した主要な
クレーム（クレームセット）を格納するアサーション
- 仕様全体を通してメッセージ形式にJWT（アサーション）を採用。
- メッセージ形式：JWT（JSON Web Tokenの略）
- クレーム暗号化：JWTの JWS or JWE を使用する。
- 以下のクレームの値を含むクレームセット。
- 発行元のIdp（OP）識別子
- 発行先のRP識別子（client_id）
- ユーザー識別子
- 発行日時
詳細 †
クレームセット †
必須クレーム群 †
- iss (issuer) クレーム
- （OAuth 2.0で言う所の）Authorization Serverの識別子。
- URI形式が推奨
これは、OpenID Connect Discovery 1.0 仕様をサポートするのであれば、
「{issクレームの値}/.well-known/openid-configuration」という URL で
リクエストを受け付ける必要があるため。
- sub (subject) クレーム
ユーザーテーブルのプライマリーキーやそれに準ずるもの。
- aud (audience) クレーム
- client_idの値を含む。
- 複数要素の配列を含んでも良い (MAY)
- exp (expiration time) クレーム
- JWT の有効期限
- Unix エポックからの経過秒数（ミリ秒ではなく秒）
- iat (issued at)クレーム
- JWT の発行日時
- Unix エポックからの経過秒数（ミリ秒ではなく秒）
ケースバイケースなクレーム群 †
- auth_time クレーム
- ユーザー認証時刻
- Unix エポックからの経過秒数（ミリ秒ではなく秒）
- リクエスト・パラメタやメタ情報設定次第で必須となるもよう。
オプションのクレーム群 †
- acr クレーム
- 認証コンテキストのクラス
- 必要に応じて再認証を催す。
- 仕様で幾つか定義されているらしいが詳細不明。
- amr クレーム
- 認証手法を示す。
- 利用用途が不明。
- 仕様範囲外、クレームの利用者が規則を決めて運用する。
- azp クレーム
- 特に、aud が複数要素の配列の場合、azp で認可された対象者を明示する。
- 認証されたユーザと認可されたユーザが違うケースを想定している模様。
- Hybrid Flowの場合、以下のクレームは、
- Authorization Endpoint から返す場合、必須。
- 以下の場合、省略可能（あってもイイ）
- at_hash
- Access Token のハッシュ値
ID Token の JOSE Header にある alg Header Parameterのアルゴリズムで使用されるハッシュアルゴリズムを用い、
Access Token のASCII オクテット列からハッシュ値を求め、左半分を base64url エンコードした値。
- response_typeにid_tokenとtokenが含まれる時に必須だが、ソレ以外の場合は任意。
- c_hash
- Code のハッシュ値
ID Token の JOSE Header にある alg Header Parameterのアルゴリズムで使用されるハッシュアルゴリズムを用い、
Code のASCII オクテット列からハッシュ値を求め、左半分を base64url エンコードした値。
- response_typeにcodeとid_tokenが含まれる時に必須だが、ソレ以外の場合は任意。
その他、ユーザー属性クレーム群を格納する。
外部クレーム †
Idp（OP）は、扱うクレームの内容によって、
どちらを利用すべきかを判断する必要がある。
集約クレーム（Aggregated Claims） †
- 別のIdp（OP）が持つクレームを署名付きで提供すること。
- RPからリクエストを受けたIdp（OP）は、事前に取得していた、
もしくは動的に取得した別のIdp（OP）のクレームをレスポンスに含む。
一定期間変更されないことが保証されており
キャッシュの効果があるものは集約クレーム。
分散クレーム（Distributed Claims） †
クレームそのものではなく、問い合わせ先のURLを扱う。
- ユーザー認可が必要な場合
- エンドポイントのURL
- OAuth 2.0のアクセストークン
をレスポンスに含む。
頻繁に更新されるものは分散クレーム。
検証処理 †
Clientは、IDトークンを検証する。
基本的な検証処理 †
- Client は Issuer から提供された鍵を利用しなければならない (MUST).
- alg の値は (SHOULD)
- デフォルトの RS256
- もしくは Registration によるid_token_signed_response_alg パラメタ値
- iss Claimの検証（Discovery で取得したIssuer値に一致）。
- aud Claim or azp Claimの検証
- aud Claim に 自身の client_id が含まれることを確認する。
- aud Claimが複数要素の配列の場合、azp Claim に含まれることを確認すべき。
- Time
- exp Claimの検証（現在時刻より後）。
- iat Claimの検証（Clientから見て古過ぎない、nonce 保存期間を制限）。
- auth_time Claimの検証（max_ageを使用してチェックし再認証を要求）。
- OIDC
- nonce Claimの検証。
- acr Claimの検証（適切かどうかをチェック、値と意味は仕様の対象外）
- Hash
- at_hash Claimの検証。
- c_hash Claimの検証。
フロー毎の差異 †
Google †
GoogleでOpenID Connectの認証で取得したクレームセット。
（id_tokenそのものなのか？、ユーザー情報エンドポイントから取得したクレームか？）
{
"iss":"accounts.google.com",
"at_hash":"・・・", ← Hybrid Flowの追加クレーム
"email_verified":"true",
"sub":"ユーザーの一意識別子",
"azp":"認可された対象者のID.apps.googleusercontent.com",
"email":"・・・・",
"aud":"クライアント識別子.apps.googleusercontent.com",
"iat":JWT の発行日時（Unix時間）,
"exp":JWT の有効期限（Unix時間）
}
ココを見ると、これは恐らく、id_tokenなのだろうなと。
以下のGoogle公式のマニュアルにも記載があった。
参考 †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
