OAuth2＆JWT完全攻略：認証・認可の全て — 開発者のための実践ガイド

空港セキュリティチェック：

1. 認証（Authentication）：パスポート検査
   - 「この人は本当に田中太郎か？」
   - パスポート（パスワード）で身元確認

2. 認可（Authorization）：搭乗券確認
   - 「田中太郎はこの飛行機に乗れるか？」
   - 搭乗券（権限）でアクセス範囲を決定
   - ビジネスラウンジアクセス？一般搭乗？

間違った理解：
  「OAuth2は認証プロトコルである」 (X)
  「OAuth2は認可フレームワークである」 (O)

  OAuth2自体は「あなたは誰ですか？」に対する答えを提供しません。
  認証が必要ならOAuth2の上にOIDC（OpenID Connect）を使用する必要があります。

フロー：
1. ユーザーログイン（ID/PW）
2. サーバーがセッション作成（サーバーメモリまたはRedis）
3. セッションIDをクッキーでクライアントに送信
4. 毎リクエストでクッキーによりセッションID送信
5. サーバーがセッションストアからユーザー情報を検索

// Express + express-session例
const session = require('express-session');
const RedisStore = require('connect-redis').default;
const redis = require('redis');

const redisClient = redis.createClient();

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true,       // HTTPSのみ
    httpOnly: true,      // JavaScriptアクセスブロック
    maxAge: 24 * 60 * 60 * 1000, // 24時間
    sameSite: 'lax',     // CSRF防止
  },
}));

// ログイン
app.post('/login', async (req, res) => {
  const user = await authenticateUser(req.body.email, req.body.password);
  if (!user) return res.status(401).json({ error: 'Invalid credentials' });

  req.session.userId = user.id;
  req.session.role = user.role;
  res.json({ message: 'Logged in successfully' });
});

// 認証ミドルウェア
function requireAuth(req, res, next) {
  if (!req.session.userId) {
    return res.status(401).json({ error: 'Authentication required' });
  }
  next();
}

フロー：
1. ユーザーログイン（ID/PW）
2. サーバーがJWT作成・署名
3. JWTをクライアントに送信
4. 毎リクエストでAuthorizationヘッダーにJWTを含む
5. サーバーがJWT署名を検証（セッションストア不要）

Sessionを使う場合：
  - 伝統的なサーバーサイドレンダリングWebアプリ（MPA）
  - 即座のセッション無効化が重要な場合
  - 単一サーバーまたは少数のサーバー

Token（JWT）を使う場合：
  - SPA（React、Vue、Angular）
  - モバイルアプリ
  - マイクロサービスアーキテクチャ
  - サードパーティAPIアクセス
  - サーバーレス環境

1. Resource Owner（リソースオーナー）
   → ユーザー本人。「自分のデータへのアクセスを許可する主体」

2. Client（クライアント）
   → アクセスを要求するアプリケーション。「ユーザーデータが必要なアプリ」

3. Authorization Server（認可サーバー）
   → ユーザーを認証しトークンを発行。「Google、GitHub、Keycloak等」

4. Resource Server（リソースサーバー）
   → 保護されたリソースをホスティング。「APIサーバー」

ステップバイステップフロー：

1. クライアント → 認可サーバー（認可リクエスト）
   GET /authorize?
     response_type=code&
     client_id=CLIENT_ID&
     redirect_uri=https://app.example.com/callback&
     scope=read write&
     state=random_csrf_token

2. ユーザーが認可サーバーでログイン・同意

3. 認可サーバー → クライアント（認可コード）
   302 Redirect: https://app.example.com/callback?
     code=AUTHORIZATION_CODE&
     state=random_csrf_token

4. クライアント → 認可サーバー（トークン交換）[バックチャネル、サーバー間]
   POST /token
     grant_type=authorization_code&
     code=AUTHORIZATION_CODE&
     redirect_uri=https://app.example.com/callback&
     client_id=CLIENT_ID&
     client_secret=CLIENT_SECRET

5. 認可サーバー → クライアント（トークンレスポンス）
   {
     "access_token": "eyJhbGciOiJSUzI...",
     "token_type": "Bearer",
     "expires_in": 3600,
     "refresh_token": "dGhpcyBpcyBhIHJl...",
     "scope": "read write"
   }

PKCE追加ステップ：

