インプリシットフロー
非推奨認可コードを介さず、認可エンドポイントから直接アクセストークンを返すフロー。セキュリティ上の問題から現在は非推奨です。代わりに認可コード + PKCE フローを使用してください。
このフローは非推奨です
セキュリティ上の問題があるため、新規の実装では使用しないでください。 代わりに認可コード + PKCE フローを使用してください。
なぜ非推奨なのか?
アクセストークンがURLフラグメントに含まれるため、ブラウザ履歴やRefererヘッダーから漏洩する可能性があります。
トークンがフロントチャネル（ブラウザ経由）で返されるため、攻撃者が偽のトークンを注入できる可能性があります。認可コードフローのようなバックチャネル検証がありません。
認可コードフローでは client_secret や code_verifier でクライアントを検証できますが、インプリシットフローにはそのような仕組みがありません。
セキュリティ上の理由からリフレッシュトークンを発行できません。トークンの有効期限が切れるたびにユーザーは再認証が必要になります。
OAuth 2.1 の仕様ではインプリシットフローは完全に削除されます。RFC 9700（OAuth 2.0 Security Best Current Practice）でも非推奨とされています。
代替手段: 認可コード + PKCE フロー
SPAやネイティブアプリでは、認可コード + PKCE フローを使用してください。 PKCEを使えばclient_secretなしでも安全に認可コードフローを利用でき、 インプリシットフローのセキュリティ上の問題をすべて回避できます。
シーケンス図
各ステップの詳細
ブラウザ → 認可サーバー
クライアントが response_type=token で認可リクエストを送信します。トークンエンドポイントを使わず、直接トークンを受け取ります。
リクエスト
GET /authorize
response_type=token&client_id=my-spa-app&redirect_uri=https://example.com/callback&scope=openid profile&state=random-csrf-token
セキュリティノート
- !response_type=token がインプリシットフローの特徴
- !client_secret は使用しない
認可サーバー → ブラウザ
認可サーバーがユーザーにログインと同意を求めます。他のフローと同じプロセスです。
リクエスト
GET /login
レスポンス
POST /login
username=user&password=****&consent=approve
認可サーバー → ブラウザ
認可サーバーがアクセストークンをURLフラグメント（#）に含めてリダイレクトします。フラグメントはサーバーに送信されませんが、ブラウザのJavaScriptからアクセスできます。
リクエスト
GET https://example.com/callback
#access_token=eyJhbGciOiJSUzI1NiIs...&token_type=Bearer&expires_in=3600&state=random-csrf-token
セキュリティノート
- !トークンがURLに露出する（ブラウザ履歴、Refererヘッダー）
- !トークン漏洩のリスクが高い
- !リフレッシュトークンは発行できない
クライアント → リソースサーバー
JavaScriptがフラグメントからトークンを抽出し、APIリクエストに使用します。
リクエスト
GET /api/userinfo
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
セキュリティノート
- !トークンがフロントエンドのみで管理される
- !XSS 攻撃でトークンが窃取されるリスクが高い
- +使用しないでください（非推奨）
- -すべてのケース → 認可コード + PKCE フローを使用する
- -レガシーシステムからの移行も計画すべき
セキュリティ上の考慮事項
- !OAuth 2.0 Security Best Current Practice (RFC 9700) で非推奨
- !アクセストークンがURLフラグメントに露出し漏洩リスクが高い
- !ブラウザ履歴やRefererヘッダーからトークンが漏洩する可能性がある
- !トークンの送信元を検証する仕組みがない（トークンインジェクション攻撃に脆弱）
- !リフレッシュトークンを発行できないため、ユーザー体験が低下する
- !OAuth 2.1 ではインプリシットフローは削除される予定