JWT 기반 사용자 식별 패턴 정리

3.1 일반적인 패턴은?

✅ JWT sub 사용 (가장 표준)

대부분의 OAuth/OIDC 시스템은 JWT 의 sub claim 으로 사용자 식별. 클라이언트가 받은 AT 에 본인 sub 가 있으니 서버는 토큰만 파싱하면 됨.

• 표준: RFC 7519 (JWT), OIDC Core spec
• 장점: 클라이언트가 별도 헤더를 넣을 필요 없음. 토큰만 서명 검증되면 신원 확정
• 단점: server-to-server (CC) 호출 시 sub 가 service-account 라 "어느 사용자에 대한 작업인지" 별도 표현 필요

⚠️ 헤더 기반 사용자 식별 (X-User-Uuid 등)

표준이 아니다. 각 시스템이 ad-hoc 으로 정의. service mesh / internal API gateway / impersonation 시나리오에서 보조적으로 쓴다.

용어 / 표준화 시도:

• "Impersonation header" — 다른 사용자로 행세할 때 (예: 관리자가 사용자 계정으로 동작)
• "On-Behalf-Of (OBO)" — RFC 8693 [OAuth 2.0 Token Exchange] 의 act-as / on-behalf-of 흐름. 토큰을 다른 사용자/주체용으로 교환하는 표준
• Kubernetes RBAC 의 Impersonate-User, Impersonate-Group 헤더 — 표준은 아니지만 K8s 표준 컨벤션
• AWS 의 X-Amz-Security-Token, Microsoft Graph 의 Authorization 외 별도 헤더 — 시스템별 ad-hoc

⚠️ Path parameter 기반 (/api/users/{userId}/...)

표준이라기보다 REST 리소스 모델링의 자연스러운 결과. URL 자체가 "어느 사용자에 대한 작업" 을 명시적으로 담음.

장점:

• 명확함 — URL 만 보고 어느 사용자인지 즉시 파악
• Swagger / OpenAPI 표현 간단 (@PathVariable)
• 캐싱 / 라우팅 / 모니터링 시 사용자별 분리 쉬움
• 권한 체크가 직관적: @PreAuthorize("#userId == authentication.token.subject")

단점:

• URL 에 사용자 UUID 노출 (보통 GET 요청은 access log 에 남음). 단 UUID 는 비밀이 아니라 큰 문제 아님
• service-account 호출 시 path 의 userId 와 JWT sub 가 일치하지 않는 게 정상 — hasRole('ADMIN') or #userId == sub 같은 SpEL 로 분기