JWT (JSON Web Token)
기본 특성
- JWT는 유저를 인증하고 식별하기 위한 토큰(Token) 기반 인증.
- 토큰은 세션과 다르게 서버가 아닌 클라이언트에 저장
- 상태가 없는(stateless) 서비스에 적용 가능
🚨 중요!
토큰 자체에 사용자의 권한 정보나 서비스를 사용하기 위한 정보가 포함(Self-contained)되어 있다.
Work flow
- 클라이언트 사용자가 아이디, 패스워드를 통해 웹서비스 인증.
- 서버에서 사용자 정보 확인 후, JWT 발급하여 데이터와 함께 응답
- 클라이언트가 서버에 데이터를 추가 요청 시에 HTTP Header에 JWT 첨부
- 서버에서 JWT 인증 후 데이터 반환
JWT 구조
⌛ TL;DR
- JWT는 Header, Payload, Signature로 구성된다. 또한 각 요소는 '.'으로 구분되어 있다.
- JWT는 JSON 데이터를 Base64 URL-safe Encoding*를 통해 직렬화 한 값(Header**, Payload**)과 위변조 방지를 위해 개인키를 통한 전자서명을 포함한다.
* Base64 URL-safe Encoding: Base64 Encode에서 URL 오류 방지를 위해 ‘+’, ‘/’를 ‘-’, ‘_’로 표현한 인코딩
** Header: 토큰과 해시 알고리즘 타입 정보
** Payload: 서버에서 전달할 Data
1) Header
- JWT에서 사용할 타입과 해시 알고리즘의 종류를 명시
2) Payload
- 서버에서 첨부한 사용자 권한 정보와 데이터
3) Signature(전자서명)
- 데이터의 위변조를 검증하기 위한 전자서명
Sig=ECDSA(SHA256(B64(Header).B64(Payload)), PrivateKey)
Header, Payload → Base64 URL-safe Encoding → SHA256(Header에 명시된 해시 알고리즘) → 개인키를 통한 ECDSA 암호화
4) 최종 JWT 구조
JWT=B64(Header).B64(Payload).B64(Sig)
**전자서명 자체도 Base64 URL-safe 인코딩한다.
5) 정리
장점
- JWT는 최근 웹서비스에서 범용적으로 사용되고 있어 다양한 클라이언트(웹, 모바일 등)에서 호환성이 뛰어나다.
- RESTful과 같은 무상태(stateless) 환경에서의 통신이 용이하다.
- 데이터를 자체적으로 가지고 있어 서버 요청 횟수가 둘어든다.
단점
- 자체적으로 데이터를 가지고 있기 때문에 Payload가 커지면 토큰이 커져 서버에 부담.
- 토큰이 재발급되기 전까지 사용자 정보가 갱신되더라도 반영되지 않는다.
- 토큰의 만료시간 전까지는 강제로 삭제 및 만료가 불가하다. → 노출되었을 경우 문제 발생