はじめに
OAuth 2.0のWebサーバーフロー（認可コードフロー）は、Webアプリケーションがユーザーの代わりに安全にAPIへアクセスするための標準的な仕組みです。本章では目的と基本的な役割、流れの概観をやさしく説明します。
目的
ユーザーの資格情報（パスワード）をWebアプリ側で扱わずに、第三者のAPIへ安全にアクセスすることを目的とします。サーバ側でトークンを管理するため、ブラウザで秘密情報が漏れるリスクを減らせます。
登場人物（役割）
- ユーザー：サービスを利用する人
- クライアント（Webアプリ）：ユーザーの代理でAPIを呼び出すサーバを持つアプリ
- 認可サーバ：認証と認可を行い、認可コードやアクセストークンを発行するサービス
- リソースサーバ：保護されたAPIを提供するサービス
流れの概観
- クライアントが認可サーバへリダイレクトし、ユーザーがログイン・同意を行います。
- 認可サーバは認可コードをクライアントのサーバへ返します。
- クライアントは認可コードを用いて認可サーバと直接やり取りし、アクセストークンを取得します。
- クライアントは取得したトークンでリソースサーバに安全にAPIを呼び出します。
次章で、上の流れを図や具体的な例でわかりやすく説明します。
フローの概要
概要
ユーザーがWebアプリ（クライアント）にアクセスすると、アプリは認可サーバー（例：GoogleやMicrosoft）へユーザーを送ります。認可サーバーでログインと許可を得ると、認可コードがアプリのコールバックURLに返されます。アプリはその認可コードを使ってアクセストークンを取得し、アクセストークンで保護されたAPIへアクセスします。
ステップ1：ユーザーのアクセス
ユーザーがアプリを開くと、アプリは認可要求を生成して認可サーバーにリダイレクトします。具体例：”Googleでログイン”ボタンを押すとGoogleの画面に移動します。
ステップ2：ログインと許可
認可サーバーでユーザーがログインし、アプリに与える権限を確認して承認します。ここで同意画面が表示されます。
ステップ3：認可コードの受領
ユーザーが承認すると、認可サーバーは事前に登録したコールバックURLに認可コードを返します。コードは短時間だけ有効な一時的な値です。
ステップ4：アクセストークンの取得
アプリはサーバー側で認可コードを受け取り、認可サーバーに対して認可コードとクライアント情報を送信してアクセストークンを取得します。
ステップ5：保護リソースへのアクセス
取得したアクセストークンをAPIリクエストのヘッダーに付けて、ユーザーのデータなど保護されたリソースにアクセスします。
注意点
認可コードは公開しないようにし、アクセストークンは安全に保管してください。コールバックURLは事前登録しておく必要があります。
主な特徴
機密情報の保護
クライアント（Webサーバー）がクライアントシークレットや秘密鍵を安全に保持します。秘密はサーバー内で管理するため、外部のブラウザや第三者のアプリに漏れにくく、全体としてセキュリティが高まります。具体例としては、サーバーの環境変数や専用のシークレット管理ツールに保存します。
ユーザー認証情報の扱い
ユーザーのパスワードや認証情報はクライアント側に渡りません。ユーザーは認可サーバーに直接ログインするため、信頼できないアプリに自分のパスワードを預ける必要がなく、安全に認証できます。
アクセストークンと有効期限
アクセストークンは一定期間で失効します。短めの有効期限にすると、不正利用のリスクを下げられます。たとえば数分〜数時間の設定が一般的です。トークンが失効すると、新しいアクセス権を得るには更新処理が必要です。
リフレッシュトークンでの更新
アクセストークンが期限切れのときは、リフレッシュトークンを使って新しいアクセストークンを取得できます。リフレッシュトークンはサーバー側で厳重に管理し、必要に応じてローテーションや取り消しを行います。
運用上のポイント
- トークンはHTTPSでやり取りします。
- スコープを限定して必要最小限の権限だけ与えます。
- トークンのログや失効処理を実装して不正検知に備えます。
代表的な利用例
1. クラウドストレージ連携（例：Google Drive）
Webアプリがユーザーのファイルにアクセスするときに使われます。ユーザーはGoogleのログイン画面でアクセスを許可し、アプリはその許可を受けてファイル一覧やアップロードを行います。パスワードを共有せずに済むため安全で、ユーザー側の操作は簡単です。長時間使う場合は”リフレッシュトークン”で再認証を省けますが、安全に管理する必要があります。
2. 企業向けAPI連携（例：Microsoft Graph）
会社のメールやカレンダー、チーム連携を行うときに役立ちます。管理者がアプリに権限を与えたり、ユーザーごとに同意を取ったりして、必要なデータだけにアクセスします。シングルサインオン（SSO）と組み合わせると、社員は追加のパスワードを入力せずに業務ツールを使えます。
3. SNSアカウントでのログイン（例：Googleアカウントでログイン）
ユーザー登録やログインの手間を減らせます。既存のSNSアカウントで認証するため、メール確認やパスワード管理の負担が軽くなります。また、アカウント連携を通じてプロフィール情報を取得し、入力の手間をさらに減らせます。
4. Webアプリの認証・認可全般
セキュリティと使いやすさの両立を目指す場面で広く使われます。権限の範囲（スコープ）を限定して最小限のアクセスに抑え、トークンの有効期限を設けることで不正利用リスクを下げます。クライアント側に秘密情報を置かない、通信を必ずHTTPSにするなどの基本も重要です。
注意点
- 必要な権限だけを求める（最小権限の原則）。
- クライアント秘密情報やリフレッシュトークンは安全に保管する。
- ユーザーがアクセスを取り消したときに対応する仕組みを用意する。
これらの例は多くのWebアプリで採用され、利便性と安全性のバランスが取れた実装法です。