1. クライアントでcode_verifier生成（43-128文字のランダム文字列）
2. code_challenge = Base64URL(SHA256(code_verifier))
3. 認可リクエストにcode_challenge + code_challenge_method=S256を含む
4. トークン交換時にcode_verifierを送信（サーバーが検証）

// PKCE実装（JavaScript）
function generateCodeVerifier() {
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  return base64URLEncode(array);
}

async function generateCodeChallenge(verifier) {
  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const digest = await crypto.subtle.digest('SHA-256', data);
  return base64URLEncode(new Uint8Array(digest));
}

function base64URLEncode(buffer) {
  return btoa(String.fromCharCode(...buffer))
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=/g, '');
}

// 使用例
const codeVerifier = generateCodeVerifier();
const codeChallenge = await generateCodeChallenge(codeVerifier);

// 認可リクエスト
const authUrl = `https://auth.example.com/authorize?` +
  `response_type=code&` +
  `client_id=CLIENT_ID&` +
  `redirect_uri=https://app.example.com/callback&` +
  `scope=openid profile email&` +
  `code_challenge=${codeChallenge}&` +
  `code_challenge_method=S256&` +
  `state=${generateState()}`;

ステップ：

1. クライアント → 認可サーバー（直接トークンリクエスト）
   POST /token
     grant_type=client_credentials&
     client_id=SERVICE_A_ID&
     client_secret=SERVICE_A_SECRET&
     scope=api.read

2. 認可サーバー → クライアント（Access Token）
   {
     "access_token": "eyJhbGciOiJSUzI...",
     "token_type": "Bearer",
     "expires_in": 3600
   }
   （Refresh Tokenなし — 期限切れ時に再リクエスト）

# PythonでClient Credentialsリクエスト
import requests

response = requests.post('https://auth.example.com/token', data={
    'grant_type': 'client_credentials',
    'client_id': 'service-a',
    'client_secret': 'secret-value',
    'scope': 'api.read api.write',
})

token = response.json()['access_token']

ステップ：

1. デバイス → 認可サーバー（Device Codeリクエスト）
   POST /device/code
     client_id=TV_APP_ID&scope=openid profile

2. 認可サーバー → デバイス（Device Code + User Code）
   {
     "device_code": "DEVICE_CODE_HERE",
     "user_code": "ABCD-1234",
     "verification_uri": "https://auth.example.com/device",
     "expires_in": 1800,
     "interval": 5
   }

3. デバイスが画面に表示：「https://auth.example.com/device でABCD-1234を入力してください」

4. ユーザーが別のデバイス（スマホ、PC）でURL接続 → コード入力 → ログイン → 同意

5. デバイスが定期的にトークンをポーリング
   POST /token
     grant_type=urn:ietf:params:oauth:grant-type:device_code&
     device_code=DEVICE_CODE_HERE&
     client_id=TV_APP_ID

6. 認可完了後Access Token受信

Implicit Flowが廃止された理由：

1. Access TokenがURL Fragmentに露出（#access_token=...）
2. ブラウザ履歴にトークン記録
3. Referrerヘッダーによるトークン漏洩
4. トークン窃取攻撃に脆弱
5. Refresh Token使用不可

代替：Authorization Code + PKCE
   → ブラウザベースのアプリもこの方式を使用すべきです。
   → OAuth 2.1ドラフトでImplicit Flowは公式に削除

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.
POstGetfAytaZS82wHcjoTyoqhMyxXiWdR7Nn7A29DNSl0EiXLdwJ6xC6AfgZWF1bOsS...

[Header].[Payload].[Signature]

Header（Base64URL）：
{
  "alg": "RS256",    // 署名アルゴリズム
  "typ": "JWT",      // トークンタイプ
  "kid": "key-id-1"  // キーID（キーローテーション時）
}

Payload（Base64URL）：
{
  "sub": "1234567890",     // Subject（ユーザーID）
  "name": "John Doe",
  "email": "john@example.com",
  "role": "admin",
  "iss": "https://auth.example.com",  // Issuer（発行者）
  "aud": "https://api.example.com",   // Audience（受信者）
  "iat": 1516239022,       // Issued At（発行時間）
  "exp": 1516242622,       // Expiration（有効期限）
  "jti": "unique-token-id" // JWT ID（一意識別子）
}

Signature：
RSASHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  privateKey
)

HS256 vs RS256：

HS256（対称）：
  - 署名：secretKeyで署名
  - 検証：同じsecretKeyで検証
  - 問題：全サービスがsecretKeyを知る必要あり → 漏洩リスク

