TL;DR
- 인증·인가에 쓰는 토큰(token)은 요청에 담아 보내는 문자열 자격증명이다.
- 참조 토큰은 저장소 조회로 검증하며 서명형 JWT는 서명과 클레임을 검증한다.
- JWT는 세션 저장소를 매번 조회하지 않고 검증할 수 있다. 다만 개별 토큰의 즉시 취소에는 별도 상태 관리가 필요할 수 있다.
토큰과 JWT: 참조 조회와 자체 검증의 차이
HTTP 자체는 요청 사이의 로그인 상태를 관리하지 않는다. 인증이 필요한 요청에서는 클라이언트가 토큰 같은 자격증명을 보내고 서버가 이를 검증한다. 여기서 다루는 토큰은 사용자나 애플리케이션의 신원 또는 접근 권한을 확인하는 데 쓰는 문자열이다. 토큰을 가졌다는 사실만으로 모든 작업이 허용되는 것은 아니다.
브라우저에서는 세션 ID나 JWT를 쿠키로 전달할 수 있고 API 요청의 Authorization 헤더에 토큰을 담을 수도 있다. 네이티브 앱도 HTTP 라이브러리의 쿠키 저장소를 사용할 수 있다. 토큰의 형식과 운반 방식은 별개의 선택이다. Apple HTTPCookieStorage.
참조 토큰(reference)과 자기완결 토큰(JWT)
인증 토큰을 비교할 때는 값을 조회해 검증하는 참조 방식과, 토큰 안의 정보를 검증하는 자기완결 방식을 구분할 수 있다. 아래 JWT는 암호화하지 않은 서명형을 전제한다.
| 구분 | 참조 토큰(reference) | 자기완결 토큰(JWT) |
|---|---|---|
| 담는 것 | 의미 없는 식별자 하나 | 사용자 정보(클레임) + 서명 |
| 검증 방법 | 서버가 저장소에서 유효성·권한 조회 | 신뢰하는 키로 서명 검증 + 클레임 검사 |
| 상태 | 토큰에 대응하는 상태를 서버가 보관 | 토큰별 저장소 조회를 생략할 수 있음; 취소 정책 등에 따라 상태 추가 |
| 길이 | 보통 짧다 | 담는 정보에 따라 길어짐 (쿠키 용량 한계를 넘기도 한다) |
참조 토큰은 저장소의 상태를 가리키는 식별자다. 서명형 JWT는 클레임을 담으므로 세션 저장소를 매번 조회하지 않고 검증할 수 있다. 서버는 허용 알고리즘과 신뢰하는 키로 서명을 검증하고 용도에 따라 발급자(iss)·대상 서비스(aud)·만료 시각(exp)·사용 가능 시각(nbf)도 확인한다. 서명이 맞아도 다른 서비스용이거나 만료된 토큰은 거절해야 한다. 필요한 클레임과 권한 검사 규칙은 애플리케이션이 정한다. RFC 8725 §3, RFC 7519 §4.1.
서명형 JWT는 내용을 숨기지 않는다
암호화하지 않은 서명형 JWT(JWS)는 토큰을 가진 사람이 페이로드를 읽을 수 있으므로 비밀 정보를 넣으면 안 된다. 서명은 내용의 변조 여부와 발급 주체를 검증하는 수단이며 탈취한 토큰의 재사용까지 막지는 않는다. JWT에는 암호화형(JWE)도 있으므로 JWT 전체를 암호화 불가능한 형식으로 설명해서는 안 된다. RFC 7519 §3.
세션 인증과의 비교: 취소 가능성
서버 저장형 세션은 세션 ID에 대응하는 로그인 상태를 서버 저장소에 보관한다. 그 상태를 확인하고 변경하는 방식으로 계정 통제 기능을 만들 수 있다.
- 강제 로그아웃: 세션을 무효화하면 이후 검증에서 해당 ID를 거절한다. 캐시가 있다면 무효화도 전파해야 한다.
- 기기별 로그아웃: 기기별 세션을 구분해 특정 세션만 무효화한다.
- 동시 접속 제한: 활성 세션이나 스트리밍 상태를 추적하고 서비스 정책에 따라 제한한다.
이 기능들은 서버의 상태 추적과 정책 집행으로 구현한다. 특정 서비스가 이런 기능을 제공한다는 사실만으로 내부 저장소나 토큰 형식을 알 수는 없다. 세션 저장에는 메모리·Redis·관계형 DB 등을 사용할 수 있으며 지연·가용성·만료 처리·운영 비용을 함께 고려한다.
JWT의 서명과 클레임만 검사하는 구조에서는 개별 토큰을 만료 전에 취소하기 어렵다. 취소 목록이나 사용자별 토큰 버전을 조회하면 통제할 수 있지만 서버 상태와 조회 비용이 추가된다. 짧은 만료는 잔여 유효 시간을 줄일 뿐 즉시 취소가 아니다. 리프레시 토큰을 취소해도 기존 액세스 토큰이 즉시 무효화되는지는 검증 정책에 달려 있다. OWASP JWT, RFC 7009 §3.
언제 무엇을 쓰나
즉시 취소 요구, 토큰을 검증하는 서비스 수, 기존 인증 프레임워크를 기준으로 선택한다. 서버 저장형 세션은 중앙에서 상태를 통제하기 쉽고 JWT는 여러 서비스가 발급자를 신뢰하는 키로 검증하도록 구성할 수 있다. JWT라고 항상 구현이 쉽거나 비용이 낮은 것은 아니다. 키 관리·클레임 검증·취소 정책까지 포함해 비교해야 한다.
Connections
- 세션 - 여러 요청에 상태를 잇는 논리적 범위 — 참조 토큰이 가리키는 서버 측 상태 범위를 정의한다.
- 쿠키 - 브라우저가 기억하고 되돌려보내는 키-값 — 웹에서 토큰(세션 ID)을 실어 나르는 운반 수단이다.
Discussion
Comments
댓글은 승인 후 공개됩니다.