Claude Codeで認証・認可を実装する——セキュアなデフォルトをCLAUDE.mdで強制する

はじめに

SASTによる脆弱性スキャンでも、API Gatewayでの認証一元化でもない。「JWTのリフレッシュトークンローテーションを正しく実装する・RBACのパーミッションテーブルを設計する」——認証・認可の実装コードをClaude Codeで自動生成して、セキュアな実装を確保する話だ。

「JWTリフレッシュトークンを1回使用後に無効化していますか？」——この問いに「そこまでやってない」と答えるチームは少なくない。JWTのシークレットをコードにハードコードする・リフレッシュトークンを無期限に使い続ける・CSRF対策のstateパラメータを省略する——これらはOWASP Top 10の「A07: 識別と認証の失敗」として分類されるほど頻発するミスだ。「動く認証」と「セキュアな認証」の間には大きなギャップがある。

CLAUDE.mdに認証ポリシーを定義することで、Claude Codeが常にセキュアなデフォルト（OWASP準拠）で認証コードを生成するようになる。「最初からセキュアな実装」が標準状態になる設計だ。ただし、生成された認証コードは必ずセキュリティレビューが必要であることを最初に断っておく。特に本番環境向けの認証実装は、セキュリティ専門家による確認を推奨する。

CLAUDE.mdで認証ポリシーを定義する——セキュアなデフォルトを強制する

認証実装のセキュリティ品質をCLAUDE.mdで定義しておくことが、このアプローチの起点だ。

# CLAUDE.md（認証・認可ポリシー）
## Authentication & Authorization Policy

### トークン管理
- アクセストークン有効期限: 15分（JWTのexp claim）
- リフレッシュトークン有効期限: 7日
- リフレッシュトークンは1回使用後に無効化（Refresh Token Rotation）
- リフレッシュトークンはHTTP-only Cookieで保存（localStorage禁止）

### OAuth 2.0ルール
- state パラメータ必須（各フロー開始時に一意の値を生成）
- stateはRedisに保存（TTL: 10分）。コールバック時に検証して削除
- PKCE（Proof Key for Code Exchange）をSPAでは必須とする
- 暗黙的フロー（Implicit Flow）禁止

### パスワード管理
- パスワードは必ずbcrypt（cost 12以上）でハッシュ化
- プレーンテキストのパスワードをログ・レスポンスに含めない
- パスワードリセットトークンは単一使用・1時間TTL

### RBAC設計
- ロール: admin / member / guest（最小権限の原則）
- ロールはJWTのclaimsに含める（データベースに毎回問い合わせない）
- リソースレベルの権限はポリシーオブジェクトで管理（コードに書かない）

### 禁止パターン
- JWTシークレットをコードにハードコード（必ず環境変数）
- 全エラーに同じメッセージを返す（ユーザー列挙攻撃への対策）
- SQLクエリにユーザー入力を直接埋め込む

「禁止パターン」のセクションが特に重要だ。「JWTシークレットをハードコードしない」は当たり前のように思えるが、急いで実装するときに環境変数設定を後回しにしてしまうケースが実際に起きる。CLAUDE.mdに禁止として定義しておくことで、Claude Codeがコードを生成するときに自動的に環境変数から読み込む実装になる。

「全エラーに異なるメッセージを返す」実装は、ユーザー列挙攻撃（「このメールアドレスは登録済み」というメッセージからユーザーの存在を確認できる攻撃）への入口になる。CLAUDE.mdにこのルールを書くことで、Claude Codeが生成するエラーレスポンスが一律の形式になる。

OAuth/JWT実装の自動化——Auth0 MCPで設定とコードを一気通貫

Claude Codeへの認証実装指示はこのように書ける。

「Node.js + ExpressでGitHub OAuthログインを実装して。
セキュリティ要件:
- state パラメータ（Redis TTL 10分）でCSRF対策
- コールバック後にstateを検証・削除
- アクセストークンはHTTP-only Cookie（SameSite=Strict）
- JWTを発行（15分有効期限、RS256署名）
- リフレッシュトークンはbcryptでハッシュ後にDBに保存
- エラーレスポンスは全て同一メッセージ（ユーザー列挙対策）」

CLAUDE.mdに認証ポリシーが定義されていれば、この指示とCLAUDE.mdの組み合わせでOWASP準拠の実装が生成される。

Auth0は公式MCPサーバーを提供している（auth0.com/docs）。Claude CodeからAuth0を自然言語で操作できる。

claude mcp add auth0
# Auth0 MCPを使った自然言語操作
> "dev テナントに orders-api を作成して、
  scope として read:orders と write:orders を設定して"

