OAuth 2.0 (RFC 6749)（オーオースツー）
IETF 2012年標準化の認可フレームワーク。Token ベース・サードパーティアプリへの限定アクセス権付与、Google / Facebook / Twitter ログインの基盤。
概要
OAuth 2.0 はIETF が2012年10月にRFC 6749 / 6750 で標準化した認可フレームワーク。Dick Hardt (Microsoft) 主導・OAuth 1.0 (2010・Twitter主導) からの大改訂版。「認可」(Authorization・ユーザの代わりにアプリがアクセスする権利) を提供するフレームワーク、認証 (Authentication) とは別概念。Access Token ベース・サードパーティアプリへの限定アクセス権付与・「○○でログイン」ボタンの基盤、現代Web アプリ認可の事実上標準。
主要マイルストーン
| 年月 | 出来事 |
|---|---|
| 2007 | OAuth 1.0 ドラフト |
| 2010-04 | OAuth 1.0 (RFC 5849) 標準化 |
| 2010-2012 | OAuth 2.0 開発 (大論争) |
| 2012-07 | Eran Hammer (主要設計者) 辞任「OAuth 2.0 はセキュリティ失敗」 |
| 2012-10 | OAuth 2.0 (RFC 6749 / 6750) 標準化 |
| 2014 | OpenID Connect (OAuth 2.0 上の認証) |
| 2017 | OAuth 2.1 議論開始 |
| 2024 | OAuth 2.1 ドラフト (RFC ベース予定) |
OAuth 2.0 主要Grant Type
| Grant Type | 用途 | 安全性 |
|---|---|---|
| Authorization Code | Web Server / Native アプリ | ◎ 最推奨 |
| Authorization Code + PKCE | SPA / Mobile (2015-) | ◎ 必須 |
| Implicit | SPA (旧) | ✕ 廃止勧告 (OAuth 2.1) |
| Client Credentials | Server-to-Server | ◎ |
| Resource Owner Password | レガシー | ✕ 廃止勧告 |
| Device Code | TV / IoT (画面なし) | ◎ |
| Refresh Token | Access Token 更新 | ◎ |
Authorization Code Flow (主要)
1. ユーザ → アプリ: 「Googleでログイン」クリック
2. アプリ → Auth Server: 認可要求 (Client ID + Redirect URI)
3. Auth Server → ユーザ: ログイン画面
4. ユーザ → Auth Server: 認証 + 同意
5. Auth Server → アプリ: Authorization Code (Redirect URI 経由)
6. アプリ → Auth Server: Code + Client Secret → Access Token 交換
7. アプリ → API: Access Token で API呼出
最も安全な Flow・Auth CodeとAccess Token を分離・Client Secret サーバ側保管。
PKCE (RFC 7636・2015)
「Proof Key for Code Exchange」・SPA / Mobile 向けセキュリティ強化:
- Code Verifier (ランダム43-128字) 生成
- Code Challenge (Verifier の SHA-256) を初期要求に送信
- Code Verifier をToken 交換時に送信
- 中間者攻撃 (Code 盗難) で攻撃不可
- 2015年RFC 7636・現代SPA で必須
OAuth 2.0 vs OAuth 1.0
| 項目 | OAuth 1.0 | OAuth 2.0 |
|---|---|---|
| 暗号署名 | HMAC-SHA1 (各リクエスト) | HTTPS 依存 (Bearer Token) |
| 複雑度 | 高 | 中 |
| Mobile対応 | 困難 | 良 |
| Token Lifetime | 永続 | 短期 + Refresh |
| 設計者反応 | OK | Hammer 辞任「失敗」 |
Eran Hammer 辞任事件 (2012)
OAuth 2.0 主要設計者Eran Hammer (Yahoo!) が2012年7月Editor 辞任・「OAuth 2.0 はWeb Authorization Hell」と批判:
- 仕様が「過度に柔軟」(企業の個別実装で互換性問題)
- セキュリティ要件が「Bearer Token + HTTPS」と楽観
- Microsoft / Salesforce / Facebook 等の大手の影響で複雑化
- 「商業政治の犠牲」と公開批判
その後Google / Auth0 / Okta 等の実装でEcosystem 成熟、現代では「Hammer の懸念は的中したが運用で対処」状況。
主要採用
| サービス | 用途 |
|---|---|
| Google OAuth | Gmail / Drive / Calendar API |
| Facebook Login | サードパーティアプリ認可 |
| Twitter / X OAuth | API アクセス |
| GitHub OAuth | リポジトリ / GraphQL API |
| Microsoft (Entra ID) | Office 365 / Azure |
| Salesforce | API + Force.com |
| Okta / Auth0 | エンタープライズSSO |
| Stripe Connect | 決済アプリ連携 |
| Slack | ボット / Webhook |
関連用語との違い
- vs OAuth 1.0: 単純化 + 商業向け / 暗号署名重視
- vs OpenID Connect: 認可 / 認証 (OIDC = OAuth 2.0 + ID Token)
- vs SAML 2.0: モダンRESTful / XML SOAP
FAQ
Q1: OAuth = 認証? A: 違う。OAuth は「認可」(Authorization)・アプリにユーザの代わりにAPI 呼ぶ権利を与える。「認証」(Authentication・「あなたは誰か」) は OpenID Connect (OAuth 上の拡張) が担当。
Q2: OAuth 2.1 はいつ? A: 2024年現在ドラフト・2025-2026年RFC 化見込み。OAuth 2.0 の安全な部分のみ統合 (Implicit / Resource Owner Password 削除・PKCE 必須化等)。
Q3: 個人プロジェクトでの実装? A: Auth0 / Clerk / Supabase / Firebase Auth 等のマネージドサービス利用が圧倒的に簡単。自家OAuth 実装は脆弱性リスク高、CVE多数。