RS256（非対称）：
  - 署名：privateKeyで署名（認可サーバーのみ保有）
  - 検証：publicKeyで検証（誰でも可能）
  - 長所：privateKey漏洩なしに他サービスがトークン検証可能
  - 推奨：マイクロサービス環境

// Node.js JWT検証（jsonwebtoken）
const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

// JWKS（JSON Web Key Set）から公開鍵取得
const client = jwksClient({
  jwksUri: 'https://auth.example.com/.well-known/jwks.json',
  cache: true,
  rateLimit: true,
});

function getSigningKey(header, callback) {
  client.getSigningKey(header.kid, (err, key) => {
    if (err) return callback(err);
    callback(null, key.getPublicKey());
  });
}

// JWT検証ミドルウェア
function verifyToken(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'Missing token' });
  }

  const token = authHeader.substring(7);

  jwt.verify(token, getSigningKey, {
    algorithms: ['RS256'],
    issuer: 'https://auth.example.com',
    audience: 'https://api.example.com',
  }, (err, decoded) => {
    if (err) {
      if (err.name === 'TokenExpiredError') {
        return res.status(401).json({ error: 'Token expired' });
      }
      return res.status(401).json({ error: 'Invalid token' });
    }
    req.user = decoded;
    next();
  });
}

絶対にやってはいけないこと：
  1. JWTペイロードにパスワード、個人情報を保存（Base64は暗号化ではない！）
  2. "alg": "none"を許可（未署名トークンの受け入れ）
  3. 署名アルゴリズム変更攻撃を無視（RS256 → HS256ダウングレード）
  4. expクレームなしでトークン発行（永久に有効なトークン）
  5. トークンサイズを無限に大きくする（毎リクエストで送信される）

必ずやるべきこと：
  1. 常に署名検証（アルゴリズム固定）
  2. exp、iss、audクレームを検証
  3. HTTPSのみ使用
  4. 適切な有効期限を設定
  5. 必要最小限のクレームのみ含む

Access Token：
  - 短い寿命：15分〜1時間
  - 毎APIリクエストで使用
  - 期限切れ時はRefresh Tokenで更新

Refresh Token：
  - 長い寿命：7日〜30日
  - Access Token更新にのみ使用
  - より厳格に保護

// 推奨：httpOnlyクッキーでトークン保存（サーバー側）
res.cookie('access_token', accessToken, {
  httpOnly: true,    // JavaScriptアクセス不可
  secure: true,      // HTTPSでのみ送信
  sameSite: 'lax',   // CSRF防止
  maxAge: 15 * 60 * 1000, // 15分
  path: '/',
});

res.cookie('refresh_token', refreshToken, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  maxAge: 7 * 24 * 60 * 60 * 1000, // 7日
  path: '/api/auth/refresh', // refreshエンドポイントでのみ送信
});

通常方式：
  Refresh Token A → 新Access Token発行（Refresh Token A維持）
  問題：Refresh Tokenが窃取された場合、攻撃者が継続使用可能

Rotation方式：
  Refresh Token A → 新Access Token + 新Refresh Token B発行
                    （Refresh Token A無効化）
  利点：窃取されたRefresh Token使用時に即座に検知可能

検知メカニズム：
  1. 既に使用されたRefresh Token Aでリクエスト
  2. サーバー：「このトークンは既に交換済み → 窃取の可能性！」
  3. そのユーザーの全Refresh Tokenを無効化
  4. ユーザーに再ログインを要求

// Refresh Token Rotation実装
async function refreshTokenHandler(req, res) {
  const { refresh_token } = req.body;

  // DBでRefresh Tokenを検索
  const storedToken = await db.refreshTokens.findOne({ token: refresh_token });

  if (!storedToken) {
    return res.status(401).json({ error: 'Invalid refresh token' });
  }

  // 既に使用されたトークンか確認（再利用検知）
  if (storedToken.used) {
    // 窃取の可能性 → そのユーザーの全トークンを無効化
    await db.refreshTokens.deleteMany({ userId: storedToken.userId });
    return res.status(401).json({ error: 'Token reuse detected. All sessions revoked.' });
  }

  // 既存トークンを使用済みとしてマーク
  await db.refreshTokens.updateOne(
    { token: refresh_token },
    { used: true, usedAt: new Date() }
  );

  // 新トークン発行
  const newAccessToken = generateAccessToken(storedToken.userId);
  const newRefreshToken = generateRefreshToken();

  await db.refreshTokens.insertOne({
    token: newRefreshToken,
    userId: storedToken.userId,
    parentToken: refresh_token,
    used: false,
    expiresAt: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000),
  });

  res.json({
    access_token: newAccessToken,
    refresh_token: newRefreshToken,
  });
}

