access token と refresh token はどのように連携して動作しますか？

Question

IT Interview Practice · Accepted Answer

2 つのトークンはシンプルなライフサイクルに従います: **短命な access token** が各 API 呼び出しを認可し、**長命な refresh token** がそれらの失効時に静かに新しい access token を発行します — こうしてユーザーは認証情報を再入力せずにログイン状態を維持します。

## フロー

```
┌─────────┐  1. login (user + pass)   ┌────────────┐
│ Client  │ ────────────────────────▶ │ Auth server│
│         │ ◀──── access + refresh ─── │            │
└─────────┘                            └────────────┘
     │  2. API 呼び出し: Authorization: Bearer <access>
     ▼
┌────────────┐  署名 + exp を検証   (DB ルックアップなし)
│ Resource   │ ──── 200 OK ────▶ (access はまだ有効)
│ API        │ ──── 401 ───────▶ (access は失効)
└────────────┘
     │  3. 401 の場合: POST /token { refresh }
     ▼
┌────────────┐  検証 + ローテーション
│ Auth server│ ──── 新しい access (+ 新しい refresh) ────▶ 呼び出しを再試行
└────────────┘
```

1. **Login** — ユーザーは一度認証します。サーバーは **access token** (短い TTL) と **refresh token** (長い TTL) を返します。
2. **API へのアクセス** — クライアントはすべてのリクエストで `Authorization: Bearer …` に access token を送ります。API はそれをステートレスに検証し (署名 + `exp`)、応答します — session store は不要です。
3. **失効時の更新** — API が `401` を返す (またはクライアントが `exp` が近いと判断する) と、クライアントは **refresh token** を auth サーバーの `/token` endpoint に POST し、新しい access token を取得してから、元のリクエストを再試行します。ユーザーは何も気づきません。
4. **ログアウト / 失効** — サーバーは refresh token を削除または denylist に登録します。次の更新は失敗し、セッションは終了します (現在の access token もそれ自体で数分以内に消滅します)。

```js
// クライアントのインターセプタ: 401 で一度更新し、再試行する。
async function apiFetch(url, opts = {}) {
  let res = await fetch(url, withAuth(opts, accessToken));
  if (res.status === 401) {
    accessToken = await refreshAccessToken(refreshToken); // POST /token
    res = await fetch(url, withAuth(opts, accessToken));   // 再試行
  }
  return res;
}
```

## refresh token のローテーション

ベストプラクティスは**ローテーション**です: 各更新呼び出しは *新しい* refresh token を返し、古いものを無効化します。古い (すでに使用済みの) refresh token が再び提示された場合、それは窃取を示します — サーバーはトークンファミリー全体を失効させ、再ログインを強制します。これにより、盗まれた refresh token による被害が制限されます。

## 保存

- **Refresh token** → `httpOnly`、`Secure`、`SameSite` cookie にして、JavaScript (したがって XSS) が読めないようにします。
- **Access token** → クライアントのメモリに保持します。短い寿命が露出を制限します。
- 避けられるなら、どちらも `localStorage` に置かないでください — 注入されたあらゆるスクリプトから読み取り可能です。

## なぜ重要なのか

このフローは、モダンな SPA、モバイルアプリ、API におけるセッション管理の背骨であるため、面接官はあなたが端から端まで追えることを期待します: ログイン時に両方を発行し、access token で認可し、失効時に透過的に更新し、安全のためにローテーション + 失効を行う。細部を正しく押さえること — ステートレスな検証、token endpoint でのみ更新、再利用検出付きのローテーション、そして `httpOnly` 保存 — が、スムーズで安全なセッションと、1 つの盗まれたトークンが長命なアカウント乗っ取りを意味するセッションとの違いです。

フロー

refresh token のローテーション

保存

なぜ重要なのか

関連する質問