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 only
      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을 쓸 때:
  - 전통적인 서버 사이드 렌더링 웹앱 (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_TuYI3OG85AmiExREkrS6tDfTQ2B3WXlrr-wp5AokiRbz3_oB4OxG-W9KcEEbDRcZc0nH3L7LzYptiy1PtAylQGxHTWZXtGz4ht0bAecBgmpdgXMguEIcoqPJ1n3pIWk_dUZegpqx0Lka21H6XxUTxiy8OcaarA8zdnPUnV6AmNP3ecFawIFYdvJB_cm-GvpCSbr8G8y_Mllj8f4x9nBH8pQux89_6gUY618iYv7tuPWBFfEbLxtF2pZS6YC1aSfLQxaOoaBSTqJoKn5L

[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 갱신에만 사용
  - 더 엄격하게 보호

1. 클라이언트가 Access Token으로 API 요청
2. 서버가 401 반환 (토큰 만료)
3. 클라이언트가 Refresh Token으로 새 Access Token 요청
   POST /token
     grant_type=refresh_token&
     refresh_token=REFRESH_TOKEN_VALUE&
     client_id=CLIENT_ID
4. 서버가 새 Access Token (+ 새 Refresh Token) 반환
5. 클라이언트가 새 Access Token으로 재요청

// 권장: httpOnly Cookie로 토큰 저장 (서버)
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' })
  }

  // 이미 사용된 토큰인지 확인 (Reuse Detection)
  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"
}

모든 OIDC 프로바이더는 Discovery 문서를 제공합니다:

GET https://accounts.google.com/.well-known/openid-configuration

응답에 포함되는 정보:
  - issuer: 프로바이더 식별자
  - authorization_endpoint: 인가 엔드포인트
  - token_endpoint: 토큰 엔드포인트
  - userinfo_endpoint: 사용자 정보 엔드포인트
  - jwks_uri: 공개키 세트 URL
  - scopes_supported: 지원 스코프
  - response_types_supported: 지원 응답 타입

// 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();
    }
}

# application.yml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://auth.example.com
          jwk-set-uri: https://auth.example.com/.well-known/jwks.json

// 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)
  [ ] 환경 변수로 민감 정보 관리
  [ ] 정기적인 보안 감사