{
  "iss": "https://accounts.google.com",
  "sub": "110169484474386276334",
  "aud": "my-client-id",
  "exp": 1678886400,
  "iat": 1678882800,
  "nonce": "random-nonce-value",
  "name": "John Doe",
  "email": "john@gmail.com",
  "email_verified": true,
  "picture": "https://lh3.googleusercontent.com/photo.jpg"
}

// Spring Boot 3 + Spring Security 6設定
@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt
                    .jwtAuthenticationConverter(jwtAuthenticationConverter())
                )
            )
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            );

        return http.build();
    }

    @Bean
    public JwtAuthenticationConverter jwtAuthenticationConverter() {
        JwtGrantedAuthoritiesConverter converter = new JwtGrantedAuthoritiesConverter();
        converter.setAuthoritiesClaimName("roles");
        converter.setAuthorityPrefix("ROLE_");

        JwtAuthenticationConverter jwtConverter = new JwtAuthenticationConverter();
        jwtConverter.setJwtGrantedAuthoritiesConverter(converter);
        return jwtConverter;
    }

    @Bean
    public JwtDecoder jwtDecoder() {
        return NimbusJwtDecoder.withJwkSetUri(
            "https://auth.example.com/.well-known/jwks.json"
        ).build();
    }
}

// auth.ts（Auth.js v5設定）
import NextAuth from 'next-auth';
import GitHub from 'next-auth/providers/github';
import Google from 'next-auth/providers/google';
import Credentials from 'next-auth/providers/credentials';

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [
    GitHub({
      clientId: process.env.GITHUB_ID,
      clientSecret: process.env.GITHUB_SECRET,
    }),
    Google({
      clientId: process.env.GOOGLE_ID,
      clientSecret: process.env.GOOGLE_SECRET,
    }),
    Credentials({
      name: 'credentials',
      credentials: {
        email: { label: 'Email', type: 'email' },
        password: { label: 'Password', type: 'password' },
      },
      async authorize(credentials) {
        const user = await verifyCredentials(
          credentials.email as string,
          credentials.password as string,
        );
        return user || null;
      },
    }),
  ],
  callbacks: {
    async jwt({ token, user, account }) {
      if (user) {
        token.id = user.id;
        token.role = user.role;
      }
      if (account) {
        token.accessToken = account.access_token;
      }
      return token;
    },
    async session({ session, token }) {
      session.user.id = token.id as string;
      session.user.role = token.role as string;
      return session;
    },
  },
  pages: {
    signIn: '/login',
    error: '/auth/error',
  },
  session: {
    strategy: 'jwt',
    maxAge: 24 * 60 * 60, // 24時間
  },
});

// middleware.ts
import { auth } from './auth';

export default auth((req) => {
  const isLoggedIn = !!req.auth;
  const isProtected = req.nextUrl.pathname.startsWith('/dashboard');

  if (isProtected && !isLoggedIn) {
    return Response.redirect(new URL('/login', req.nextUrl));
  }
});

export const config = {
  matcher: ['/dashboard/:path*', '/api/protected/:path*'],
};

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"

    "github.com/coreos/go-oidc/v3/oidc"
    "golang.org/x/oauth2"
)

var (
    oauth2Config *oauth2.Config
    oidcVerifier *oidc.IDTokenVerifier
)

func init() {
    ctx := context.Background()
    provider, _ := oidc.NewProvider(ctx, "https://accounts.google.com")

    oauth2Config = &oauth2.Config{
        ClientID:     "CLIENT_ID",
        ClientSecret: "CLIENT_SECRET",
        RedirectURL:  "http://localhost:8080/callback",
        Endpoint:     provider.Endpoint(),
        Scopes:       []string{oidc.ScopeOpenID, "profile", "email"},
    }

    oidcVerifier = provider.Verifier(&oidc.Config{
        ClientID: "CLIENT_ID",
    })
}

func handleLogin(w http.ResponseWriter, r *http.Request) {
    state := generateState()
    http.Redirect(w, r, oauth2Config.AuthCodeURL(state), http.StatusFound)
}

