김신건의 로그 - 위키 / auth-security

[Auth] OAuth 2.0 / 2.1: Authorization Code + PKCE

koa (김신건) — Thu, 16 Jul 2026 00:00:00 GMT

정의

OAuth 2.0 (RFC 6749, 2012) 은 제3자 앱이 사용자 동의로 자원에 접근 하게 하는 권한 위임 프레임워크. 인증 (authentication) 이 아니라 인가 (authorization).

OAuth 2.1 은 진행 중인 draft. 옛 flow 정리 + PKCE 의무화.

핵심 4 역할

flowchart LR
    User["Resource Owner<br/>사용자"] -->|동의| Auth["Authorization Server<br/>예: Google"]
    Client["Client App<br/>예: 우리 앱"] -->|토큰 요청| Auth
    Auth -->|access_token| Client
    Client -->|"토큰 + 요청"| Resource["Resource Server<br/>예: Google Drive API"]

Authorization Code Flow + PKCE (표준)

가장 일반적이고 OAuth 2.1 에서 유일하게 권장 되는 사용자 흐름.

sequenceDiagram
    autonumber
    participant U as User
    participant C as Client
    participant Auth as Auth Server
    participant API as Resource Server

    C->>C: code_verifier (랜덤 43-128자) 생성
    C->>C: code_challenge = SHA256(verifier) -> base64url
    C->>U: 브라우저 -> Auth 로 redirect<br/>?response_type=code&client_id=...<br/>&code_challenge=...&code_challenge_method=S256
    U->>Auth: 로그인 + 동의
    Auth-->>U: redirect to Client<br/>?code=ABC
    U-->>C: code=ABC 전달
    C->>Auth: POST /token<br/>code=ABC&code_verifier=<원본>&client_id=...
    Auth->>Auth: SHA256(verifier) == challenge?
    Auth-->>C: { access_token, refresh_token }
    C->>API: Authorization: Bearer <token>
    API-->>C: 자원

PKCE 가 왜 필수?

OAuth 2.0 의 옛날 implicit flow + public client (모바일 / SPA) 에서 intercept 공격. code_verifier 가 동적 공유 secret 처럼 작용.

[!IMPORTANT] 모든 OAuth 클라이언트는 PKCE 필수. 옛 라이브러리도 반드시 최신 버전.

다른 Flow

Flow	사용	상태
Authorization Code + PKCE	사용자 로그인 (웹/모바일)	권장
Client Credentials	서버 대 서버 (사용자 없음)	권장
Device Authorization	TV / CLI / 헤드리스	권장
Refresh Token	access_token 갱신	권장
Implicit	(옛 SPA)	폐기 (OAuth 2.1)
Resource Owner Password	password 직접 전달	폐기 (OAuth 2.1)

Client Credentials (서버끼리)

sequenceDiagram
    Service A->>Auth: POST /token<br/>client_id + client_secret<br/>grant_type=client_credentials
    Auth-->>Service A: { access_token, expires_in }
    Service A->>Service B: Bearer <token>
    Service B-->>Service A: 자원

Device Flow

sequenceDiagram
    Device->>Auth: POST /device/code
    Auth-->>Device: { device_code, user_code, verification_uri }
    Device->>User: "다른 기기로 https://x.com/code 가서 ABC123 입력"
    User->>Auth: 브라우저에서 ABC123 입력 + 동의
    loop poll
        Device->>Auth: POST /token (device_code)
        Auth-->>Device: 200 (성공) 또는 authorization_pending
    end

Apple TV, Roku, GitHub CLI (gh auth login) 같은 키보드 없는 기기.

OAuth 2.0 vs OAuth 2.1

항목	2.0	2.1
Implicit flow	허용	제거
Resource owner password	허용	제거
PKCE	권장	필수
Bearer token in URL	허용 (?token=)	제거
Refresh token rotation	옵션	권장
HTTPS	권장	필수

Scope

scope=read:files write:profile 같이 권한 범위 명시. Auth Server 가 사용자 동의 화면에 표시.

scope=openid profile email     # OpenID Connect
scope=read:items write:orders  # 자원 권한

State Parameter (CSRF 방어)

GET /authorize?...&state=<random>

Auth 가 같은 state 를 redirect 에 포함. 다른 사이트가 위조한 redirect 를 클라이언트가 거절.

[!CAUTION] state 검증 누락 = CSRF 공격에 OAuth 흐름 위조 가능. 모든 클라이언트 필수.

PKCE 구현 예시

