OAuth 2.0

OAuth 2.0 は委譲型の認可（authorization）のためのフレームワークです。アプリにパスワードを渡す代わりに、ユーザーは認可サーバー上でリクエストを承認します。認可サーバーは、スコープ（たとえば orders:read）と有効期限で制限されたアクセストークンをアプリに発行します。アプリはそのトークンを、通常は Authorization: Bearer <token> として API に送ります。4 つのロールは、リソースオーナー（ユーザー）、クライアント（アプリ）、認可サーバー（トークンを発行する）、リソースサーバー（API）です。

認証と認可の違い

**認証（authentication）**は「あなたは誰か？」に答えます。**認可（authorization）**は「あなたは何をしてよいか？」に答えます。OAuth 2.0 単体が扱うのは認可です。アクセストークンが示すのはトークンの持ち主が何にアクセスできるかであり、ユーザーが誰であるかを確実に示すものではありません。ユーザーのログインを担うのは OpenID Connect で、OAuth 2.0 の上に、ユーザーを表す ID トークン（JWT）を追加したレイヤーです。「○○でサインイン」ボタンは OpenID Connect を使っています。

主なグラントタイプ

• 認可コード + PKCE: ブラウザーアプリやモバイルアプリを含め、ユーザーの代理として動作するアプリ向けです。ユーザーが認可サーバーでサインインし、アプリは短命のコードを受け取り、それをトークンと交換します。
• クライアントクレデンシャル: ユーザーが介在しないサービス間通信向けです。API テストスイートで最もよく使われるフローです。
• リフレッシュトークン: 長期間有効なリフレッシュトークンを新しいアクセストークンと交換します。

インプリシットグラントとリソースオーナーパスワードグラントは、現在の OAuth セキュリティガイダンスで非推奨とされており、OAuth 2.1 のドラフトでは削除されています。

例：クライアントクレデンシャル

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

レスポンスには access_token、Bearer という値の token_type、秒単位の expires_in が含まれます。トークンはフィクスチャで一度だけ取得し、有効期限が近づくまでキャッシュしてください。クライアントシークレットはリポジトリではなく CI のシークレットに保管します。

テストすべきこと

• トークンがない、期限切れ、または形式が不正な場合は 401 が返る。
• 有効なトークンでも必要なスコープがなければ 403 が返る。
• 別のオーディエンスやクライアント向けに発行されたトークンは拒否される。
• 認可コードフローでは state パラメーターが検証され、リダイレクト URI が登録済みの値と完全に一致する必要がある。
• トークンレスポンスやリダイレクトによって、ログや URL にトークンが露出しない。