OpenID ConnectのクレームとIDトークン

OpenID Connect（OIDC）は、OAuth 2.0の上にアイデンティティレイヤーを追加します。OAuth 2.0が認可（このアプリは何にアクセスできるか）を扱うのに対し、OIDCはアイデンティティ（ユーザーは誰か）に関する問いに答えます。OIDCは、OAuth 2.0リクエストに「openid」スコープを追加することで実装されます。これにより、認可サーバーはアクセストークンとともにIDトークンを返します。

OIDCのIDトークンは、認証されたユーザーに関するクレームを含むJSON Web Token（JWT）です。JWTは通常、認可サーバーの秘密鍵（RS256またはES256）で署名されます。依存当事者（クライアントアプリケーション）は、認可サーバーが公開している公開鍵（JWKSエンドポイント）を使用して署名を検証します。

必須または一般的に使用されるIDトークンのクレームは、「sub」（subject、ユーザーを一意に識別する識別子）、「iss」（issuer、認可サーバーのURL）、「aud」（audience、client ID）、「exp」（有効期限を示すUnixタイムスタンプ）、「iat」（発行時刻を示すUnixタイムスタンプ）です。オプションのクレームには、「auth_time」（認証が行われた時刻）、「nonce」（リプレイ防止）、「at_hash」（アクセストークンのハッシュ）、「acr」（認証コンテキストクラス）、「amr」（使用された認証方式）があります。

OIDCのUserInfoエンドポイントは、有効なアクセストークンを使って呼び出されると、認証されたユーザーに関する追加のクレームを返します。クライアントはスコープを使って要求するクレームのセットを指定します。「profile」はname、picture、localeを、「email」はemail、email_verifiedを、「address」はformatted addressを、「phone」はphone_number、phone_number_verifiedを返します。UserInfoのレスポンスはJSONオブジェクトまたはJWTです。

IDトークンの検証は、署名の検証から始まります。クライアントは、well-knownエンドポイントから認可サーバーのJWKS（JSON Web Key Set）を取得し、JWTヘッダーの「kid」（キーID）パラメーターに一致する鍵を見つけて、JWTの署名を検証します。これにより、そのトークンが正規の認可サーバーによって発行されたものであり、改ざんされていないことを確認できます。

署名を検証した後、クライアントは次の項目を検証する必要があります。「iss」は、想定する認可サーバーのURLと完全に一致しなければなりません（スキームとパスも含みます）。「aud」にはクライアント自身のclient_idが含まれていなければなりません。「exp」は未来の時刻でなければなりません（期限切れのトークンは拒否します）。「iat」は妥当な範囲で新しい値である必要があります。これら4つの確認は、OIDC仕様で必須とされています。

nonceクレームは、IDトークンのリプレイ攻撃を防ぎます。クライアントはランダムなnonceを生成し、認可リクエストに含めます。認可サーバーは、そのnonceをIDトークンに埋め込みます。クライアントは、IDトークン内のnonceが送信した値と一致することを検証します。これにより、攻撃者が取得したIDトークンを別のセッションで認証に再利用することを防ぎます。

OIDCでインプリシットフロー（response_type=id_token）を使用すると、IDトークンはURLフラグメントに直接返されます。クライアントは、アクセストークンのハッシュであるat_hashを検証して、アクセストークンをIDトークンに結び付ける必要があります。at_hashを検証しないと、アクセストークン置換攻撃が可能になります。これも、インプリシットフローが非推奨とされている理由の1つです。

OIDCは、スコープとクレームの標準的な対応関係を定義しています。「openid」スコープは必須で、「sub」クレームを返します。「profile」はname、given_name、family_name、nickname、picture、website、locale、zoneinfo、updated_atを返します。「email」はemailとemail_verifiedを返します。不要なスコープを要求することは、最小限の開示という原則に反し、ユーザーの機密データを意図せず公開する可能性があります。

OIDCで複数プロバイダーのログイン（たとえば「Sign in with Google」や「Sign in with GitHub」）を実装する場合、クレームインジェクション攻撃が発生する可能性があります。攻撃者が、Provider Aを利用する被害者のメールアドレスでProvider Bにアカウントを作成すると、アプリケーションがメールクレームだけでアカウントを照合している場合、攻撃者がアクセス権を得る可能性があります。アカウントはメールアドレスだけでなく、必ず（iss、sub）の組み合わせで照合してください。

OIDCのハイブリッドフロー（response_type=code id_token）は、認可エンドポイントから認可コードとIDトークンの両方を返します。IDトークンによってすぐにアイデンティティを検証できる一方、コードはバックチャネル経由でトークンと交換されます。バックチャネルでのトークン交換を完了する前に、ユーザー情報をすぐに表示する必要がある場合に使用します。

OIDCのIDトークンでは、依存当事者はどのクレームの組み合わせを検証する必要がありますか？

OIDCは、OAuth 2.0フローに署名付きのJWT IDトークンを追加します。署名（JWKS）、iss（完全一致）、aud（client_id）、exp（期限切れでないこと）、nonce（送信した場合）を検証してください。UserInfoエンドポイントは、スコープを通じて追加のクレームを提供します。クレームインジェクションを防ぐため、アカウントはメールアドレスだけでなく、（iss、sub）の組み合わせで照合してください。インプリシットフローは非推奨です。OIDCには、PKCEを使用する認可コードフローを使ってください。