REST API をどう保護しますか (認証、認可、トランスポート)?

Question

IT Interview Practice · Accepted Answer

REST API の保護とは、すべてのリクエストで 3 つの問いに答えることです: **あなたは誰か** (authentication)、**何をしてよいか** (authorization)、**チャネルはプライベートか** (transport)。REST は **stateless** なので、資格情報は server セッションに存在するのでなく各リクエストとともに移動しなければなりません。

## トランスポート: 常に HTTPS

以下すべては **TLS/HTTPS** を前提とします。それなしでは、トークンと API key は平文で移動し盗聴されえます。これは交渉の余地なし — HTTP 上の bearer token は漏洩したトークンです。

## 認証の選択肢

**API key** — ヘッダ内の静的な秘密。単純で、server-to-server と、user ではなく *アプリケーション* の識別に適します。それ単体では弱い (有効期限なし、scope なし) ため、他と組み合わせない限り。
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — **委任 (delegated)** アクセス (「App X に、私のパスワードなしで私のデータを読ませる」) の標準。アプリはフロー (例: Authorization Code) を介して **access token** を取得し、bearer token として送ります。これが「Sign in with Google」やサードパーティ統合の仕組みです。

**JWT (JSON Web Token)** — トークンの一般的な *形式*: 署名された自己完結型のトークンで、クレーム (user id、role、有効期限) を運びます。server は署名を検証します — データベース参照が不要で、stateless REST に適合します。
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## 認可: scope と role

Authentication は身元を証明し、**authorization** はアクセスを決定します。トークンは **scope** (`orders:read`、`orders:write`) や role を運びます。server はエンドポイントごとにそれらをチェックし、不十分なとき `403 Forbidden` を返します (欠落/無効な auth の `401` とは対照的)。

```text
トークンなし/無効       → 401 Unauthorized
有効なトークン、scope なし → 403 Forbidden
```

## その他の必須事項

```text
✓ 短命な access token + refresh token (漏洩時の影響範囲を限定)
✓ Rate limiting (429) で brute-force と乱用を鈍らせる
✓ すべての input を validate/sanitize する; client を決して信頼しない
✓ scope に対する least privilege の原則
```

## なぜ重要なのか

セキュリティは小さなミスが侵害になる場所なので、面接官はこれで、buzzword を暗唱するのでなく構造的に推論するか見ます。彼らが探すシグナルは、あなたが **3 つの層を分離する** こと — transport (HTTPS、常に)、authentication (身元を stateless に、bearer token/JWT/OAuth で証明)、authorization (scope と least privilege) — そしてそれらを混同しないこと、例えば「未認証」に `401`、「認証済みだが許可されない」に `403` を正しく使うことです。強い答えは実際的なトレードオフへの認識を示します: JWT は便利で stateless だが有効期限前の失効が難しい (だから短い寿命に refresh token を加える)、API key は user でなくアプリを識別する、OAuth は user がサードパーティにパスワードを渡さずに済むためにこそ存在する。REST の statelessness と結びつける — 各リクエストに資格情報、server セッションなし — ことは、なぜ API セキュリティがこの形なのかを理解していることを示します。

トランスポート: 常に HTTPS

認証の選択肢

認可: scope と role

その他の必須事項

なぜ重要なのか

関連する質問