Auth0 MCPにより「認証プロバイダーの設定」と「アプリケーションコードの実装」をClaude Codeで一気通貫して行える（auth0.com/docs、dev.to/auth0）。ユーザー管理・テナント設定・APIのauthorization system設定・カスタムロジックのデプロイ・ログのデバッグまで、Auth0 Dashboardを開かずに操作できる。

リフレッシュトークンのローテーション実装は、セキュリティ上の重要な設計だ。

// リフレッシュトークンローテーション
// 1. 古いリフレッシュトークンを無効化（1回使用制限）
await db.refreshTokens.update({
  where: { token: hashedOldToken },
  data: { revokedAt: new Date() }
});

// 2. 新しいリフレッシュトークンを発行
const newRefreshToken = crypto.randomBytes(64).toString('hex');
await db.refreshTokens.create({
  data: {
    token: await bcrypt.hash(newRefreshToken, 12),
    userId: payload.userId,
    expiresAt: addDays(new Date(), 7)
  }
});

「古いリフレッシュトークンが再利用された場合」はトークン盗難の証拠だ。無効化済みトークンの使用を検知したら、全セッションを強制ログアウトする設計も合わせて実装する。

並行セッションのレース条件も実在する問題だ。複数タブが同時にリフレッシュを試みると、最初のリクエストがトークンをローテーションした後、2番目のリクエストが無効化済みの古いトークンを使って失敗する。この問題はClaude Code CLI自体も経験している（github.com/anthropics/claude-code issue #24317）。アプリ実装での解決策としては、短時間内の複数使用を許可するMulti-useリフレッシュトークンか、専用プロセスを経由した共有セッション管理がある（実践的な観点から）。

RBAC × 認証テスト自動生成——権限マトリクスを網羅する

3層RBACのデコレータ実装はClaude Codeへのこのような指示で生成できる。

「FastAPIでRBACミドルウェアを実装して。
ロール: admin / lead / member の3層。
各エンドポイントにrequire_role('admin')のようなデコレータで保護。
ロールはJWTのclaimsから取得（DBに問い合わせない）」

JWTのclaimsにロールを含める設計により、認可チェックのたびにDBクエリが発生しない。毎リクエストでDB問い合わせが必要なRBAC実装は、高トラフィック時にボトルネックになりやすい。

AnthropicはClaude Code向けに複数のユーザーロールを実装しており（code.claude.com/docs/en/authentication）、EnterpriseプランではIDPとのSSO連携によるロール自動管理が提供されている。エンタープライズRBAC設計の参考になる。

認証テストのカバレッジは「ロール×エンドポイントの権限マトリクス」で考える必要がある。Claude Codeへの指示はこうなる。

「/api/orders エンドポイントの認証テストを書いて。
必要なテストケース:
1. 未認証ユーザー → 401
2. 認証済み member → 自分の注文のみ200
3. 認証済み member で他人の注文を取得 → 403
4. 期限切れJWT → 401（エラーメッセージ: 'Token expired'）
5. 改ざんされたJWT → 401（エラーメッセージ: 'Invalid token'）
6. admin ロール → 全ての注文に200」

このテストケース設計は「adminは通る・memberは通らない」だけでなく、「memberが他人のリソースにアクセスした場合の403」「期限切れと改ざんで異なるエラー」という細かいエッジケースまでカバーしている。

テストに必要なモックユーティリティも合わせて生成できる。

- createMockUser(role: 'admin' | 'member' | 'guest') ファクトリー関数

- JWTテストジェネレーター（有効期限テスト・無効署名テスト）

- OAuth Callbackのモック（state validation テスト）

CLAUDE.mdに「認証コードのレビューチェックリスト（JWT設定・CSRF対策・SQL injection防止）」を定義しておくと、PRレビュー時にClaude Codeが自動でセキュリティチェックを実施するようになる。

まとめ

認証・認可の実装をClaude Codeで自動化する起点は、CLAUDE.mdにセキュリティポリシーを定義することだ。トークン管理・OAuth必須要件・禁止パターンを一度定義すれば、以降Claude Codeがそのポリシーに従って実装を生成する。「最初からセキュアな設計」が標準状態になる。

Auth0 MCPで認証プロバイダーの設定とアプリコードの実装を一気通貫させ、RBAC設計をAnthropicのエンタープライズRBAC実装（IDPとのSSO連携によるロール自動管理）を参考に設計し、権限マトリクスのテストでカバレッジを担保する——この流れが認証実装の品質を体系的に底上げする。

ただし繰り返しになるが、Claude Codeが生成した認証コードは必ずセキュリティレビューが必要だ。「Claude Codeが生成したから安全」ではなく、「CLAUDE.mdが正しい制約を定義していて、その制約に従った実装をレビューで確認する」というサイクルが本質だ。まずCLAUDE.mdに禁止パターンを5行定義するところから始めてほしい。

コメント

タイトルとURLをコピーしました