OIDC ― OAuthに認証結果を伝える仕組みを足す

IDトークンとアクセストークンを色分けし、nonce・issとsub・UserInfoの役割を整理します。

OAuthに、認証結果を伝える層を足す

OpenID Connect（OIDC）は、OAuth 2.0を土台に、利用者の認証結果をクライアントへ伝える仕組みです。ログインを受け入れるアプリをRP、認証を行う提供者をOPと呼びます。

OAuthのアクセストークンはAPIへのアクセス用でした。OIDCでは、それに加えてIDトークンという認証結果を使います。OpenID Connect Core

この教材はAuthorization Code Flowの例です。画面の雰囲気だけで「OAuthログイン」と覚えず、何がアプリへ返るかを追ってみましょう。

アプリは scope=openid を含む認証リクエストを送ります。必要に応じて profile なども要求します。PKCEやリクエストとの対応確認も、採用するフローに従って組み込みます。

この例では、リクエストにランダムな nonce を付け、アプリ側に記憶します。IDトークンに返る値と照合するためです。

nonce とPKCEの code_verifier は別の値です。前者はIDトークンと認証リクエストを結び付け、後者は認可コードの交換を保護します。認証リクエスト

利用者がOPで認証され、アプリが受け取った認可コードを交換します。コードフローの成功応答にはIDトークンとアクセストークンが含まれます。

図では、紫のIDトークンと緑のアクセストークンを分けて描きます。IDトークンは、このアプリへ認証結果を伝えます。アクセストークンは、許可されたAPIへアクセスするために使います。

この二つを同じ「ログインした証拠」として、好きな場所へ渡してよいわけではありません。トークン応答

アプリは信頼するOPとアルゴリズムのもとで署名などを検証し、iss が想定するOPか、aud が自分のクライアントIDを含むか、有効期限を過ぎていないかを確認します。nonce を送ったなら、その一致も必須です。

複数のaudienceや azp など、条件付きの検証もあります。実装では規格に対応したライブラリを使い、必要な設定を省略しません。IDトークンの検証

図の三つの関門は、署名・宛先・リクエストとの結び付きを表しています。

同じ sub という文字列でも、別のOPが発行したなら別人かもしれません。通常は発行者issと、その発行者のもとでのsubの組を利用者との結び付けに使います。

メールアドレスは変わることがあり、OPの扱いによっては再割当てもあります。email_verified が真でも、すべてのサービス間で同じ人を永久に表す識別子になるわけではありません。

図では同じ「123」という札の上に、異なる発行者の札が載っています。同じ文字列を見ただけでアカウントを統合しない理由です。クレームの安定性

アプリはアクセストークンを使ってUserInfoエンドポイントを呼び、許可されたプロフィール情報を得られます。UserInfoの sub はIDトークンの sub と一致するか確認します。

ログイン後は、アプリ自身のセッションや権限モデルへ接続します。OIDCが「教材Xの編集者は誰か」まで決めるわけではありません。

図では緑のトークンがUserInfoへ進み、紫のIDトークンはアプリに残ります。IDトークンを任意のAPI用Bearerトークンとして流用しないことがポイントです。UserInfo応答

答えはこのログインを受け入れるクライアントです。IDトークンはアプリへ認証結果を伝え、アクセストークンは指定されたAPIへのアクセスを担います。

OIDCを読むときは、「誰が認証したか」「どのアプリに向けた結果か」「どのリクエストに対応するか」を確認してください。

OAuthはアクセスの委譲、OIDCは認証結果の伝達、JWTはそれらで利用されることがあるデータ形式。この三つを役割で分けると、同じ通信に登場しても混乱しにくくなります。