OAuth2.0とOpenID Connectについて整理する

1. はじめに

最近業務の中でOAuth2.0及びOpenID Connectの仕組みについて理解を深める機会があったので、そこで学んだ内容を自分なりにまとめてみました。(まだ完璧な理解には程遠いですが...）補足、不備等あればご指摘いただけると幸いです。

2. OAuth2.0とOIDC

OAuth2.0 = 認可（Authorization）のためのプロトコル
OIDC（OpenID Connect） = OAuth2.0の上に「認証（Authentication）」を乗せたプロトコル

OAuth2.0でなにを「認可」するのかというと、サードパーティアプリ(例.美容室予約アプリ)からリソースサーバ(例.Google Calendar API)へのアクセスを認可します。
その結果、例えば美容室予約アプリからGoogleカレンダーに予定を追加といった操作ができるようになり、より便利にアプリを利用することができます。
ただOAuth2.0は「認可」の仕組みなので、「認証」は保証してくれません。OIDCはそこを補います。

3. 登場人物

名前	役割	具体例
リソースオーナー	データの持ち主（ユーザ）	Googleアカウントのユーザー
クライアント	アクセスしたいアプリ	美容室予約アプリ
認可サーバー	権限を発行するサーバー	Googleの認証基盤
リソースサーバー	実際のデータを持つサーバー	Google Calendar API

4. 認可コードフロー

4-1 基本的な流れ

なんやらごちゃごちゃしてますが、要はOAuth2.0の目的はリソースサーバへのアクセストークンを取得することです。そのために以下2つの手順を実施します。

1. 認可リクエスト：認可サーバに認可リクエストを飛ばします。このレスポンスとして認可コードを取得します。
2. トークンリクエスト：認可リクエストで取得した認可コードをもとにトークンリクエストを行い、アクセストークンを取得します。

※各リクエストの具体的なリクエストパラメータについては7節でまとめていますが、認可リクエスト時のscopeに"openid"を含めることで認可サーバーにOIDCリクエストとして解釈され、アクセストークンに加えてIDトークンを取得することができます。

4-2 アクセストークンとIDトークン

アクセストークンはAPIへのアクセス用の「鍵」、IDトークンはユーザーが誰かを証明する「身分証明書」といったイメージです。OIDCでは認可サーバーが IDトークン（JWT形式） を発行します。

※JWTの構造

JWTは.で区切られた3つのパーツで構成されています。

① ヘッダー（Header） : 署名アルゴリズムとトークンの種類を示します。
② ペイロード（Payload） : ユーザー情報やトークンのメタデータ（クレーム）が含まれます。
③ 署名（Signature） : ヘッダーとペイロードを認可サーバーの秘密鍵で署名したものです。

※ペイロードの構造例

フィールド	意味
iss	トークンを発行したサーバー（Issuer）
sub	ユーザーの一意なID（Subject）
aud	このトークンの受け取り手（自アプリのクライアントID）
iat	発行日時
exp	有効期限

5. トークン取得後の認証認可の流れ

5-1 ログイン時（OIDCによる認証）

IDトークンを取得したあと、アプリ側では以下の流れでログイン処理を行います。

1. IDトークンを取得する — トークンエンドポイントのレスポンスから取得
2. 署名を検証する — 認可サーバーの公開鍵（JWKSエンドポイント）で検証
3. クレームを検証する — iss / aud / exp / nonce が正しいか確認
4. ユーザーを特定する — sub でDBを検索し、存在しなければ新規登録
5. セッションを発行する — ログイン完了

5-2 API呼び出し時（認証 + 認可）

ログイン後にAPIを呼び出す際は、認証と認可の2段階で確認が行われます。

1. セッションチェック（認証） — 「誰からのリクエストか」を確認。無効なら 401 Unauthorized
2. アクセストークンチェック（認可） — 「このAPIを呼ぶ権限があるか」を確認。権限なしなら 403 Forbidden

6. セキュリティパラメータを理解する

パラメータ	検証者	守っているもの	防いでいる攻撃	他のパラメータとの違い
state	クライアント	ユーザーのセッション	CSRF攻撃（他人のコードを押し付けられる）	PKCE が「コードの盗難」を防いでも、state がないと「自分のコードを他人に踏ませる」攻撃が防げない
PKCE	認可サーバー	認可コード	横取り攻撃（コードを盗んでトークンに交換される）	state が「正しいセッション」を保証しても、コード自体が盗まれたら PKCE がないとトークンを奪われる
nonce	クライアント	身分証明書の鮮度	リプレイ攻撃（過去のトークンを使い回される）	state や PKCE は「手続き」を守るが、nonce は「発行された後のトークン」の再利用を直接防ぐ
at_hash	クライアント	アクセストークンの正当性	すり替え攻撃（別フローのトークンを混入される）	他の3つは「正しいフローかどうか」を守るが、at_hash は「セットで発行されたトークンかどうか」を守る

※１ CSRF攻撃において自分の認可コードを他人に踏ませると攻撃者にとってなにが嬉しいのか

CSRF攻撃について具体的な問題が理解しずらかったので、攻撃者側のメリットをまとめました。

📌パターン1(攻撃者が仕込んだ認可コードに対応するスコープがGoogleIDの連携機能だった場合)

アプリ側は「被害者が自分のアカウントに、このGoogle IDを紐付けようとしている」と誤認し、被害者のデータと攻撃者のGoogle IDを連結してしまいます。(※このGoogleIDはIDトークンのsubクレームとして含まれます。)
その結果攻撃者は自分のgoogleアカウント情報で、被害者のアカウントとしてログインができてしまいます。(これえぐい...)

📌パターン2(攻撃者が仕込んだ認可コードに対応するスコープがリソースサーバへのアクセス権限だった場合)

このとき攻撃者は被害者のリソースにアクセスすることはできませんが、逆に被害者が攻撃者のリソースにアクセスしてしまいます。その事実に気づかず被害者がアカウント情報等を入力すると、その情報が攻撃者に筒抜けになってしまいます。(これもえぐい...)

※２ PKCEの防御対象について

認可コードの横取りを防ぐと書きましたが、セッションIDをキーにcode_verifierを管理している構成ならPKCEが実質的にCSRFも防げます。

7. リクエストパラメータまとめ

これまでの内容を踏まえ、認可コードフローで実際に送るリクエストのパラメータを一覧にまとめてみました。

7-1 認可リクエスト（Authorization Request）

認可サーバーの認可エンドポイントへGETリクエストで送るパラメータです。

パラメータ	必須/任意	説明
response_type	必須	レスポンスの種類。認可コードフローでは code を指定
client_id	必須	クライアントアプリの識別子。認可サーバーへの事前登録時に発行される
redirect_uri	推奨	認可後にリダイレクトされるURL。事前登録したURIと一致している必要がある
scope	推奨	要求するアクセス権限の範囲（例: openid email profile）。openid を含めるとOIDCリクエストになる
state	推奨	CSRF攻撃防止用のランダムな文字列。コールバック時にそのまま返却され、クライアントが検証する
code_challenge	PKCE使用時	code_verifier をSHA-256でハッシュしBase64URLエンコードした値
code_challenge_method	PKCE使用時	ハッシュアルゴリズムの指定。通常 S256
nonce	OIDCで推奨	リプレイ攻撃防止用のランダムな文字列。IDトークンのクレームに埋め込まれる

7-2 トークンリクエスト（Token Request）

認可サーバーのトークンエンドポイントへPOSTリクエストで送るパラメータです。

パラメータ	必須/任意	説明
grant_type	必須	認可の種類。認可コードフローでは authorization_code を指定
code	必須	認可リクエストのレスポンスとして取得した認可コード
redirect_uri	条件付き必須	認可リクエストに redirect_uri を含めた場合は必須。同じ値を指定する
client_id	条件付き必須	公開クライアント（モバイル・SPAなど）の場合は必須
client_secret	機密クライアントのみ	サーバーサイドアプリなど、秘密を安全に保管できるクライアントのみ使用
code_verifier	PKCE使用時	認可リクエスト時に生成した元の乱数。認可サーバーが code_challenge と照合する

※トークンリクエスト時はリダイレクトされませんが、認可リクエストと同じ値かどうかをチェックするために設定するようです。