func handleCallback(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    code := r.URL.Query().Get("code")

    // トークン交換
    token, err := oauth2Config.Exchange(ctx, code)
    if err != nil {
        http.Error(w, "Token exchange failed", http.StatusInternalServerError)
        return
    }

    // ID Token抽出・検証
    rawIDToken, ok := token.Extra("id_token").(string)
    if !ok {
        http.Error(w, "No ID token", http.StatusInternalServerError)
        return
    }

    idToken, err := oidcVerifier.Verify(ctx, rawIDToken)
    if err != nil {
        http.Error(w, "ID token verification failed", http.StatusInternalServerError)
        return
    }

    // クレーム抽出
    var claims struct {
        Email   string `json:"email"`
        Name    string `json:"name"`
        Picture string `json:"picture"`
    }
    idToken.Claims(&claims)

    json.NewEncoder(w).Encode(claims)
}

func main() {
    http.HandleFunc("/login", handleLogin)
    http.HandleFunc("/callback", handleCallback)
    fmt.Println("Server running on :8080")
    http.ListenAndServe(":8080", nil)
}

攻撃：
  ユーザーがログイン状態で悪意あるサイトを訪問
  → 悪意あるサイトがユーザーのクッキーを利用してAPIリクエスト

対策：
  1. SameSiteクッキー属性設定（LaxまたはStrict）
  2. CSRFトークン使用
  3. Origin/Refererヘッダー検証
  4. Authorizationヘッダー使用（クッキーの代わりに）

攻撃：
  XSS脆弱性を通じてJavaScript実行
  → localStorageのトークン窃取

対策：
  1. httpOnlyクッキーにトークン保存（JavaScriptアクセス不可）
  2. CSP（Content Security Policy）ヘッダー設定
  3. 入力値サニタイジング
  4. DOMPurify等のXSS防止ライブラリ使用

攻撃：
  URLパラメータにトークンを含む
  → Referrerヘッダー、ブラウザ履歴、サーバーログから漏洩

対策：
  1. トークンをURLに含めない
  2. AuthorizationヘッダーまたはhttpOnlyクッキー使用
  3. Referrer-Policyヘッダー設定

攻撃：
  有効なトークンを傍受して再利用

対策：
  1. 短いトークン有効期限
  2. jti（JWT ID）クレームで一回性確認
  3. nonce使用（OIDC）
  4. トークンバインディング（DPoP — Demonstration of Proof-of-Possession）

攻撃：
  RS256環境で攻撃者がalgをHS256に変更
  → 公開鍵をHS256の秘密鍵として使用して署名偽造

対策：
  1. サーバーで許可アルゴリズムを固定（algorithms: ['RS256']）
  2. algクレームを信頼しない
  3. 最新のJWTライブラリを使用

A07:2021 — Identification and Authentication Failures

チェックリスト：
  1. 弱いパスワードを許可しない
  2. ブルートフォース攻撃防止（アカウントロック、Rate Limiting）
  3. 多要素認証（MFA）サポート
  4. セッション固定攻撃防止（ログイン時にセッションID変更）
  5. 安全なパスワード保存（bcrypt、Argon2）
  6. トークン/セッション有効期限の実装
  7. ログアウト時のトークン/セッション完全無効化

セキュリティ基本：
  [ ] HTTPS必須（HTTPリダイレクト）
  [ ] 適切なトークン有効期限（Access: 15分、Refresh: 7日）
  [ ] httpOnly + Secure + SameSiteクッキー使用
  [ ] CORS正しく設定

トークン管理：
  [ ] Refresh Token Rotation適用
  [ ] トークンブラックリスト/無効化メカニズム
  [ ] JWT署名アルゴリズム固定（RS256/ES256）
  [ ] キーローテーション計画策定

入力検証：
  [ ] redirect_uriホワイトリスト検証
  [ ] stateパラメータでCSRF防止
  [ ] PKCE適用（SPA、モバイル）
  [ ] 入力値サニタイジング

モニタリング：
  [ ] ログイン失敗モニタリングとアラート
  [ ] 異常なトークン使用パターン検知
  [ ] Rate Limiting適用
  [ ] 監査ログ記録

インフラ：
  [ ] シークレット管理（AWS Secrets Manager、Vault）
  [ ] 環境変数で機密情報管理
  [ ] 定期的なセキュリティ監査