目次
1. 結論（早見表）
| やりたいこと | 選ぶべきプロトコル |
|---|---|
| ユーザーをログインさせたい（新規開発のWeb・モバイル・SPA） | OpenID Connect (OIDC) |
| API へのアクセス権を委譲したい（「このアプリにGoogleカレンダーの読み取りを許可」など） | OAuth 2.0 / 2.1 |
| 既存のエンタープライズIdP（ADFS、古い社内SSO）と企業向けSSOを連携したい | SAML 2.0（新規ならOIDCも検討） |
| サーバー間（M2M）でAPIを呼びたい | OAuth 2.0 Client Credentials |
| ログイン ＋ API アクセスの両方 | OIDC（＝OAuth 2.0の上に乗っている） |
一言で言うと：認証（誰か）＝OIDC / SAML、認可（何をしてよいか）＝OAuth。
2. それぞれの役割
OAuth 2.0
- 認可（Authorization） のためのフレームワーク。
- 「ユーザーのパスワードを渡さずに、第三者アプリにリソースへの限定的なアクセス権を与える」ためのもの。
- 発行されるのは アクセストークン。これは「APIを呼ぶ権利」を表すもので、ユーザーが誰かを証明するものではない。
- 主な用途：外部API連携、自社API保護、M2M通信。
OpenID Connect (OIDC)
- OAuth 2.0 の上に構築された認証（Authentication）レイヤー。
- OAuth のフローに ID トークン（JWT） と UserInfo エンドポイントを追加し、「ユーザーが誰か」を標準的に伝えられるようにしたもの。
- JSON / REST ベースで、モバイル・SPA・マイクロサービスと相性が良い。
- 主な用途：ソーシャルログイン、自社サービスのSSO、モダンなIdP（Entra ID、Okta、Auth0、Keycloak、Cognito 等）との連携。
SAML 2.0
- XML ベースの認証・SSO 標準（2005年〜）。
- IdP が署名付きの SAML アサーションを発行し、ブラウザのリダイレクト／POST 経由で SP に渡す。
- エンタープライズ領域で長い実績があり、多くの SaaS・社内システムが対応。
- 主な用途：企業向け SaaS の SSO、レガシーな社内IdPとの連携。
- 弱点：ネイティブアプリ・SPA・API 保護には不向き、XML署名検証の実装が難しく脆弱性を生みやすい。
3. 比較表
| 観点 | OAuth 2.0 | OIDC | SAML 2.0 |
|---|---|---|---|
| 目的 | 認可 | 認証（＋認可） | 認証（SSO） |
| トークン形式 | アクセストークン（形式は規定なし、JWTか不透明トークン） | IDトークン（JWT）＋アクセストークン | SAMLアサーション（XML） |
| データ形式 | JSON | JSON | XML |
| 伝送 | HTTP / REST | HTTP / REST | ブラウザリダイレクト / HTTP POST |
| モバイル・SPA | ◎ | ◎ | △（不向き） |
| API 保護 | ◎ | ◎ | ✕（想定外） |
| エンタープライズSSO | — | ◎ | ◎（実績が豊富） |
| 実装難易度 | 中 | 中（ライブラリ充実） | 高（XML署名・正規化） |
| ディスカバリ | RFC 8414（メタデータ） | /.well-known/openid-configuration | メタデータXML |
4. 判断フロー
ユーザーのログイン（本人確認）が必要？
├─ No → API アクセスの委譲／M2M？
│ └─ Yes → OAuth 2.0
│ ├─ ユーザーが関与する → Authorization Code + PKCE
│ └─ サーバー間のみ → Client Credentials
│
└─ Yes → 相手（IdP / 顧客企業）が SAML しか対応していない？
├─ Yes → SAML 2.0（可能なら将来OIDCへ移行を計画）
└─ No → OIDC（Authorization Code + PKCE）
5. ユースケース別の推奨
5.1 一般消費者向け Web / モバイルアプリのログイン
- OIDC を使う。Google / Apple / Microsoft 等のソーシャルログインもすべて OIDC。
- フローは Authorization Code + PKCE。
5.2 B2B SaaS（顧客企業の社内IdPでSSOさせたい）
- OIDC と SAML の両方をサポートするのが現実解。
- 大企業・官公庁・レガシー環境では SAML が要求されることがまだ多い。
- 自前で両対応を実装せず、IdP ブローカー（Auth0、Okta、Keycloak、Entra External ID、WorkOS 等）で吸収すると楽。
- ユーザープロビジョニングには SCIM を組み合わせる（SAML/OIDC はプロビジョニングを担わない）。
5.3 社内システムの SSO（新規）
- 社内IdP（Entra ID 等）が OIDC 対応なら OIDC を優先。
- 既存資産が SAML 前提なら SAML を継続してよいが、新規システムは OIDC で作る。
5.4 自社 API の保護
- OAuth 2.0 のアクセストークンで保護する。
- API 側は
aud（オーディエンス）、iss、exp、scopeを必ず検証。 - ID トークンを API の認可に使わない（ID トークンはクライアント向け）。
5.5 外部サービスの API 連携（GitHub、Google Drive など）
- OAuth 2.0。必要最小限のスコープを要求する。
5.6 マイクロサービス間・バッチ・M2M
- OAuth 2.0 Client Credentials。
- より強固にするなら mTLS（RFC 8705）や
private_key_jwtによるクライアント認証。
5.7 CLI / IoT / TV など入力が難しいデバイス
- OAuth 2.0 Device Authorization Grant（RFC 8628）。
6. よくあるアンチパターン
| アンチパターン | 問題点 | 正しい方法 |
|---|---|---|
| OAuth のアクセストークンだけで「ログイン」扱いにする | トークンは誰向けか保証されず、なりすまし（トークン差し替え）の余地がある | OIDC の ID トークンで認証する |
| ID トークンを API の Bearer トークンとして使う | ID トークンの aud はクライアントで、API 向けではない | API にはアクセストークンを使う |
| Implicit Flow を使う | トークンがURLフラグメントに露出、リフレッシュ不可 | Authorization Code + PKCE |
| Resource Owner Password Credentials（ROPC） | アプリがパスワードを扱う、MFA・フェデレーション不可 | Authorization Code + PKCE |
| SAML の署名検証を自前実装 | XML Signature Wrapping 等の脆弱性を生みやすい | 実績あるライブラリ／IdPブローカーを使う |
| 新規のモバイルアプリで SAML | ネイティブアプリ向けに設計されていない | OIDC |
| 「OAuth で認証」と言ってしまう | 設計時に認証と認可が混同される | 用語を分けて設計する |
7. 実装時のセキュリティベストプラクティス
OAuth 2.0 / OIDC 共通
- Authorization Code + PKCE を全クライアントで使う（機密クライアントも含む）。OAuth 2.0 Security BCP（RFC 9700）および OAuth 2.1 の方針。
- リダイレクト URI は完全一致で登録・検証する（ワイルドカード禁止）。
stateパラメータで CSRF 対策、OIDC ではnonceでリプレイ対策。- アクセストークンは短命にし、リフレッシュトークンはローテーション＋失効管理。
- SPA ではトークンをブラウザに保持しない BFF（Backend for Frontend）パターンを検討。
- スコープは最小権限。
- トークンの盗用対策が必要なら DPoP（RFC 9449） や mTLS による送信者制約トークン。
- JWT 検証では
algを固定し、noneを拒否、JWKS から鍵を取得してキャッシュ／ローテーションに対応。
OIDC 固有
- ID トークンの
iss、aud、exp、iat、nonceを必ず検証。 - ユーザーの一意識別には
iss+subの組み合わせを使う（メールアドレスをキーにしない）。 - ディスカバリ（
/.well-known/openid-configuration）を利用して設定ミスを減らす。
SAML 固有
- アサーションの署名を必須にし、可能ならアサーションの暗号化も行う。
Audience、Recipient、NotBefore/NotOnOrAfter、InResponseToを検証。- アサーション ID を記録してリプレイを防止。
- XML パーサーで XXE（外部エンティティ）を無効化。
- 署名検証済みの要素だけを参照する（Signature Wrapping 対策）。
- IdP 証明書の期限切れ・ローテーション運用を事前に設計する。
8. 組み合わせ方のパターン
- SAML で社内ログイン → OAuth でAPI保護 IdP ブローカーが SAML アサーションを受け取り、アプリ／API向けに OIDC・OAuth トークンを発行する構成。レガシーIdPを残しつつ、アプリ側はモダンに作れる。
- OIDC でログイン → 同じ認可サーバーが API 用アクセストークンを発行 最も一般的でシンプルな構成。
- フェデレーション（IdP ブローカー）を中心に置く アプリは常に OIDC だけを話し、顧客ごとの SAML / OIDC の差分はブローカーで吸収する。B2B SaaS で特に有効。
9. まとめ
- 新規開発のログインは OIDC（Authorization Code + PKCE）。
- API の保護・委譲は OAuth 2.0。アクセストークンと ID トークンの役割を混同しない。
- SAML は「相手が要求するから使う」もの。エンタープライズ連携では依然として必要だが、新規設計の第一候補にはしない。
- Implicit / ROPC は使わない。
- プロトコル実装は自作せず、実績あるライブラリや IdP を使う。
参考仕様
- RFC 6749 — The OAuth 2.0 Authorization Framework
- RFC 7636 — PKCE
- RFC 9700 — OAuth 2.0 Security Best Current Practice
- RFC 8628 — OAuth 2.0 Device Authorization Grant
- RFC 9449 — DPoP
- RFC 8705 — OAuth 2.0 Mutual-TLS
- OAuth 2.1（IETF ドラフト）
- OpenID Connect Core 1.0
- OASIS SAML 2.0 Core / Bindings / Profiles