// TypeScript (browser)
async function generatePKCE() {
  const verifier = crypto.randomUUID().replace(/-/g, '')
    + crypto.randomUUID().replace(/-/g, '');   // 64자

  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const digest = await crypto.subtle.digest('SHA-256', data);

  const challenge = btoa(String.fromCharCode(...new Uint8Array(digest)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');

  return { verifier, challenge };
}

// 사용 예
const { verifier, challenge } = await generatePKCE();
sessionStorage.setItem('pkce_verifier', verifier);

const authUrl = new URL('https://auth.example.com/authorize');
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('client_id', CLIENT_ID);
authUrl.searchParams.set('redirect_uri', REDIRECT_URI);
authUrl.searchParams.set('code_challenge', challenge);
authUrl.searchParams.set('code_challenge_method', 'S256');
authUrl.searchParams.set('state', crypto.randomUUID());
window.location.href = authUrl.toString();

토큰 수명과 갱신

토큰	수명	용도
`access_token`	5-60분 (짧을수록 좋음)	자원 접근에 사용
`refresh_token`	수일-수개월	access_token 재발급
`id_token` (OIDC)	보통 access_token 과 동일	사용자 정보 포함 JWT

Refresh Token Rotation (OAuth 2.1 권장):

refresh_token 을 한 번 사용하면 새 refresh_token 발급, 이전 무효화
탈취 탐지: 만료된 refresh_token 재사용 시 경보 + 세션 전체 무효화

POST /token
grant_type=refresh_token
refresh_token=<old_token>

-> { access_token: "...", refresh_token: "<new_token>", expires_in: 3600 }

Token Introspection / Revocation

# RFC 7662: Token Introspection
POST /introspect
token=<opaque_token>

-> { active: true, sub: "user123", scope: "read", exp: 1234567890 }

# RFC 7009: Token Revocation (로그아웃)
POST /revoke
token=<refresh_token>
token_type_hint=refresh_token

opaque token (불투명 토큰) 은 서버 DB 조회 필요. [[jwt|JWT]] 는 서명 검증으로 로컬 검증 가능하지만 revoke 가 어려움.

JWT vs Opaque Token

	JWT	Opaque Token
검증	로컬 (서명 확인)	서버 introspect 필요
Revocation	어려움 (TTL 만료 대기)	즉시 (DB 삭제)
크기	큰 편 (클레임 포함)	짧음
용도	API Gateway, stateless	Auth Server 중심

OAuth vs OpenID Connect

	OAuth 2.0	OIDC
목적	권한 위임 (자원 접근)	인증 (누구인지)
토큰	access_token	+ id_token (JWT)
User info	자원 API 로 별도 조회	id_token 안에
표준화	기본	OAuth 2.0 위

자세한 건 [[openid-connect|OpenID Connect]] 참고.

흔한 함정

[!WARNING]

redirect_uri 검증 부재: open redirect 공격으로 코드 탈취.

state 미사용: CSRF.

PKCE 없이 public client: intercept 공격.

access_token 을 URL 에: 로그 / referrer 로 노출.

refresh_token 영구: 탈취 시 영구 침해. rotation (한 번 쓰면 새 발급 + 옛 무효화).

scope 최소화 무시: 필요한 scope 만 요청 (principle of least privilege).

보안 체크리스트

구현 전 점검:

항목	세부 사항
PKCE	모든 public client (SPA, 모바일) 에 적용
redirect_uri	정확한 값만 서버에 등록, prefix 매칭 금지
state	요청마다 새 random 값, callback 에서 검증
access_token 저장	`localStorage` 보다 메모리 또는 HttpOnly cookie
refresh_token 저장	HttpOnly cookie (XSS 접근 불가)
HTTPS	Auth Server 및 Client 모두 필수
scope	최소 필요 scope 만 요청
token rotation	refresh_token 사용 후 즉시 교체

실전 라이브러리

플랫폼	라이브러리
SPA (React/Vue)	`@auth0/auth0-react`, `oidc-client-ts`
Next.js	`next-auth` (Auth.js v5)
Node.js 서버	`passport-oauth2`, `openid-client`
Spring	`spring-security-oauth2-client`
Python	`authlib`, `python-social-auth`
Mobile (iOS)	`AppAuth-iOS`
Mobile (Android)	`AppAuth-Android`

[Auth] CSRF: 위조 요청 공격과 방어

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

CSRF (Cross-Site Request Forgery) 는 사용자가 로그인된 상태 에서 공격자가 만든 페이지 가 피해자 브라우저로 위조 요청 을 보내는 공격. 쿠키 기반 인증의 큰 약점.

CSRF vs XSS

항목	CSRF	XSS
공격 경로	브라우저 자동 쿠키 첨부 악용	피해 사이트에 스크립트 주입
피해 사이트 코드 조작	불필요	필요
피해자 의도	피해자가 요청을 모름	피해자 브라우저에서 코드 실행
방어 포인트	서버: 요청 출처 검증	서버: 출력 인코딩
쿠키 의존	쿠키 기반 세션에 한정	어떤 인증 방식도 영향

공격 시나리오

sequenceDiagram
    autonumber
    participant V as Victim
    participant Bank as bank.com
    participant Evil as evil.com

    V->>Bank: 로그인
    Bank-->>V: Set-Cookie: session=ABC
    V->>Evil: 다른 탭에서 evil.com 방문
    Evil-->>V: HTML with <form action="bank.com/transfer">
    Note over V: HTML 안의 form 자동 submit (JS)
    V->>Bank: POST /transfer<br/>(자동 첨부 cookie: session=ABC)<br/>amount=1000&to=attacker
    Bank->>Bank: 인증된 세션 → 정상 처리
    Bank-->>V: 200 OK (이미 이체 됨)

핵심: 브라우저가 쿠키를 자동 첨부 한다는 점을 악용. XSS 와 다름. CSRF 는 공격자가 페이지에 코드 주입 못 해도 가능.

4가지 방어 패턴

flowchart TD
    Q{방어 패턴}
    Q --> A["1. SameSite Cookie<br/>(가장 단순)"]
    Q --> B["2. CSRF Token<br/>(Synchronizer)"]
    Q --> C["3. Double Submit Cookie"]
    Q --> D["4. Custom Header"]

Set-Cookie: SID=abc; HttpOnly; Secure; SameSite=Lax

SameSite=Lax 가 cross-site form POST 차단. 2020 부터 Chrome 의 기본값.

SameSite 값	Cross-site GET	Cross-site POST	설명
`Strict`	차단	차단	완전 격리, 외부 링크 클릭도 차단
`Lax`	top-level 허용	차단	기본값, 대부분의 CSRF 차단
`None`	허용	허용	`Secure` 필수, iframe / 3rd-party 용

[!IMPORTANT] SameSite=Lax 만으로도 대부분의 CSRF 차단. 옛 브라우저 호환 이 필요하면 추가 패턴.

2. CSRF Token (Synchronizer Token)

sequenceDiagram
    C->>Server: GET /form
    Server->>Server: token = random()
    Server-->>C: HTML + hidden input _csrf=token (session 에 token 저장)
    C->>Server: POST /transfer<br/>_csrf=token + body
    Server->>Server: session 의 token == 받은 token?
    Server-->>C: OK / 거절

각 폼/요청마다 고유 token.
session 에 서버 측 저장 + 폼 hidden field.
Rails, Django, Spring 기본 적용.

GET /form
→ Set-Cookie: csrf_token=ABC
→ HTML: <input name="_csrf" value="ABC">

POST /transfer
→ Cookie: csrf_token=ABC
→ Body: _csrf=ABC

Server: cookie 의 csrf_token == body 의 _csrf ?

서버 측 저장 없이 동작.
단점: subdomain 의 cookie 침해 시 우회.

4. Custom Header (XHR/Fetch 한정)

fetch('/api/transfer', {
  method: 'POST',
  headers: {
    'X-Requested-With': 'XMLHttpRequest',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({...}),
});

Simple Request 가 아니므로 CORS preflight 발생.
다른 origin 이면 preflight 거절 → 위조 요청 애초에 불가.
SPA + API 의 깔끔한 패턴.

Origin / Referer 헤더 검증

서버에서 요청 출처를 직접 확인하는 보조 방어:

# 서버 측 Origin 검증 예시
def check_origin(request):
    origin = request.headers.get('Origin')
    referer = request.headers.get('Referer')
    allowed = {'https://myapp.com', 'https://www.myapp.com'}
    if origin:
        return origin in allowed
    if referer:
        return any(referer.startswith(o) for o in allowed)
    return False  # 둘 다 없으면 거절

[!WARNING] Referer 는 브라우저 설정 / 프록시로 제거될 수 있음. Origin + CSRF Token 을 같이 사용 권장. Referer 만으로는 불충분.

프레임워크 기본 내장

프레임워크	CSRF 방어
Django	`CsrfViewMiddleware` 기본 활성화 (`{% csrf_token %}` 태그)
Rails	`protect_from_forgery :exception` 기본
Spring Security	`csrf()` 기본 활성화 (JWT 사용 시 disable)
Laravel	`VerifyCsrfToken` 미들웨어 기본
Express	`csrf` 패키지 별도 설치 필요

서버 렌더링 프레임워크는 기본 내장. SPA 는 별도 설정 필요.

CORS 와 CSRF 관계

CORS 와 CSRF 는 다른 문제. 혼동 주의.

flowchart LR
    CORS["CORS<br/>(Cross-Origin Resource Sharing)"]
    CSRF["CSRF<br/>(Cross-Site Request Forgery)"]

    CORS -->|"브라우저가 cross-origin 요청 허용 여부"| Browser["브라우저 정책"]
    CSRF -->|"인증된 사용자 대신 위조 요청"| Attack["공격 방어"]

항목	CORS	CSRF
목적	다른 origin 의 JS 가 응답 읽기 허용	위조 요청 자체를 차단
방어 대상	응답 데이터 노출	상태 변경 요청 위조
Simple Request	preflight 없음 → CORS 우회 가능	CSRF 공격 가능
관계	CORS 허용해도 CSRF 방어 별도 필요	CSRF 방어해도 CORS 설정 별도 필요

[!WARNING] CORS 를 허용했다고 CSRF 가 방어되는 것이 아님. Simple Request (form POST) 는 preflight 없이 전송되어 CORS 와 무관하게 CSRF 공격 가능.

어디에 어떤 방어?

환경	권장
클래식 서버 렌더링 (Rails, Django)	CSRF token + SameSite=Lax
SPA + REST API	Custom header + SameSite=Strict
API + JWT in `Authorization` 헤더	대부분 영향 없음 (cookie 안 씀)
모바일 앱 (자체 HTTP 라이브러리)	영향 없음
3rd-party 통합 (iframe)	SameSite=None + Secure + token

현대 브라우저 현황 (2024+)

flowchart TD
    Chrome["Chrome 80+<br/>SameSite=Lax 기본"]
    Firefox["Firefox 79+<br/>SameSite=Lax 기본"]
    Safari["Safari 13.1+<br/>SameSite 지원"]
    Old["IE / 구형 브라우저<br/>SameSite 미지원"]

    Chrome -->|"대부분 CSRF 자동 차단"| Safe["안전"]
    Firefox -->|"대부분 CSRF 자동 차단"| Safe
    Safari -->|"대부분 CSRF 자동 차단"| Safe
    Old -->|"추가 방어 필요"| Extra["CSRF Token 필수"]

브라우저	SameSite=Lax 기본	비고
Chrome 80+	적용	2020년 2월부터
Firefox 79+	적용	2020년 7월부터
Safari 13.1+	적용	2020년 3월부터
IE 11	미지원	레거시 환경은 CSRF Token 필수

현대 브라우저 환경에서는 SameSite=Lax 기본값으로 대부분 방어. 레거시 지원 필요 시 CSRF Token 병행.

GET 의 위험성

<img src="https://bank.com/transfer?to=attacker&amount=1000">

[!CAUTION] 상태 변경 GET 은 CSRF 의 가장 흔한 함정. 모든 변경 요청은 POST/PUT/DELETE 만. GET 은 idempotent + read-only.

토큰 구현 시 주의사항

CSRF Token 을 직접 구현할 때:

import secrets
import hmac
import hashlib

def generate_csrf_token(session_id: str, secret: str) -> str:
    # 세션 ID 와 서버 secret 으로 HMAC 생성
    # 단순 random 보다 세션 바인딩이 더 안전
    random_part = secrets.token_hex(16)
    mac = hmac.new(
        secret.encode(),
        f"{session_id}:{random_part}".encode(),
        hashlib.sha256,
    ).hexdigest()
    return f"{random_part}:{mac}"

단순 random() 토큰 은 서버 재시작 시 세션과 분리될 수 있음. HMAC 기반 토큰 이 더 안전하고 stateless 구현 가능.

흔한 함정

[!WARNING]

SameSite=None 인데 Secure 없음 = 브라우저가 거절. 옛 코드 깨짐.

CSRF token 을 모든 요청에서 동일 = 하나만 탈취 되면 모든 요청 위조. 세션 단위 회전.

GET 의 상태 변경 = SameSite=Lax 가 top-level GET 허용 → CSRF.

Multipart form 의 Content-Type = simple request 라 preflight 없음. Custom header 방어가 부분적.

JWT + cookie 혼합 = Authorization 헤더 JWT 는 안전하지만 cookie 에 저장된 JWT 는 CSRF 위험.

[Auth] JWT: 구조, 서명, 만료, refresh token

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

JWT (JSON Web Token) (RFC 7519) 은 base64url 인코딩된 JSON + 서명 형태의 self-contained token. 서버가 세션 저장 없이 클레임 검증 가능.

JWS vs JWE: 두 가지 형태

형태	풀네임	기능	사용
JWS	JSON Web Signature	서명 (무결성 보장)	대부분의 JWT (인증, 인가)
JWE	JSON Web Encryption	암호화 (기밀성 보장)	민감 정보 페이로드 필요 시

JWS: header.payload.signature           (페이로드 가시)
JWE: header.key.iv.ciphertext.tag       (페이로드 암호화)

일반적으로 “JWT” 는 JWS 를 의미. 페이로드는 암호화 아님 (base64 인코딩만).

구조: 3 부분

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsIm5hbWUiOiJrb2EiLCJleHAiOjE3MjAxMjM0NTZ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
↑ header                                  ↑ payload                                            ↑ signature

부분	형식
Header	`{ "alg": "HS256", "typ": "JWT" }`
Payload	`{ "sub": "42", "name": "koa", "exp": 1720123456 }`
Signature	HMAC-SHA256(base64(header) + ”.” + base64(payload), secret)

표준 클레임

클레임	의미
`iss`	issuer
`sub`	subject (user ID)
`aud`	audience
`exp`	만료 시각 (Unix epoch)
`nbf`	not before
`iat`	issued at
`jti`	JWT ID (unique, replay 방지)

서명 알고리즘: HS256 vs RS256

Alg	종류	키	비고
`HS256/384/512`	HMAC (대칭)	공유 secret	양측이 같은 키. 내부 서비스
`RS256/384/512`	RSA (비대칭)	private (sign) / public (verify)	권장. 공개키 배포 가능
`ES256/384/512`	ECDSA	private / public	짧고 빠름
`EdDSA` (Ed25519)	EdDSA	private / public	가장 빠름, 안전
`none`	서명 없음	-	절대 사용 금지

sequenceDiagram
    participant Auth as AuthServer
    participant API as APIServer
    participant Client as Client

    Note over Auth,API: RS256 키 배포 (1회)
    Auth->>API: 공개키 (JWKS endpoint or 환경변수)

    Note over Client,API: 인증 흐름
    Client->>Auth: POST /login
    Auth->>Auth: JWT 생성 (private key 로 서명)
    Auth-->>Client: access_token (JWT)
    Client->>API: GET /resource (Authorization: Bearer JWT)
    API->>API: 공개키로 서명 검증 (Auth 서버 접속 없음)
    API-->>Client: 200 OK

[!IMPORTANT] RS256: Auth Server 만 private key 보유. API Server 는 public key 로 검증. public key 유출돼도 토큰 위조 불가. HS256 은 secret 공유 필요 → 서비스 수 늘어날수록 위험.

흐름

sequenceDiagram
    autonumber
    participant C as Client
    participant Auth as AuthServer
    participant API as APIServer

    C->>Auth: POST /login (id, password)
    Auth->>Auth: 검증 + JWT 생성
    Auth-->>C: { access_token, refresh_token }
    C->>API: GET /me (Authorization: Bearer JWT)
    API->>API: JWT 검증 (서명 + exp)
    API-->>C: 200 OK
    Note over C: 만료 임박
    C->>Auth: POST /refresh (refresh_token)
    Auth-->>C: 새 access_token

Refresh Token Rotation 패턴

sequenceDiagram
    participant C as Client
    participant Auth as AuthServer

    C->>Auth: POST /refresh (RT=abc)
    Auth->>Auth: RT 검증, 새 AT + 새 RT 발급
    Auth->>Auth: 구 RT(abc) 무효화
    Auth-->>C: { access_token, refresh_token: xyz }
    Note over C,Auth: 탈취된 RT 로 재시도
    C->>Auth: POST /refresh (RT=abc 재사용 시도)
    Auth->>Auth: abc 무효화 확인
    Auth-->>C: 401 Unauthorized
    Auth->>Auth: 계정 전체 세션 강제 종료 (재사용 감지)

RT rotation: 매 refresh 마다 새 RT 발급 + 구 RT 즉시 무효화. 재사용 시 탈취 감지 → 전체 세션 폐기.

Access Token vs Refresh Token

항목	Access Token	Refresh Token
수명	짧음 (5분 ~ 1시간)	길음 (7일 ~ 30일)
저장	메모리 (브라우저 SPA)	HttpOnly cookie 또는 안전한 저장
매 요청 전송	예	갱신 시만
탈취 영향	짧은 시간 피해	큰 피해, 반드시 HttpOnly
Revoke	만료까지 어려움	DB 에 저장 + revoke 가능

[!IMPORTANT] Access token 을 localStorage 에 저장 하면 XSS 시 즉시 탈취. 메모리 + 새로고침 시 refresh 패턴이 정통.

alg=none 취약점

# 취약한 라이브러리 예시 (개념도)
import jwt

# 공격자가 만든 페이로드
malicious_header = {"alg": "none", "typ": "JWT"}
malicious_payload = {"sub": "1", "role": "admin", "exp": 9999999999}

# base64 인코딩 후 서명 없이 전송
token = base64(malicious_header) + "." + base64(malicious_payload) + "."
# → 취약 라이브러리는 서명 검증 없이 통과

방어:

# 안전한 사용법: 허용 alg 화이트리스트
decoded = jwt.decode(token, PUBLIC_KEY, algorithms=["RS256"])  # alg 명시
# algorithms=["RS256"] 에 없는 알고리즘은 거절

[!WARNING] alg: none 을 받는 라이브러리는 치명적 취약점. 항상 허용 alg 화이트리스트. 사용 라이브러리의 CVE 이력 확인.

Revoke 전략

flowchart TD
    Q{revoke 필요}
    Q --> A["짧은 exp + refresh<br/>대부분의 경우"]
    Q --> B["Blacklist (Redis)<br/>jti 등록"]
    Q --> C["Versioning<br/>user.token_version 비교"]
    A --> Best[추천]
    B --> Heavy[캐시 부담]
    C --> Sync[DB 한 번 조회 필요]

Redis Blacklist 구현:

// 로그아웃 시 jti 를 blacklist 에 등록
async function logout(jti: string, exp: number) {
  const ttl = exp - Math.floor(Date.now() / 1000);
  await redis.setex(`blacklist:${jti}`, ttl, "1");
}

// 검증 미들웨어
async function verifyToken(token: string) {
  const payload = jwt.verify(token, PUBLIC_KEY, { algorithms: ["RS256"] });
  const isBlacklisted = await redis.exists(`blacklist:${payload.jti}`);
  if (isBlacklisted) throw new Error("Token revoked");
  return payload;
}

XSS / CSRF 와의 관계

flowchart TD
    Store{저장 위치}
    Store --> A[localStorage] -->|XSS 시 탈취| Bad1[X]
    Store --> B["메모리 + HttpOnly cookie refresh"] -->|XSS 영향 적음| Good[O]
    Store --> C["HttpOnly cookie + SameSite=Strict"] -->|CSRF 안전 + XSS 안전| Best[권장]

[!IMPORTANT] Cookie 기반 이면 CSRF 방어 필요 (SameSite=Strict 또는 CSRF token). Bearer header 면 XSS 방어 가 중요.

Stateless vs Stateful

	Session (stateful)	JWT (stateless)
서버 저장소	필수	불필요
Revoke	즉시	만료까지 어려움
스케일	sticky session 필요	수평 확장 자유
페이로드	session ID 만 (작음)	전체 클레임 (큼)
갱신	서버 갱신	새 JWT 발급

[!CAUTION] “JWT 가 항상 더 좋다” 는 미신. 작은 monolith 에서는 session 이 더 단순 + 즉시 revoke 가능. JWT 는 분산 + 마이크로서비스 + 모바일 SDK 에서 진가.

흔한 함정

[!WARNING]

alg: none 허용 라이브러리 = 옛 라이브러리 일부. 즉시 업데이트.

HS256 vs RS256 혼동 = 공개키를 secret 으로 오해해 서명 받으면 모든 토큰 위조 가능 (CVE 다수).

만료 너무 김 = 탈취 시 피해 큼. 15분 ~ 1시간 권장.

secret 이 짧음 = secret 같이 무차별 공격 가능한 키. 32+ 바이트 랜덤.

민감 정보 페이로드 = JWT 는 암호화 아님 (base64 인코딩). password / 카드 번호 절대 금지.

Refresh token localStorage 저장 = XSS 취약. 반드시 HttpOnly cookie.

RT rotation 미적용 = 탈취된 RT 무한 재사용 가능.

JWT 크기와 성능 고려사항

JWT 는 매 요청 헤더에 포함. 크기가 커지면 네트워크 오버헤드:

클레임 수	대략 크기 (HS256)
최소 (sub, exp, iat)	~150 bytes
일반 (10개 클레임)	~300-400 bytes
과도 (role, permission 배열 포함)	1KB+

클레임 최소화: role 이름 대신 role ID, permission 배열 대신 scope string 으로 압축. 큰 권한 데이터는 DB 조회로.

JWE (암호화 변형)

JWT 가 서명만 이면 내용 노출. JWE 는 암호화 까지. 그러나 느리고 복잡. 대부분의 경우 민감 정보를 페이로드에 안 넣고 JWS (서명만) 만으로 충분.

[Auth] OpenID Connect (OIDC): OAuth 위의 인증 레이어

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

OpenID Connect (OIDC) 는 OAuth 2.0 위에 얹은 인증 (authentication) 표준. OAuth 가 권한 위임 (authorization), OIDC 가 “누구인지” 알려준다.

핵심 추가:

id_token (JWT): 사용자 식별 정보
/userinfo endpoint: 추가 프로필 정보
Discovery: .well-known/openid-configuration 으로 자동 설정
Scope openid: OIDC 활성화 신호

사용 시나리오

상황	OIDC 역할
SPA / 모바일 앱 로그인	Authorization Code + PKCE
기업 SSO	Okta / Keycloak → 여러 앱 자동 인증
소셜 로그인	Google / Kakao → 내 앱에서 id_token 검증
K8s API 인증	OIDC Provider 와 kube-apiserver 연동

흐름

sequenceDiagram
    autonumber
    participant U as User
    participant App as Client App
    participant Idp as OIDC Provider
    Note over App: scope=openid profile email
    App->>U: redirect to Idp
    U->>Idp: 로그인 + 동의
    Idp-->>App: code (Authorization Code)
    App->>Idp: POST /token<br/>code + verifier
    Idp-->>App: { access_token, id_token, refresh_token }
    App->>App: id_token (JWT) 검증
    App->>Idp: GET /userinfo (옵션)<br/>Bearer access_token
    Idp-->>App: { sub, name, email, picture, ... }

PKCE 상세 흐름

PKCE (Proof Key for Code Exchange) 는 Authorization Code 탈취 방지. 공개 클라이언트 (SPA, 모바일) 필수.

sequenceDiagram
    autonumber
    participant App as Client
    participant Idp as OIDC Provider

    App->>App: code_verifier = random 43-128자
    App->>App: code_challenge = BASE64URL(SHA256(verifier))
    App->>Idp: GET /auth?code_challenge=XXX&code_challenge_method=S256
    Idp-->>App: redirect + code
    App->>Idp: POST /token<br/>code + code_verifier
    Idp->>Idp: SHA256(verifier) == code_challenge?
    Idp-->>App: tokens

code 만 탈취해도 verifier 없이는 token 교환 불가. SPA 에서 PKCE 없는 Authorization Code Flow 는 안전하지 않음.

id_token 의 표준 클레임

클레임	의미
`iss`	Issuer (Idp URL)
`sub`	Subject (사용자 ID, 영구 식별자)
`aud`	Audience (Client ID)
`exp`	만료
`iat`	발급 시각
`auth_time`	사용자가 마지막으로 인증한 시각
`nonce`	replay 방지
`acr`	Authentication Context Class Reference
`amr`	Authentication Methods (`["pwd", "mfa"]`)
`azp`	Authorized Party
프로필	`name`, `given_name`, `family_name`, `email`, `email_verified`, `picture`

id_token 검증 절차

id_token 은 단순히 받는 것으로 충분하지 않음. 반드시 서버에서 검증.

flowchart TD
    T["id_token 수신"]
    T --> V1["1. JWT 서명 검증<br/>(JWKS 에서 키 가져오기)"]
    V1 --> V2["2. iss 검증<br/>(기대 Idp URL?)"]
    V2 --> V3["3. aud 검증<br/>(내 Client ID?)"]
    V3 --> V4["4. exp 검증<br/>(만료 안 됐나?)"]
    V4 --> V5["5. nonce 검증<br/>(replay 방지)"]
    V5 --> OK["인증 완료"]

# python-jose 예시
from jose import jwt

payload = jwt.decode(
    id_token,
    jwks,           # JWKS 에서 가져온 공개키
    algorithms=["RS256"],
    audience="my-client-id",
    issuer="https://accounts.google.com",
)
# payload["sub"] 가 사용자 영구 ID

Discovery: `.well-known/openid-configuration`

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

{
  "issuer": "https://accounts.google.com",
  "authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
  "token_endpoint": "https://oauth2.googleapis.com/token",
  "userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
  "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
  "scopes_supported": ["openid", "email", "profile"],
  "response_types_supported": ["code", "token", "id_token", ...],
  "id_token_signing_alg_values_supported": ["RS256"],
  ...
}

클라이언트는 Idp URL 하나만 알면 모든 endpoint 자동 발견. 신규 OIDC Provider 통합이 1줄.

JWKS (JSON Web Key Set)

curl https://www.googleapis.com/oauth2/v3/certs

{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "abc123",
      "n": "...",
      "e": "AQAB"
    }
  ]
}

Idp 가 공개키 공개.
클라이언트가 id_token 의 kid 로 해당 키 찾아 검증.
키 회전 시 복수 키 동시 공존.

OIDC 흐름 종류

Flow	응답 타입	사용
Authorization Code Flow + PKCE	`response_type=code`	권장 (모든 클라이언트)
Implicit Flow	`response_type=id_token token`	폐기
Hybrid Flow	`response_type=code id_token`	일부 경우

SSO (Single Sign-On)

flowchart LR
    User --> App1[App 1]
    User --> App2[App 2]
    User --> App3[App 3]
    App1 --> Idp[OIDC Provider]
    App2 --> Idp
    App3 --> Idp
    Idp --> Login[중앙 로그인 1회]

한 번 로그인 → 여러 앱 자동 인증. 기업 SSO (Okta, Auth0, Keycloak) 의 토대.

로그아웃 흐름

OIDC 는 로그아웃 도 표준화. 세 가지 방식:

방식	설명
RP-Initiated Logout	앱이 Idp 에 로그아웃 요청. Idp 세션 종료
Front-Channel Logout	Idp 가 모든 연결 앱에 로그아웃 알림 (iframe)
Back-Channel Logout	Idp 가 서버-서버로 로그아웃 알림 (더 안정)

# RP-Initiated Logout
GET https://idp.example.com/logout?
  id_token_hint=<id_token>&
  post_logout_redirect_uri=https://myapp.com/

[!WARNING] 로컬 세션만 지우는 것 은 완전한 로그아웃이 아님. Idp 세션도 종료 해야 SSO 전체에 영향.

K8s + OIDC 통합

kube-apiserver 에 OIDC Provider 를 연결해 kubectl 사용자 인증 에 활용:

# kube-apiserver 플래그
--oidc-issuer-url=https://accounts.google.com
--oidc-client-id=my-k8s-client
--oidc-username-claim=email
--oidc-groups-claim=groups

# kubeconfig 에 OIDC 토큰 설정
kubectl config set-credentials alice \
  --auth-provider=oidc \
  --auth-provider-arg=idp-issuer-url=https://accounts.google.com \
  --auth-provider-arg=client-id=my-k8s-client \
  --auth-provider-arg=id-token=<id_token>

OIDC 로 인증된 사용자 email / group 을 RBAC 의 subject 로 사용. 중앙 IdP 로 K8s 접근 제어 통합.

사용 라이브러리

언어	라이브러리
Node	passport-openidconnect, openid-client
Python	authlib, python-jose
Java	spring-security-oauth2-client, Nimbus JOSE
Go	go-oidc, oidc-mw
Ruby	omniauth-openid-connect

OIDC vs OAuth vs SAML

	OAuth 2.0	OIDC	SAML 2.0
목적	권한 위임	인증	인증 + 권한
토큰	access_token	+ id_token (JWT)	SAML Assertion (XML)
페이로드	bearer	JWT	XML
모바일 친화	좋음	최고	떨어짐
기업	일부	모던 표준	옛 표준, 여전히 많음

흔한 함정

[!WARNING]

id_token 만 신뢰 = aud, iss, exp, nonce 모두 검증해야 함.

JWKS 매 요청 fetch = 캐싱 필요 (보통 24h). 단 key rotation 시 빠르게 갱신.

sub 변경 = 같은 Idp 의 같은 사용자는 sub 가 영구 동일. 다른 Idp 의 같은 이메일은 다른 sub.

email 만 보고 사용자 식별 = 이메일 변경 가능. 항상 sub 로 매핑.

Implicit Flow 아직 사용 = 폐기된 방식. PKCE 있는 Authorization Code Flow 로 전환.

[Auth] SAML 2.0: XML 기반 기업 SSO

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

SAML 2.0 (Security Assertion Markup Language) 는 XML 기반 기업 SSO 표준. 2005년 OASIS 표준화. 모바일 친화도 / 단순성에서 OIDC 에 밀리지만 기업 / SaaS 통합의 옛 표준 으로 여전히 광범위.

핵심 역할

flowchart LR
    User --> SP["SP (Service Provider)<br/>예: Salesforce"]
    User --> IdP["IdP (Identity Provider)<br/>예: Okta"]
    SP --> IdP
    IdP --> SP

역할	설명	예시
SP (Service Provider)	서비스를 제공, IdP 에 인증 위임	Salesforce, Slack, GitHub Enterprise
IdP (Identity Provider)	신원 확인 + Assertion 발급	Okta, Azure AD, Google Workspace

SP-initiated SSO 흐름

sequenceDiagram
    autonumber
    participant U as User
    participant SP as ServiceProvider
    participant IdP as IdentityProvider

    U->>SP: GET /app (로그인 안 됨)
    SP->>U: 302 Redirect to IdP (SAMLRequest base64+deflate)
    U->>IdP: SAMLRequest 전달
    IdP->>U: 로그인 화면 표시
    U->>IdP: id + password 입력
    IdP->>IdP: SAML Response 생성 (Assertion + XML 서명)
    IdP->>U: HTML form 자동 submit (SAMLResponse)
    U->>SP: POST /acs (SAMLResponse)
    SP->>SP: Assertion 검증 (서명, 유효시간, Audience)
    SP-->>U: 세션 시작, 애플리케이션 접근 허용

SP-initiated = 서비스 (SaaS) 가 먼저 redirect. 가장 일반적.

IdP-initiated SSO 흐름

sequenceDiagram
    autonumber
    participant U as User
    participant IdP as IdentityProvider
    participant SP as ServiceProvider

    U->>IdP: IdP 포털에서 앱 아이콘 클릭
    IdP->>IdP: SAML Response 생성 (InResponseTo 없음)
    IdP->>U: HTML form 자동 submit (SAMLResponse)
    U->>SP: POST /acs (SAMLResponse)
    SP->>SP: Assertion 검증 (InResponseTo 검증 생략됨)
    SP-->>U: 세션 시작

[!WARNING] IdP-initiated 는 InResponseTo 가 없어 CSRF replay 공격에 취약. SP 가 허용 여부 명시 설정 필요.

HTTP Binding 비교

Binding	전송 방법	특징
HTTP-Redirect	URL query string (deflate + base64)	GET 요청, URL 길이 한계 (~2KB)
HTTP-POST	HTML form hidden field (base64)	POST 요청, 크기 제한 없음, XML 서명 전송 가능

AuthnRequest 는 대부분 HTTP-Redirect. SAMLResponse 는 반드시 HTTP-POST (서명 포함 크기 때문).

# HTTP-Redirect (AuthnRequest)
GET /sso?SAMLRequest=nJJBj9MwEIXv...&SigAlg=RSA-SHA256&Signature=abc...

# HTTP-POST (SAMLResponse)
POST /acs
Content-Type: application/x-www-form-urlencoded

SAMLResponse=PHNhbWxwO...

SAML Assertion (XML)

<saml:Assertion ID="..." IssueInstant="2026-06-25T12:00:00Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml:Subject>
    <saml:NameID Format="...:emailAddress">koa@example.com</saml:NameID>
    <saml:SubjectConfirmation Method="bearer">
      <saml:SubjectConfirmationData
        Recipient="https://sp.example.com/acs"
        NotOnOrAfter="2026-06-25T12:05:00Z"
        InResponseTo="<원래 AuthnRequest ID>"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions
    NotBefore="2026-06-25T12:00:00Z"
    NotOnOrAfter="2026-06-25T12:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://sp.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement AuthnInstant="2026-06-25T12:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>koa@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="department">
      <saml:AttributeValue>engineering</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Metadata 교환

SP 와 IdP 가 XML metadata 파일 로 사전 합의:

항목	SP metadata	IdP metadata
Entity ID	`https://sp.example.com`	`https://idp.example.com`
ACS URL	`https://sp.example.com/acs`	-
SSO URL	-	`https://idp.example.com/sso`
SLO URL	logout	logout
Certificate	서명 검증용 공개키	동일

대부분의 SaaS 는 URL 한 줄로 metadata 자동 교환.

SLO (Single Logout)

sequenceDiagram
    participant U as User
    participant SP as ServiceProvider
    participant IdP as IdentityProvider

    U->>SP: POST /logout
    SP->>U: Redirect to IdP (LogoutRequest)
    U->>IdP: LogoutRequest 전달
    IdP->>IdP: 세션 종료, 다른 SP 에 LogoutRequest 전파
    IdP-->>U: LogoutResponse (redirect to SP)
    U->>SP: LogoutResponse 전달
    SP-->>U: 로그아웃 완료

SLO 는 모든 SP 의 세션을 한 번에 종료. 구현이 복잡해 미구현 SP 도 많음.

SAML vs OIDC 선택

flowchart TD
    Q1{타겟 사용자}
    Q1 -->|기업 직원 SSO| Q2{기존 IdP?}
    Q1 -->|소비자 / 모바일| OIDC[OIDC / OAuth2 권장]
    Q2 -->|Okta, Azure AD, Ping| Q3{새 앱?}
    Q2 -->|Google, GitHub| OIDC
    Q3 -->|예| OIDC_ENT["OIDC 권장<br/>(단순, 모바일 지원)"]
    Q3 -->|기존 SAML SP 통합| SAML[SAML 유지]

항목	SAML 2.0	OIDC
출시	2005	2014
페이로드	XML	JSON (JWT)
크기	큼 (수 KB)	작음
모바일	떨어짐	우수
디버깅	복잡 (XML 서명)	단순
기업 SSO	전통적	부상 중
MFA / step-up	가능 (acr)	가능 (acr)
사용자 의도	토큰 발급 후 세션	토큰 자체 반복 사용

[!IMPORTANT] 2026 시점: 모바일 / 소비자 앱 = OIDC. 기업 SaaS 통합 (Workday, Salesforce, ServiceNow, Slack 등) = 여전히 SAML 이 압도적.

보안: Assertion 검증 체크리스트

검증	의미
Signature	XML-DSig 로 IdP 공개키 검증
Audience	내가 그 audience 인지
NotBefore / NotOnOrAfter	유효 시간
Issuer	신뢰하는 IdP 인지
InResponseTo	원래 보낸 AuthnRequest ID 와 일치
Replay	NotOnOrAfter 까지 받은 ID 중복 거절

XSW (XML Signature Wrapping) 공격

XML 서명 검증 구현 버그를 이용해 서명된 영역과 실제 처리 영역을 다르게 만드는 공격:

<!-- 공격자가 조작한 Assertion (개념도) -->
<saml:Assertion ID="evil" ...>
  <!-- 공격자가 원하는 내용 (서명 없음) -->
  <saml:NameID>admin@company.com</saml:NameID>
  <!-- 원본 서명된 Assertion 은 다른 위치에 숨겨짐 -->
</saml:Assertion>

방어: 검증된 XML 라이브러리 사용. Assertion ID 의 canonicalization 엄격 검증. 자체 XML 파서 구현 금지.

단점 / 함정

[!WARNING]

XML Canonicalization 의 함정 = 공백 처리 까지 정확해야 서명 검증. 라이브러리 버그 다수 (XSW 공격).

시계 어긋남 = NotBefore / NotOnOrAfter 검증에서 수십 초 clock skew 가 문제. NTP 필수.

메시지 크기 = HTTP-Redirect 으로 보내는 인코딩된 SAMLRequest 가 URL 길이 한계 초과 가능. HTTP-POST binding 사용.

Assertion 의 audience 검증 누락 = 다른 SP 의 assertion 이 재사용 가능.

IdP-initiated CSRF = InResponseTo 없으므로 replay 가능. SP 에서 허용 여부 명시.

Okta 설정 예시

실제 SaaS 통합에서 SP 설정 예시:

# Okta 앱 설정 (개념도)
SingleSignOnURL: https://app.example.com/auth/saml/callback  # ACS URL
Audience URI (Entity ID): https://app.example.com
NameID format: EmailAddress
Attribute Statements:
  - email: user.email
  - firstName: user.firstName
  - lastName: user.lastName
  - groups: user.groups

# python3-saml 라이브러리로 Assertion 검증
from onelogin.saml2.auth import OneLogin_Saml2_Auth

def prepare_django_request(request):
    return {
        "https": "on" if request.is_secure() else "off",
        "http_host": request.META["HTTP_HOST"],
        "script_name": request.META["PATH_INFO"],
        "post_data": request.POST.dict(),
    }

def acs(request):
    req = prepare_django_request(request)
    auth = OneLogin_Saml2_Auth(req, custom_base_path=settings.SAML_FOLDER)
    auth.process_response()
    errors = auth.get_errors()
    if not errors:
        user_email = auth.get_nameid()
        attributes = auth.get_attributes()
        # 세션 생성 로직

[Auth] Session Cookie: HttpOnly, SameSite, Secure flag

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

Session Cookie 는 서버가 발급한 임의 ID 를 쿠키에 보관. 매 요청 자동 첨부. 서버 측 세션 store (Redis, DB) 와 짝.

[!IMPORTANT] JWT 와의 비교: session = stateful, JWT = stateless. 작은-중간 모놀리스에서는 session 이 더 단순 + 즉시 revoke 가능. 분산 환경에서는 JWT.

쿠키 속성

Set-Cookie: SID=abc123; Path=/; Domain=example.com;
            Secure; HttpOnly; SameSite=Lax;
            Max-Age=3600

속성	의미
`HttpOnly`	JS 에서 접근 불가 (XSS 방어)
`Secure`	HTTPS 만
`SameSite=Strict\|Lax\|None`	cross-site 동작 제어
`Path`	URL prefix
`Domain`	도메인 범위
`Max-Age` / `Expires`	만료
`Partitioned` (2024+)	3rd-party cookie 격리
`__Host-` prefix	Secure + Path=/ + Domain 없음 강제

HTTP 세션 전체 흐름

sequenceDiagram
    autonumber
    participant C as Client
    participant W as WebServer
    participant S as SessionStore

    C->>W: POST /login (id, password)
    W->>S: session.set(SID, userId and expiresAt)
    W-->>C: 200 OK, Set-Cookie: SID=abc123, HttpOnly, Secure
    C->>W: GET /profile (Cookie: SID=abc123)
    W->>S: session.get(SID=abc123)
    S-->>W: userId=42, expiresAt=...
    W-->>C: 200 OK (profile data)
    Note over C,W: 로그아웃
    C->>W: POST /logout (Cookie: SID=abc123)
    W->>S: session.delete(SID=abc123)
    W-->>C: 200 OK, SID cleared (Max-Age=0)

로그아웃은 반드시 서버 store 도 삭제. 쿠키만 지우면 SID 재사용 가능.

SameSite 3 모드

flowchart TB
    Strict["Strict<br/>같은 site 만 cookie 전송"]
    Lax["Lax (기본)<br/>top-level GET 만 허용"]
    None["None<br/>모든 cross-site 허용 (+Secure 필수)"]
    Strict --> S1["가장 안전<br/>외부 링크 접근 시 로그인 풀림"]
    Lax --> L1["보안 + UX 균형<br/>대부분 권장"]
    None --> N1["3rd-party 통합<br/>(예: 임베드 위젯)"]

	Strict	Lax	None
직접 입력 (주소창)	O	O	O
외부 사이트 링크 클릭	X	O (top-level GET)	O
외부 폼 POST	X	X	O
`<img src="other.com">`	X	X	O
iframe POST	X	X	O

2020 부터 Chrome 의 기본값 = Lax. 명시하지 않은 옛 쿠키도 Lax 적용.

CSRF 공격과 방어

sequenceDiagram
    autonumber
    participant V as Victim
    participant A as AttackerSite
    participant B as BankSite

    V->>B: 로그인 (SID=abc 쿠키 발급)
    V->>A: 악성 사이트 방문
    A-->>V: "<form action='bank.com/transfer' method='POST'> 자동 submit"
    V->>B: POST /transfer (Cookie: SID=abc 자동 첨부, amount=100000)
    Note over B: CSRF 취약하면 정상 처리됨

방어 전략:

SameSite=Lax/Strict: 외부 POST 요청 시 쿠키 전송 차단
CSRF Token: 서버가 생성한 토큰을 폼에 hidden 필드로 삽입, 요청 시 검증
Double Submit Cookie: 쿠키와 헤더에 같은 토큰 → origin 확인 효과
Referer / Origin 헤더 검증: 신뢰할 수 없는 origin 차단

<!-- CSRF token 폼 예시 -->
<form method="POST" action="/transfer">
  <input type="hidden" name="_csrf" value="{{ csrf_token }}">
  <input type="number" name="amount">
  <button type="submit">송금</button>
</form>

Session Store 패턴

flowchart LR
    C[Client] -->|SID=abc| Web[Web App 1]
    C2[Client] -->|SID=abc| Web2[Web App 2]
    Web --> Store[(Session Store<br/>Redis)]
    Web2 --> Store

세션 store 옵션:

Store	특징
메모리	단일 노드, 재시작 시 손실
파일	단일 노드
Redis	분산 표준
DB (Postgres / MySQL)	단순 / 큰 부담
클라이언트 (encrypted cookie)	stateless 처럼. Express의 cookie-session, Rails encrypted cookie

구현 예시 (Node.js / Express)




const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

app.use(session({
  store: new RedisStore({ client: redisClient }),
  secret: process.env.SESSION_SECRET,  // 32+ bytes random
  resave: false,
  saveUninitialized: false,
  name: "__Host-SID",  // __Host- prefix 강제 보안
  cookie: {
    httpOnly: true,
    secure: true,           // HTTPS only
    sameSite: "lax",        // CSRF 완화
    maxAge: 1000 * 60 * 30, // 30분
  },
}));

Cookie Prefix (`Host-`, `Secure-`)

Prefix	강제 속성	효과
`__Host-`	Secure + Path=/ + Domain 없음	가장 강력. 서브도메인 격리
`__Secure-`	Secure 만	HTTPS 전송 보장

Set-Cookie: __Host-SID=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

__Host- 사용 시 Domain 속성을 설정하면 브라우저가 쿠키를 무시. Path=/ 강제.

Stateless vs Stateful

항목	Session (cookie)	JWT
서버 store	필수	불필요
Revoke	즉시 (DB 삭제)	만료까지 어려움
Cookie 자동 첨부	예	Bearer header 수동
CSRF	위험 (SameSite 로 완화)	덜 위험 (헤더면)
XSS	덜 위험 (HttpOnly)	localStorage 면 위험

Session Fixation

sequenceDiagram
    participant Att as Attacker
    participant S as Site
    participant V as Victim

    Att->>S: GET /login (SID=ATTACK123)
    S-->>Att: 응답
    Att->>V: "이 링크로 로그인해" (SID=ATTACK123 박힌 링크)
    V->>S: 로그인 + SID=ATTACK123 유지
    S->>S: 인증 성공, SID=ATTACK123 가 권한 가짐
    Att->>S: SID=ATTACK123 으로 접근
    Note over Att,S: Victim 의 권한 행사

방어: 로그인 직후 새 SID 발급. 옛 SID 무효화.

보안 체크리스트

✓ HttpOnly                (XSS 방어)
✓ Secure                  (HTTPS 만)
✓ SameSite=Lax 이상       (CSRF 완화)
✓ session 만료 짧게        (15-60분 inactive timeout)
✓ session rotation        (privilege escalation 시 새 SID)
✓ session_id 충분히 랜덤   (128+ bits)
✓ 로그아웃 시 server-side 삭제
✓ __Host- 또는 __Secure- prefix 사용
✓ CSRF token 또는 SameSite=Strict

흔한 함정

[!WARNING]

HttpOnly 없음 = XSS 1줄로 세션 탈취.

Secure 없음 = HTTP 구간에서 평문 노출.

SameSite 미설정 = 옛 브라우저는 None 처럼 동작 → CSRF.

세션 영구 = Max-Age 없이 영구 쿠키. 사용자 비활성 후에도 위험.

로그아웃이 cookie 만 삭제 = server-side store 에 그대로. 토큰이 재사용 가능.

Session Fixation 미방어 = 로그인 후 SID 교체 안 하면 공격자가 사전에 SID 심기 가능.

CHIPS (Cookies Having Independent Partitioned State): 3rd-party 쿠키 퇴장 이후 임베드 시나리오를 위한 대안.

Set-Cookie: __Host-widget_session=xyz; Secure; HttpOnly; SameSite=None; Partitioned

쿠키가 top-level site 별로 격리. a.com 에서 설정한 widget.com 쿠키는 b.com 에서 보이지 않음
Chrome 118+ 기본 지원, Firefox 지원 예정
기존 SameSite=None 임베드 쿠키의 미래 대안

Redis 세션 만료 패턴

// 비활성 만료: 활동 시마다 TTL 갱신
async function touchSession(sid: string) {
  const INACTIVE_TIMEOUT = 30 * 60; // 30분
  await redis.expire(`session:${sid}`, INACTIVE_TIMEOUT);
}

// 절대 만료: 최초 설정 후 고정
async function setSession(sid: string, data: object) {
  const ABSOLUTE_TIMEOUT = 8 * 60 * 60; // 8시간
  await redis.setex(`session:${sid}`, ABSOLUTE_TIMEOUT, JSON.stringify(data));
}

비활성 timeout + 절대 timeout 을 모두 적용하는 것이 정통. 비활성으로는 짧게 (30분), 절대값으로는 길게 (8시간).

[Auth] mTLS (Mutual TLS): 양방향 인증서 인증

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

mTLS (Mutual TLS) 는 서버뿐 아니라 클라이언트도 TLS 인증서로 자기 신분 증명. 일반 TLS = 서버 인증만, mTLS = 양방향.

활용: 서비스 메시 (Istio, Linkerd), 기업 내부 API, 금융 / B2B 통합, IoT 기기.

TLS vs mTLS 흐름

{}

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server

    rect rgb(220,240,220)
    Note over C,S: 일반 TLS
    C->>S: ClientHello
    S-->>C: ServerHello + Certificate
    C->>C: 서버 인증서 검증
    C-->>S: Finished
    end

    rect rgb(255,235,220)
    Note over C,S: mTLS
    C->>S: ClientHello
    S-->>C: ServerHello + Certificate<br/>+ CertificateRequest
    C->>S: ClientCertificate + Finished
    S->>S: 클라이언트 인증서 검증
    S-->>C: Finished
    end

인증서 발급 흐름

flowchart LR
    CA[Root CA] -->|sign| IntCA[Intermediate CA]
    IntCA -->|sign| ServerCert[Server Cert]
    IntCA -->|sign| ClientCert[Client Cert]
    Client -->|보유| ClientCert
    Server -->|보유| ServerCert

자세한 인증서 체인은 [[TLS]] 참고.

사용 시나리오

1. Service Mesh (Istio, Linkerd, Consul)

flowchart LR
    subgraph A[Service A]
        AApp[App]
        AProxy[Sidecar Envoy]
    end
    subgraph B[Service B]
        BProxy[Sidecar Envoy]
        BApp[App]
    end
    AApp -->|plain HTTP| AProxy
    AProxy -->|mTLS auto| BProxy
    BProxy -->|plain HTTP| BApp

애플리케이션이 mTLS 를 신경 쓰지 않음. Sidecar 가 자동.
Zero Trust 네트워크의 토대.

2. SPIFFE/SPIRE: 워크로드 신원

SPIFFE ID = spiffe://example.com/ns/prod/sa/web

쿠버네티스 ServiceAccount → SVID (SPIFFE Verifiable Identity Document) → 짧은 mTLS 인증서.

[!IMPORTANT] 수동 인증서 발급/배포 없이 SPIRE 가 자동 회전. 회전 주기는 시간 단위. 침해 시 영향 최소화.

3. 기업 VPN / Zero Trust

BeyondCorp 류 디바이스 인증 + 사용자 인증.
기기 인증서 + 사용자 OIDC.

4. IoT / 디바이스

수백만 디바이스 각자 인증서.
제조 시점에 발급 (factory cert).

인증서 회전

gantt
    title 인증서 라이프사이클
    dateFormat YYYY-MM-DD
    section Cert
    유효기간 1: 2026-01-01, 90d
    유효기간 2 (회전):  active, 2026-03-15, 90d
    유효기간 3 (회전):  2026-06-01, 90d

회전 주기	적합
1년	legacy 시스템
90일	Let’s Encrypt 표준
24시간	짧은 SVID (SPIFFE)
1시간	고보안 환경

짧을수록 침해 영향 최소화. 자동화 없으면 운영 불가.

OAuth + mTLS (RFC 8705)

OAuth 의 client_credentials 에서 client_secret 대신 client cert. 큰 기업 / 금융 API.

sequenceDiagram
    Service A->>Auth: POST /token<br/>(mTLS client cert)<br/>grant_type=client_credentials
    Auth->>Auth: cert 검증
    Auth-->>Service A: access_token (cnf claim 에 cert hash)
    Service A->>Service B: Bearer <token><br/>(mTLS, 같은 cert)
    Service B->>Service B: token 의 cnf == cert hash?
    Service B-->>Service A: 자원

흔한 함정

[!WARNING]

인증서 만료 사고 = 자동화 없으면 언젠가는 만료 → 서비스 다운. 모니터링 + 자동 갱신 필수.

인증서 회전과 사용 동시 = 회전 직후 옛 인증서로 검증 실패. grace period 필요.

CRL (Certificate Revocation List) 의 체크 누락 = 침해 인증서가 수개월 유효. 짧은 인증서 (SPIFFE) 가 현실적 답.

mTLS 끝점에 L7 LB = TLS 종료 시점에 클라이언트 인증서 정보 손실. X-Forwarded-Client-Cert 같은 헤더로 전달 또는 passthrough LB.

인증서 형식

형식	의미
`.crt` / `.pem`	base64 인코딩 X.509 (텍스트)
`.der`	binary DER
`.p7b` / `.p7c`	PKCS#7 (체인 포함)
`.pfx` / `.p12`	PKCS#12 (인증서 + private key)
`.key`	private key 만

mTLS vs 대안 비교

방식	강도	복잡도	주요 용도
mTLS	최강 (인증서 기반)	높음	서비스 간 Zero Trust
API Key	중간 (공유 비밀)	낮음	외부 API 파트너
JWT Bearer	중간 (서명 검증)	낮음	유저 인증, OIDC
HMAC 서명	중간 (요청 무결성)	중간	Webhook
IP Whitelist	낮음 (위조 가능)	낮음	최후 수단

[!IMPORTANT] mTLS 는 인증서 유효 + 개인키 보유를 동시에 증명. API Key 는 탈취 시 즉시 재사용 가능. 고보안 서비스 간 통신에는 mTLS.

OCSP vs CRL vs 단기 인증서

인증서 폐지 확인 3가지 방법:

flowchart TD
    Verify["인증서 유효성 확인"]
    Verify --> CRL["CRL 다운로드<br/>전체 폐지 목록"]
    Verify --> OCSP["OCSP 단건 조회<br/>실시간 CA 확인"]
    Verify --> Short["단기 인증서<br/>만료로 자동 폐지"]
    CRL --> R1["큰 파일, 갱신 지연"]
    OCSP --> R2["실시간, CA 의존성"]
    Short --> R3["자동화 필수, 권장 방식"]

방식	확인 방법	단점
CRL	CA 발행 폐지 목록 다운로드	큰 파일, 갱신 주기 지연
OCSP	실시간 CA 단건 조회	CA 다운 시 검증 불가 (Fail-Open 위험)
OCSP Stapling	서버가 미리 조회, 인증서에 첨부	서버 설정 필요
단기 인증서	짧은 유효기간 (SPIFFE)	자동화 없으면 운영 불가

디버깅: openssl s_client

# 서버 인증서 확인
openssl s_client -connect example.com:443 -showcerts

# mTLS: 클라이언트 인증서 제시
openssl s_client \
  -connect api.example.com:443 \
  -cert client.crt \
  -key client.key \
  -CAfile ca.crt

# ALPN 협상 확인
openssl s_client -alpn h2 -connect example.com:443 2>&1 | grep ALPN

주요 확인 포인트:

Verify return code: 0 (ok) = 검증 성공
SSL-Session: 안의 Protocol 및 Cipher Suite
Peer certificate: 서버 인증서 Subject / Issuer
No client certificate CA names sent = 서버가 클라이언트 인증서 요구 안 함

Istio PeerAuthentication (mTLS in K8s)

flowchart LR
    subgraph SvcA["Service A Pod"]
        AppA[App]
        ProxyA["Envoy Proxy<br/>자동 mTLS"]
    end
    subgraph SvcB["Service B Pod"]
        ProxyB["Envoy Proxy<br/>자동 mTLS"]
        AppB[App]
    end
    AppA -->|"plain HTTP"| ProxyA
    ProxyA -->|"mTLS (SPIFFE)"| ProxyB
    ProxyB -->|"plain HTTP"| AppB

# PeerAuthentication: 네임스페이스 전체 STRICT mTLS 강제
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

모드	동작
`PERMISSIVE`	mTLS + plain 혼용 (마이그레이션 중)
`STRICT`	mTLS 강제 (권장 최종 상태)
`DISABLE`	mTLS 비활성

[!TIP] PERMISSIVE 로 시작 → 모니터링으로 확인 → STRICT 로 전환. 한 번에 STRICT 하면 레거시 서비스 차단 위험.

구현 체크리스트

CA 인프라: 독립 Root CA, Intermediate CA 분리
인증서 만료 모니터링: Datadog, Prometheus alert
자동 갱신: SPIRE / cert-manager
grace period: 이전 인증서 30일 중복 신뢰
CRL 체크: OCSP Stapling 또는 단기 인증서
L7 LB 고려: passthrough 또는 X-Forwarded-Client-Cert
폐기 절차: 침해 시 즉시 폐기 + 신규 발급 SLA

김신건의 로그 - 위키 / auth-security

[Auth] OAuth 2.0 / 2.1: Authorization Code + PKCE

정의

핵심 4 역할

Authorization Code Flow + PKCE (표준)

PKCE 가 왜 필수?

다른 Flow

Client Credentials (서버끼리)

Device Flow

OAuth 2.0 vs OAuth 2.1

Scope

State Parameter (CSRF 방어)

PKCE 구현 예시

토큰 수명과 갱신

Token Introspection / Revocation

JWT vs Opaque Token

OAuth vs OpenID Connect

흔한 함정

보안 체크리스트

실전 라이브러리

관련 위키

[Auth] CSRF: 위조 요청 공격과 방어

정의

CSRF vs XSS

공격 시나리오

4가지 방어 패턴

1. SameSite Cookie

2. CSRF Token (Synchronizer Token)

3. Double Submit Cookie

4. Custom Header (XHR/Fetch 한정)

Origin / Referer 헤더 검증

프레임워크 기본 내장

CORS 와 CSRF 관계

어디에 어떤 방어?

현대 브라우저 현황 (2024+)

GET 의 위험성

토큰 구현 시 주의사항

흔한 함정

관련 위키

[Auth] JWT: 구조, 서명, 만료, refresh token

정의

JWS vs JWE: 두 가지 형태

구조: 3 부분

표준 클레임

서명 알고리즘: HS256 vs RS256

흐름

Refresh Token Rotation 패턴

Access Token vs Refresh Token

alg=none 취약점

Revoke 전략

XSS / CSRF 와의 관계

Stateless vs Stateful

흔한 함정

JWT 크기와 성능 고려사항

JWE (암호화 변형)

관련 위키

[Auth] OpenID Connect (OIDC): OAuth 위의 인증 레이어

정의

사용 시나리오

흐름

PKCE 상세 흐름

id_token 의 표준 클레임

id_token 검증 절차

Discovery: .well-known/openid-configuration

JWKS (JSON Web Key Set)

OIDC 흐름 종류

SSO (Single Sign-On)

로그아웃 흐름

K8s + OIDC 통합

사용 라이브러리

OIDC vs OAuth vs SAML

흔한 함정

관련 위키

[Auth] SAML 2.0: XML 기반 기업 SSO

정의

핵심 역할

SP-initiated SSO 흐름

IdP-initiated SSO 흐름

HTTP Binding 비교

SAML Assertion (XML)

Discovery: `.well-known/openid-configuration`

Cookie Prefix (`Host-`, `Secure-`)