「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Finalを参照して記述。
- OpenID Connect で OAuth 2.0 を拡張した主要な
クレーム(クレームセット)を格納するアサーション
- 仕様全体を通してメッセージ形式にJWT(アサーション)を採用。
- 以下のクレームの値を含むクレームセット。
- 発行元の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 エポックからの経過秒数(ミリ秒ではなく秒)
- リクエスト・パラメタやメタ情報設定次第で必須となるもよう。
オプションのクレーム群 †
- amr クレーム
認証手法を示す。クレームの利用者が規則を決めて運用する。
- azp クレーム
- 特に、aud が複数要素の配列の場合、azp で認可された対象者を明示する。
- 認証されたユーザと認可されたユーザが違うケースを想定している模様。
Hashクレーム †
- Authorization Endpoint からIDトークンを返す場合、必要になる。
- Hashクレームの種類
- at_hash: Access Token のハッシュ値
- Access Tokenを合わせて返す場合に追加可能になる。
- response_typeにid_tokenとtokenが含まれる時に必須、ソレ以外の場合は任意。
- ID Token の JOSE Header にある alg Header Parameterのアルゴリズムで使用されるハッシュアルゴリズムを用い、
Access Token のASCII オクテット列からハッシュ値を求め、左半分を base64url エンコードした値。
- c_hash: Code のハッシュ値
- Codeを合わせて返す場合に追加可能になる。
- response_typeにcodeとid_tokenが含まれる時に必須だが、ソレ以外の場合は任意。
- ID Token の JOSE Header にある alg Header Parameterのアルゴリズムで使用されるハッシュアルゴリズムを用い、
Code のASCII オクテット列からハッシュ値を求め、左半分を base64url エンコードした値。
その他、ユーザー属性クレーム群を格納する。
外部クレーム †
Idp(OP)は、扱うクレームの内容によって、
どちらを利用すべきかを判断する必要がある。
集約クレーム(Aggregated Claims) †
- 別のIdp(OP)が持つクレームを署名付きで提供すること。
- RPからリクエストを受けたIdp(OP)は、事前に取得していた、
もしくは動的に取得した別のIdp(OP)のクレームをレスポンスに含む。
一定期間変更されないことが保証されており
キャッシュの効果があるものは集約クレーム。
分散クレーム(Distributed Claims) †
クレームそのものではなく、問い合わせ先のURLを扱う。
- ユーザー認可が必要な場合
- エンドポイントのURL
- OAuth 2.0のアクセストークン
をレスポンスに含む。
頻繁に更新されるものは分散クレーム。
検証処理 †
Clientは、IDトークンを検証する。
基本的な検証処理 †
- Client は Issuer から提供された鍵を利用しなければならない (MUST).
- audクレーム or azpクレームの検証
- audクレームに 自身の client_id が含まれることを確認する。
- audクレームが複数要素の配列の場合、azpクレームに含まれることを確認すべき。
- Time
- expクレームの検証(現在時刻より後)。
- iatクレームの検証(Clientから見て古過ぎない、nonce 保存期間を制限)。
- auth_timeクレームの検証(max_ageを使用してチェックし再認証を要求)。
- OIDC
- acrクレームの検証(適切かどうかをチェック、値と意味は仕様の対象外)
フロー毎の差異 †
- Authorization Code Flow
- JWS署名の検証 / JWE暗号の復号
- Token Endpoint の間の直接通信により受け取った場合、
トークンの署名確認の代わりに TLS で issuer を確認してもよい (MAY).
- OPTIONAL
- nonceクレームの検証。
- c_hashクレームの検証(Authorization Endpoint)。
- at_hashクレームの検証(Token Endpoint)。
- Implicit Flow
- JWS署名の検証のみ(JWE暗号の復号は不可)
- REQUIRED
- nonceクレームの検証。
- at_hashクレームの検証("id_token token"の場合)。
- Hybrid Flow
- nonceクレームの検証。
- Authorization Endpoint
- JWS署名の検証のみ(JWE暗号の復号は不可)
- c_hashクレームの検証。
- at_hashクレームの検証。
- Token Endpoint
- JWS署名の検証 / JWE暗号の復号
- at_hashクレームの検証。
Google †
GoogleでOpenID Connectの認証で取得したクレームセット。
(id_tokenそのものなのか?、ユーザー情報エンドポイントから取得したクレームか?)
{
"iss":"accounts.google.com",
"at_hash":"・・・", ← Implicit or 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公式のマニュアルにも記載があった。
参考 †
- IDトークンが分かれば OpenID Connect が分かる - Qiita
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :OAuth