OAuth2 と OpenID Connect（OIDC）の違いを徹底解説：Cognito や Auth0 連携時の注意点
🎯 はじめに：認証・認可の基本を整理しよう
- OAuth2：ユーザーに代わってアクセス権限を与えるためのフレームワークです。
- OIDC（OpenID Connect）：OAuth2 に「誰がログインしたか（認証）」の仕組みを加えた、ID 層の拡張仕様です :contentReference[oaicite:1]{index=1}。
Cognito や Auth0 はこの両方を含めて利用できるため、誤解なく設計することが重要です。
1. OAuth2 と OIDC の違いを比較
| 項目 | OAuth2 | OIDC（OpenID Connect） |
|---|---|---|
| 主目的 | 認可（Authorization）：リソースへのアクセス許可 | 認証（Authentication）：ユーザーの本人性確認 :contentReference[oaicite:2]{index=2} |
| 発行トークン | アクセストークン（Access Token）、リフレッシュトークン（任意） | + IDトークン（ID Token） |
| ユースケース | APIアクセス許可、リソース保護 | ログイン機能、SSO、ID情報取得 |
| フロー | Authorization Code、Client Credentials、Implicitなど | 主に Authorization Code + PKCE |
| スコープ（scope） | リソースへのアクセス範囲指定 | openid, profile, email などでID情報取得 :contentReference[oaicite:3]{index=3} |
2. なぜ両者を分けて考えるのか？
-
OAuth2 単体では認証目的に使うのは危険
アクセストークンが正当なユーザーのものかどうか判断できず、セキュリティリスクが高まります :contentReference[oaicite:4]{index=4}。 -
OIDC は「誰がログインしたか」をJWTとして含む
ID Token によりユーザーIDやメールアドレスなどのクレームが得られ、セキュアな認証が可能です :contentReference[oaicite:5]{index=5}。
つまり、ログイン機能が必要な場合はOIDC、外部APIへのアクセスだけならOAuth2という使い分けが推奨されます。
3. Cognito と Auth0 の対応状況
🔹 AWS Cognito
- OAuth2 の複数グラントタイプ（Auth Code、Implicit、Client Credentials）に対応 :contentReference[oaicite:6]{index=6}。
- OIDC も対応しており、IDトークンによるユーザー認証が可能 :contentReference[oaicite:7]{index=7}。
- さらに、Cognito を「OIDC プロバイダ」として他の IdP（Auth0等）と連携できる :contentReference[oaicite:8]{index=8}。
🔹 Auth0
- OAuth2 と OIDC を両方サポートし、GUI や SDK による統合が容易 :contentReference[oaicite:9]{index=9}。
- 各種認証フロー（Auth Code + PKCE、Implicit Flowなど）を柔軟に設定可能 :contentReference[oaicite:10]{index=10}。
- Cognito と OIDC 連携も可能（ID プールやSAMLと合わせて設定構成可能） :contentReference[oaicite:11]{index=11}。
4. 設計時の注意点・実装の落とし穴
1. スコープ指定忘れ
- OIDC を使う際には
scope=openidを含めることが必須。これがないと ID トークンが取得できません :contentReference[oaicite:12]{index=12}。 - Auth0 では
offline_accessスコープを付けることでリフレッシュトークン取得が有効になります :contentReference[oaicite:13]{index=13}。
2. トークン形式の違い
- Cognito は Access・Refresh・ID 全て JWT が返ってきます :contentReference[oaicite:14]{index=14}。
- Auth0 はスコープ設定が不十分なとき Access → Opaqueトークン、ID/Refresh → 取得されないケースもあります :contentReference[oaicite:15]{index=15}。
3. Cognito と Auth0 の連携
- Cognito を「OIDC IdP」として設定する場合、OIDC IdPの発行するJWT構造（署名方式やpublic key配置）に則る必要があります :contentReference[oaicite:16]{index=16}。
- Auth0 を統合する際、RS256 証明書署名を使用し、Cognito 側で正しいClientID/Audience 設定が必要です :contentReference[oaicite:17]{index=17}。
4. フロー選択のポイント
- SPA やモバイルアプリでは PKCE 対応の『Authorization Code + PKCE』を選ぶのが安全です。
- バックエンドサーバーのみの場合は Authorization Code Flow がよく使われます。
- **機械間通信（M2M）**では Client Credentials グラントを使い、IDトークン不要で済むため OAuth2 単体でOK。
5. まとめ：設計と運用の整理ガイド
✅ 使用目的別おすすめフロー
| ケース | フロー | 使用サービス例 |
|---|---|---|
| ユーザー認証（ログイン）を実装したい | Authorization Code + PKCE（OIDC） | Cognito / Auth0 |
| API にアクセスする M2M やサーバー処理 | Client Credentials（OAuth2） | Cognito, Auth0 |
| 認証後にリフレッシュ可能にしたい場合 | offline_access + Authorization Code |
Cognito / Auth0 |
| Cognito と外部 OIDC IdP を連携させる場合 | Cognito User Pool に OIDC IdP 登録 | Auth0 連携 |
🔍 設定漏れチェックリスト
- [ ]
scope=openidが指定されているか - [ ] 認可フローに応じたスコープ（profile, email, offline_access）も指定が入っているか
- [ ] トークン署名方式（RS256）と公開鍵取得方法が正しいか
- [ ] tr用フロー（SPA/Mobile/Cognito App client）に応じたセキュリティ対策が施されているか
最後に：なぜ正しく使い分けることが重要か
- OAuth2 と OIDC を混同すると、本当のログインが保証できず、認可リクエストだけで済ませてしまう構成になる可能性があります。
- Auth0 や Cognito などのサービスには細かな仕様差があり、意図しないトークン形式やスコープ設定によって、本番環境で予期せぬアクセス障害が発生するリスクがあります。
- 正しい設計を行い、安全かつスケーラブルな認証・認可基盤としてシステムを構築しましょう。
このガイドが、OAuth2 と OIDC の違いを整理し、Cognito・Auth0との安全な連携設計に役立てば幸いです。
さらに具体的なフローや設定ファイル例が必要であれば、お気軽にご依頼ください！