JWT(Json Web Token)은 Json 형태로 주고받을 수 있는 토큰입니다. JWT는 Base64를 사용하여 인코딩하지만, URL에서 사용할 수 있도록 URL safe 구조로 이루어져 있습니다. 크게 header, payload, signature라는 구조를 갖고 있으며, 이들은 .으로 구분되도록 구성되었습니다.
HEADER.PAYLOAD.SIGNATURE
각 요소가 갖고있는 정보는 아래와 같습니다.
- Header는 토큰의 종류나 해싱알고리즘이 포함되어 있습니다.
- Payload에는 사용자 혹은 토큰에 대한 정보를 key-value 형태로 저장합니다. 표준 스펙은 아래와 같습니다.
- 1. iss(Issuer): 토큰 발급자
- 2. sub(Subject): 토큰 제목
- 3. aud(Audience): 토큰 대상자
- 4. exp(Expiration Time): 토큰 만료 시간
- 5. nbf(Not Before): 토큰 활성 날짜
- 6. iat(Issued At): 토큰 발급 시간
- 7. jti(JWT ID): JWT 토큰 식별자
이 외에도 유저의 아이디 등 payload에 추가 정보를 포함하여도 무방합니다.
유의해야 할 점은 Header와 Payload는 모두 base64로 인코딩되어있을 뿐 암호화는 되어있지 않으므로 민감한 정보는 포함시키지 말아야 합니다.
Signature 부분은 토큰의 유효성 검증을 위한 요소로, 헤더에 정의한 알고리즘과 서버의 비밀 키를 사용하여 생성하고 Base64로 인코딩합니다.
JWT의 특징
- JWT의 장점은 HTTP API의 특징 중 하나인 stateless하다는 것입니다. 따라서 stateful하지 않기 때문에 서버를 scale out한다고 할 때에도 크게 무리가 없을 것이라고 생각합니다.
- 위에서 언급했듯이 payload는 암호화되어있지 않으므로 중요한 정보는 포함하면 안됩니다.
- 토큰에 정보를 입력할수록 토큰의 길이가 길어집니다. 따라서 최소한의 정보만을 저장해야할 것입니다.
JWT를 사용하는 이유?
- 위에서 언급했듯이, JWT를 사용한 로그인은 HTTP 통신에서 완벽한 stateless를 부여합니다. 따라서 요즘 유행하는 MSA 아키텍처에서 로그인 기능을 구현할 때 정말 좋은 방법이라고 생각합니다.
- MSA 아키텍처가 아니라도, 모델 서빙 등의 이유로 API 서버가 분리되어야 할 경우에도 좋은 활용방안이라고 생각합니다. 실제로 온프레미스와 클라우드를 섞어서 사용해야할 상황이 존재할텐데, 이 때에도 로그인 기능을 JWT로 사용하는 것이 좋은 방안일 것이라고 생각합니다.
'기타' 카테고리의 다른 글
OpenACC 디버깅 모드 (0) | 2024.02.14 |
---|---|
좋지 않은 예외처리로 인하여 디버깅이 어려워지는 경우 (0) | 2022.02.08 |