[WEB] JWT(JSON Web Token)이란?

JWT를 사용하는 이유 (세션의 단점)

클라이언트가 무수히 많을 경우 하나의 서버로 모든 요청을 처리하기 버거움

대부분의 대용량 트래픽을 다루는 회사들은 여러 개의 가용서버를 운영

클라이언트의 요청은 가용 상태에 따라 적절히 서버로 이동(로드 밸런싱)

이때 문제는 각각의 서버마다 다른 세션 저장소를 가진다는 것

따라서 최초에 접속한 서버에 세션 아이디가 저장되고, 클라이언트는 쿠키를 부여받음

그런데 만약 다른 서버로 다음에 연결되면, 해당 클라이언트는 쿠키를 부여받았지만 처음 접속한 걸로 취급받음

이를 해결하는 방법은 다음과 같다.

1. 최초에 들어간 서버로 계속 들어가게 만든다.
2. 세션 저장소의 내용을 복제한다.
3. DB에 세션 내용을 저장한 후, 공유해서 사용한다. => but 속도가 느림

결국 셋다 까다롭다. JWT를 사용하면 위의 세션이 지니는 문제점들을 해결할 수 있다.

 

JWT(JSON Web Token)

JWT는 당사자간에 정보를 JSON 객체로 안전하게 전송하기 위한 방법이다.

JWT는 디지털 서명이 되어 있으므로, 신뢰할 수 있다.

JWT의 암호화 알고리즘은 RSA 혹은 HMAC 방식을 사용한다.

JWT의 핵심은 암호화 된 정보와 서명된 토큰이다.

 

JWT 구조

1. Header

헤더는 일반적으로 토큰 타입과 서명에 쓰인 알고리즘의 종류 두 부분으로 구성된다.

그런 다음 해당 JSON은 Base64Url로 인코딩되어 JWT의 첫번째 부분을 형성한다.

2. Payload

페이로드에는 클레임을 포함한다. 클레임은 엔티티(일반적으로 사용자) 및 추가 데이터에 대한 설명이다.

클레임에는 다음 세가지가 존재한다.

- 등록된 클레임

필수는 아니지만, 권장되는 클레임, iss(발행자), exp(만료 시간), sub(주제), aud(청중) 등을 포함한다.

- 공개 소유권 클레임

JWT를 사용하는 사람들이 커스터마이징 가능, 그러나 충돌을 방지하려면 IANA JWT Registry에서 정의해야한다.

혹은 충돌 방지 네임 스페이스를 포함하는 URI로 정의해야한다.

- 개인 클레임

사용에 동의하고, 위의 클레임이 아닌 당사자간에 정보를 공유하기 위한 클레임이다.

그런 다음 해당 페이로드는 Base64Url로 인코딩되어 JWT의 두번째 부분을 형성한다.

 

3. Signature 

인코딩 된 헤더와 페이로드, 개인 키를 헤더에 지정된 알고리즘 방식을 통해 암호화한다.

 

JWT 실행 과정

 

JWT - HS256

1. HMAC으로 암호화된 signature 를 복호화 시킨 후에, 여기서 나온 header, payload 그리고 서버의 시크릿키를 이용해서 다시 토큰을 만든다음 생성된 토큰과 클라이언트로 날아온 토큰을 비교

2. 비교하여 맞다면, 정상이니 payload에 포함되어있는 정보를 이용하여 유저정보를 디비에서 셀렉 후 가공하여 반환

 

JWT - RSA

시크릿키가 필요없으니 사용하지않고, 서버쪽의 개인키로 잠군다음 자기가 잠군걸 자기 공개키로 계속 풀어내는 방식 

이때 공개키로 풀어도 괜찮은 것은 애초에 jwt의 payload에는 전자서명의 기능을 목적으로 이용하는거라 중간에 공개되어도 상관없음

 

 

 

 

Reference

www.youtube.com/playlist?list=PL93mKxaRDidERCyMaobSLkvSPzYtIk0Ah

Springboot - 시큐리티 특강

jwt.io/introduction

JWT.IO