해결책
사용자가 로그인하면 서버는 보통 세션 ID를 발급하고 사용자를 테이블에 저장하며, 이후 각 요청은 그 테이블을 조회한다. 이는 단일 서버에서는 동작하지만, 상태를 저장하지 않는 API 서버의 클러스터는 캐시나 스티키 세션 없이는 인메모리 테이블을 공유할 수 없다.
JWT는 사용자의 클레임을 토큰 자체로 옮긴다. 토큰은 URL 안전한 압축 JSON 페이로드이며, 위조할 수 없도록 서명된다. 서버는 서명을 확인하고 토큰에서 클레임을 바로 읽는다.
그 결과는 상태 비저장 인증이다. 공개 키를 아는 어떤 서버든 공유 세션 저장소 없이 어떤 사용자든 검증할 수 있다. 클레임과 증명이 함께 이동하기 때문에 JWT가 API 인증과 싱글 사인온의 기본이 되었다.
이룬 것
클레임을 토큰에 담고, 서명이 증명이 된다.
통한 이유
토큰이 자기 완결적이기 때문에 검증자는 데이터베이스 호출이 필요 없어, 요청 경로가 평평하고 빠르게 유지된다.
세션이 아니라 서명이 신뢰의 닻이므로, 키를 가진 어떤 상태 비저장 서버든 어떤 토큰이든 검증할 수 있다.
세 부분으로 된 header.payload.signature 구조는 웹 생태계의 모든 언어가 구현하기에 간단하다.
OAuth 및 OpenID Connect와 결합되므로, 같은 토큰이 여러 서비스와 제품에서 동작한다.
증명이 클레임과 함께 이동한다면, 신원이 조회가 아니라 자기 완결적이 되므로 어디서든 검증하고 검증자를 수평으로 확장할 수 있다.
여파
JWT는 2015년 5월 RFC 7519로 표준화되었으며, JWS/JWE 계열을 포함한다. 싱글 페이지 앱 인증, API 게이트웨이, 마이크로서비스의 기본이 되었다. 알려진 약점은 폐기(거부 목록 없이는 만료 전에 토큰을 무효화할 수 없음)와 알고리즘 혼동 버그, 그리고 불투명 세션 대비 크기 오버헤드이다.
근거 확인하기
출처
- RFC 7519: JSON Web Token (JWT) IETF / RFC Editor · rfc-editor.org
- JSON Web Token Wikipedia · en.wikipedia.org