インプリシットフローが非推奨である理由

インプリシットフローとその非推奨

インプリシットフロー（response_type=token）は、バックチャネルリクエストを安全に行うことができないブラウザベースのアプリケーション（SPA）向けに元々設計されました。認可コードをトークンに交換する代わりに、ユーザーの認可後にアクセストークンがURLフラグメントで直接返されました。

仕組み

1. クライアントが/authorize?response_type=token&client_id=...&redirect_uri=...にリダイレクト
2. ユーザーの同意後、認可サーバーがフラグメントにトークンを含めてリダイレクト: #access_token=...&token_type=Bearer&expires_in=3600
3. JavaScriptアプリケーションがURLフラグメントからトークンを抽出

非推奨となった理由

インプリシットフローにはいくつかの根本的なセキュリティ上の弱点があります：

1. URLでのトークン露出 アクセストークンがURLフラグメントに表示され、以下を通じて漏洩する可能性があります：

• ブラウザ履歴
• HTTPリファラーヘッダー（ページが外部サイトにリンクしている場合）
• サーバーログ（フラグメントが誤って転送された場合）
• ショルダーサーフィング

2. トークンバインディングの欠如 トークンがそれを受信したクライアントに対して発行されたことを検証する方法がありません。攻撃者が盗まれたトークンを正当なクライアントのコールバックURLに注入できます（トークンインジェクション攻撃）。

3. リフレッシュトークンなし インプリシットフローはリフレッシュトークンをサポートしません。アクセストークンの有効期限が切れると、ユーザーは再認可する必要があり、UXの低下や隠しiframeなどの安全でない回避策につながります。

4. クライアント認証なし パブリッククライアントは自身を認証できないため、トークンリクエストが正当なアプリケーションからのものであることを確認する方法がありません。

代替：認可コード + PKCE

モダンなSPAは、PKCE（Proof Key for Code Exchange）付きの認可コードフローを使用すべきです。アクセストークンをURLから遠ざけ、リフレッシュトークンをサポートし、認可コードの傍受攻撃を防ぎます。OAuth 2.1はインプリシットグラントタイプを正式に削除します。