Webサービスのログイン機能を調べると、OAuth 2.0、OpenID Connect（OIDC）、CIAMという言葉が並んで登場する。これらは関連しているが、同じものではない。本記事では、三者の役割と処理の流れ、解決できる課題を整理する。
1. 基礎概念
OAuth 2.0は「権限を委譲する」ための枠組み
OAuth 2.0は、利用者がパスワードを外部サービスへ渡さずに、自分のデータへアクセスする権限を委譲するための認可フレームワークである。
登場人物は主に四者。
- Resource Owner：データの所有者
- Client：データを利用したいアプリケーション
- Authorization Server：利用者の同意を確認し、トークンを発行する
- Resource Server：APIと保護対象データを持つ
OAuth 2.0が扱う中心的な問いは、「このClientに、どのAPIを、どの範囲で利用させるか」である。OAuth 2.0単体は、ログインした人物の身元をClientへ伝える標準を定めていない。
OpenID Connectは「誰がログインしたか」を伝える
OIDCは、OAuth 2.0の上に構築された認証プロトコルである。Authorization Serverに相当するOpenID Providerが認証を行い、その結果をID TokenとしてClientへ伝える。
ID Tokenは通常JWT形式で、発行者、対象Client、利用者の識別子、有効期限、認証時刻などのClaimを含む。Clientは署名、発行者、対象者、有効期限などを検証しなければならない。
Access TokenがAPIへのアクセス権を表すのに対し、ID Tokenは認証結果をClientへ伝える。この二つを混同してはいけない。
CIAMは顧客向けID管理の仕組み
CIAM（Customer Identity and Access Management）は、消費者や取引先など、社外ユーザーのIDを管理する製品領域またはシステム設計を指す。
典型的な機能には、会員登録、ログイン、SSO、ソーシャルログイン、多要素認証、アカウント復旧、同意管理、不正アクセス対策、プロフィール管理がある。OAuth 2.0やOIDCはCIAMを構成する技術になり得るが、CIAMそのものは単一の通信規格ではない。
2. 技術フロー
OIDCのAuthorization Code Flowを単純化すると、次のようになる。
利用者
│ 1. ログイン開始
▼
Client ── 2. 認証要求 ──▶ OpenID Provider
▲ │
│ │ 3. 認証・同意
│ 4. Authorization Code ▼
└──────────────────────── 利用者
│
│ 5. CodeをToken Endpointへ送信
▼
OpenID Provider
│ 6. ID Token / Access Token
▼
Client実運用では、Clientは`state`でリクエストとレスポンスを対応付け、`nonce`でID Tokenの再利用を防ぐ。公開Clientでは、Authorization Codeの横取り対策としてPKCEを使う。受け取ったID Tokenは、署名だけでなく`iss`、`aud`、`exp`、`nonce`なども検証する。
複数サービスが同じOpenID Providerを利用すれば、一度の認証で複数サービスへアクセスするSSOを構成できる。ただし、セッションの有効期間、再認証条件、ログアウトの伝播は別途設計が必要である。
3. 何を解決できる技術か
OAuth 2.0は、パスワード共有を避けながらAPIアクセスを委譲する。OIDCは、サービスごとに認証機能を個別実装する負担を減らし、標準化された方法で認証結果を連携する。CIAMは、それらを顧客向けの登録・認証・セキュリティ・運用として統合する。
一方、導入するだけで安全になるわけではない。トークンの漏えい、リダイレクトURIの不備、アカウント統合の誤り、長すぎるセッションなどは実装と運用の問題として残る。また、認証基盤を集約すると利便性は上がるが、障害や侵害の影響範囲も広がる。
三者の関係は、次のように整理できる。
– OAuth 2.0：何を許可するか
– OIDC：誰が認証されたか
– CIAM：顧客IDをどう登録・保護・運用するか
実装時に理解すべき補足
OAuth 2.0では認可範囲をScopeで表す。写真閲覧、予定表の読み取り、投稿作成を別々のScopeに分ければ、利用者は必要最小限の権限だけを渡せる。ただし、Scopeの粒度と意味はAuthorization Server側の設計事項である。`read`のような広すぎるScopeでは、何を許可するのか判断しにくい。
Bearer型Access Tokenは、所持者が権限を行使できる資格情報である。Resource Serverは発行者、有効期限、Scope、対象Resourceを検証する。Access TokenがJWTとは限らず、Clientが内容を認証結果として使うべきでもない。
OIDCでは利用者の安定した識別子として`sub`を使う。`sub`は発行者を示す`iss`と組み合わせて初めて一意になる。メールアドレスは変更や再割り当てが起こり得るため、内部アカウントの主キーには適さない。外部アカウント連携でも、メールアドレスが同じという理由だけで統合すると乗っ取りにつながる。
Authorization Code FlowではClientはパスワードを受け取らない。公開ClientはPKCEを使い、Codeと`code_verifier`を結び付ける。攻撃者がCodeだけを横取りしてもTokenへ交換できない。OIDC DiscoveryによってEndpointや署名検証鍵の取得先を知り、鍵のローテーションにはJWKSと`kid`で追従する。
Refresh Tokenは再ログインなしにAccess Tokenを更新するために使う。長期間有効になり得るため、暗号化保存、Rotation、失効、再利用検知が必要になる。
認証と本人確認も異なる。認証は登録済み資格情報の制御を確認する。本人確認はアカウントを現実の人物へ結び付ける。OIDCで正常にログインできても、登録された氏名や住所が真正だとは限らない。
CIAMの品質はログイン成功率だけでは測れない。登録完了率、認証失敗率、復旧成功率、不正検知率、問い合わせ件数、所要時間を組み合わせて評価する。基盤の集約は重複実装を減らす一方、障害や侵害の影響範囲を広げるため、高可用性、監査、緊急失効まで設計する必要がある。
参考資料
– [OAuth 2.0 Authorization Framework（RFC 6749）](https://www.rfc-editor.org/rfc/rfc6749)
– [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)
– [OAuth 2.0 Security Best Current Practice（RFC 9700）](https://www.rfc-editor.org/rfc/rfc9700)