OAuth 2.0のフローとトークンの種類

OAuth 2.0では4つのロールを定義しています。リソースオーナーはデータを所有するユーザーです（例：ユーザー自身のGoogle Driveファイル）。クライアントはアクセスを要求するアプリケーションです。認可サーバーはアクセストークンを発行します（例：GoogleのOAuthサーバー）。リソースサーバーは保護されたデータをホストします（例：Google Drive API）。これらのロールを理解すると、それぞれのフローの目的が明確になります。

認可コードフローは、サーバーサイドのウェブアプリケーションに適したフローです。ユーザーは認可サーバーで認証し、認可サーバーは有効期間の短い認可コードを付けてクライアントへリダイレクトします。クライアントのサーバーは、バックチャネルリクエストでこのコードをトークンと交換します。トークンがブラウザーを通過することはないため、ブラウザー履歴やリファラからの漏えいを防止できます。

インプリシットフローは、クライアントシークレットを安全に保存できないブラウザーのみのJavaScriptアプリケーション向けに設計されました。トークンはURLフラグメントに直接返され、バックチャネルを経由しません。PKCE（RFC 7636）によってパブリッククライアントでもクライアントシークレットなしに認可コードフローを安全に使用できるため、インプリシットフローはOAuth 2.1では非推奨です。

ROPCフローでは、クライアントがユーザーのユーザー名とパスワードを直接受け取り、それらをトークンと交換します。これは高い信頼性を持つファーストパーティクライアント向けに意図されたものでしたが、アプリケーションにユーザーの認証情報を見せないというOAuthの目的を根本から損ないます。OAuth 2.1では非推奨であり、新しいアプリケーションでは使用すべきではありません。

クライアントクレデンシャルフローは、ユーザーが関与しないマシン間（M2M）認証に使用します。クライアントは自身のクライアントIDとシークレットを使って認可サーバーに直接認証し、自分で使用するアクセストークンを受け取ります。一般的な用途には、バックグラウンドジョブ、マイクロサービス間通信、バックエンドサービスにアクセスするAPIゲートウェイがあります。

デバイス認可フロー（RFC 8628）は、スマートテレビ、ゲーム機、プリンター、IoTデバイスなど、入力機能が限られたデバイスでOAuthを利用できるようにします。デバイスには短いコードとURLが表示されます。ユーザーはスマートフォンやコンピューターでURLにアクセスして認可します。デバイスは、ユーザーが認可を完了するまで認可サーバーをポーリングします。

OAuth 2.0では、2種類のアクセストークンを定義しています。不透明トークンはランダムな文字列で、リソースサーバーが認可サーバーのイントロスペクションエンドポイントを呼び出して検証します。JWTアクセストークンは自己完結型であり、リソースサーバーは署名を検証してローカルで検証できます。これによりイントロスペクションAPIの呼び出しを減らせますが、鍵管理が必要になります。

リフレッシュトークンは、アクセストークンの有効期限が切れた後に新しいアクセストークンを取得するために使う、長期間有効な認証情報です。リフレッシュトークンのローテーションでは、使用するたびに新しいリフレッシュトークンを発行して古いトークンを無効化します（OAuth 2.1ではパブリッククライアントに必須です）。盗まれたリフレッシュトークンが使われると、正規のクライアントが無効化を検出できるため、トークン盗難の発見につながります。

RFC 7662では、トークンイントロスペクションエンドポイントを定義しています。これによりリソースサーバーは、認可サーバーに対して不透明なアクセストークンの現在の状態（active/inactive）、スコープ、サブジェクト、有効期限を問い合わせられます。イントロスペクションによってリアルタイムのトークン失効が可能になります。認可サーバーでトークンを失効させると、イントロスペクションの呼び出しは直ちに active: false を返します。

RFC 7009ではトークン失効エンドポイントを定義しており、クライアントはアクセストークンまたはリフレッシュトークンを無効化するよう認可サーバーに通知できます。これはログアウト時や、クライアントが不審なアクティビティを検知した場合に使用します。JWTアクセストークンは、失効リストなしでは完全に失効させることができません。リソースサーバーが認可サーバーに接続せず、ローカルでトークンを検証するためです。

OAuth 2.0のスコープは、クライアントが要求する具体的な権限を定義します。認可サーバーは、要求されたスコープをユーザーに提示して承認を求めます。リソースサーバーはエンドポイントごとにスコープ要件を適用します。最小権限の原則に従い、クライアントは必要最小限のスコープだけを要求し、リソースサーバーはスコープが不十分なリクエストを拒否する必要があります。

ユーザーの認証が必要であるものの、ブラウザーもキーボードもないCLIツールやIoTデバイスには、どのOAuth 2.0フローが適していますか？

認可コードフローはサーバーサイドアプリに適しています。インプリシットフローは非推奨です（代わりにPKCEを使用します）。ROPCフローは非推奨です（OAuthの目的を損なうためです）。クライアントクレデンシャルフローはM2Mに使用します。デバイス認可フローは入力機能が限られたデバイスに対応します。アクセストークンには不透明トークンとJWTがあります。リフレッシュトークンはローテーションすべきです。イントロスペクション（RFC 7662）と失効（RFC 7009）によって、トークン管理が完成します。