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

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

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

정의

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

공격 시나리오

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 의 기본값.

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

2. CSRF Token (Synchronizer Token)

sequenceDiagram
    C->>Server: GET /form
    Server->>Server: token = random()
    Server-->>C: HTML + <input name="_csrf" value="token"><br/>(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 의 깔끔한 패턴.

어디에 어떤 방어?

환경	권장
클래식 서버 렌더링 (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

GET 의 위험성

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

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

흔한 함정

[!WARNING]

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

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

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

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

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

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

정의

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

구조: 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 방지)

서명 알고리즘

Alg	종류	비고
`HS256/384/512`	HMAC (대칭)	양측이 같은 secret. 내부
`RS256/384/512`	RSA (비대칭)	private 으로 sign, public 으로 verify
`ES256/384/512`	ECDSA	짧고 빠름
`EdDSA`	Ed25519	가장 빠름, 안전
`none`	서명 없음	사용 금지 (취약점 다수)

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

흐름

sequenceDiagram
    autonumber
    participant C as Client
    participant Auth as Auth Server
    participant API as API Server

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

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 패턴이 정통.

Stateless vs Stateful

{}

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

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

Revoke 전략 (Stateless 의 단점 보완)

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

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 방어 가 중요.

흔한 함정

[!WARNING]

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

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

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

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

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

JWE (암호화 변형)

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

[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 만

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

koa (김신건) — Thu, 25 Jun 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 흐름 위조 가능. 모든 클라이언트 필수.

OAuth vs OpenID Connect

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

자세한 건 [[OpenID Connect]] 참고.

흔한 함정

[!WARNING]

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

state 미사용 = CSRF.

PKCE 없이 public client = intercept 공격.

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

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

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

koa (김신건) — Thu, 25 Jun 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 활성화 신호

흐름

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, ... }

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`

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) 의 토대.

사용 라이브러리

언어	라이브러리
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 로 매핑.

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

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

정의

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

핵심 역할

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

SP-initiated SSO 흐름

sequenceDiagram
    autonumber
    participant U as User
    participant SP as Service Provider
    participant IdP as Identity Provider

    U->>SP: GET /app (로그인 안 됨)
    SP->>U: 302 → IdP<br/>SAMLRequest (AuthnRequest, base64+deflate)
    U->>IdP: SAMLRequest
    IdP->>U: 로그인 화면
    U->>IdP: id + password
    IdP->>IdP: SAML Response 생성<br/>(Assertion + 서명)
    IdP->>U: HTML form 자동 submit<br/>SAMLResponse
    U->>SP: POST /acs<br/>SAMLResponse
    SP->>SP: Assertion 검증 (서명 + 유효시간)
    SP-->>U: 세션 시작

SP-initiated = 서비스 (SaaS) 가 먼저 redirect. IdP-initiated = IdP 의 사용자 포털에서 클릭.

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 자동 교환.

SAML vs OIDC

항목	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 이 압도적.

단점 / 함정

[!WARNING]

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

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

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

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

보안: Assertion 검증 체크리스트

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

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

koa (김신건) — Thu, 25 Jun 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 없음 강제

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 적용.

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

Stateless vs Stateful

{}

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

보안 체크리스트

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

Session Fixation

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

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

흔한 함정

[!WARNING]

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

Secure 없음 = HTTP → HTTPS 전환에서 평문 노출.

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

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

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

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

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

정의

공격 시나리오

4가지 방어 패턴

1. SameSite Cookie

2. CSRF Token (Synchronizer Token)

3. Double Submit Cookie

4. Custom Header (XHR/Fetch 한정)

어디에 어떤 방어?

GET 의 위험성

흔한 함정

관련 위키

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

정의

구조: 3 부분

표준 클레임

서명 알고리즘

흐름

Access Token vs Refresh Token

Stateless vs Stateful

Revoke 전략 (Stateless 의 단점 보완)

XSS / CSRF 와의 관계

흔한 함정

JWE (암호화 변형)

관련 위키

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

정의

TLS vs mTLS 흐름

인증서 발급 흐름

사용 시나리오

1. Service Mesh (Istio, Linkerd, Consul)

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

3. 기업 VPN / Zero Trust

4. IoT / 디바이스

인증서 회전

OAuth + mTLS (RFC 8705)

흔한 함정

인증서 형식

관련 위키

[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 방어)

OAuth vs OpenID Connect

흔한 함정

관련 위키

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

정의

흐름

id_token 의 표준 클레임

Discovery: .well-known/openid-configuration

JWKS (JSON Web Key Set)

OIDC 흐름 종류

SSO (Single Sign-On)

사용 라이브러리

OIDC vs OAuth vs SAML

흔한 함정

관련 위키

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

정의

핵심 역할

SP-initiated SSO 흐름

SAML Assertion (XML)

Metadata 교환

SAML vs OIDC

단점 / 함정

보안: Assertion 검증 체크리스트

관련 위키

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

정의

쿠키 속성

SameSite 3 모드

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