Contents

JWT

JWT 는 유저를 인증하고 식별하기 위한 토큰(Token)기반 인증이다. RFC 7519 에 자세한 명세가 나와있다. 토큰은 세션과는 달리 서버가 아닌 클라이언트에 저장되기 때문에 메모리나 스토리지 등을 통해 세션을 관리했던 서버의 부담을 덜 수 있다.

JWT 가 가지는 핵심적인 특징이 있다면, 토큰 자체에 사용자의 권한 정보나 서비스를 사용하기 위한 정보가 포함(Self-contained)된다는 것이다. 데이터가 많아지면 토큰이 커질 수 있으며 토큰이 한 번 발급된 이후 사용자의 정보를 바꾸더라도 토큰을 재발급하지 않는 이상 반영되지 않는다.

JWT 를 사용하면 RESTful 과 같은 무상태(Stateless)인 환경에서 사용자 데이터를 주고 받을 수 있게된다. 세션(Session)을 사용하게 될 경우에는 쿠키 등을 통해 식별하고 서버에 세션을 저장했지만 JWT 와 같은 토큰을 클라이언트에 저장하고 요청시 단순히 HTTP 헤더에 토큰을 첨부하는 것만으로도 단순하게 데이터를 요청하고 응답을 받아올 수 있다.

JWT 동작순서

일반적으로 JWT를 사용하면 아래와 같은 순서로 진행된다.

  1. 클라이언트 사용자가 아이디, 패스워드를 통해 웹서비스 인증.
  2. 서버에서 서명된(Signed) JWT 를 생성하여 클라이언트에 응답으로 돌려주기.
  3. 클라이언트가 서버에 데이터를 추가적으로 요구할 때 JWT 를 HTTP Header 에 첨부.
  4. 서버에서 클라이언트로부터 온 JWT 를 검증.

JWT는 JSON 데이터를 Base64 URL-safe Encode 를 통해 인코딩하여 직렬화한 것이 포함되며 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 있다. 따라서 사용자가 JWT 를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.

Base64 URL-safe Encode
Base64 URL-safe Encode는 일반적인 Base64 Encode 에서 URL 에서 오류없이 사용하도록 ‘+’, ‘/’ 를 각각 ‘-’, ‘_’ 로 표현한 것이다.

구조

JWT 의 구조를 살펴보자. JWT는 Header, Payload, Signature 로 구성된다. 또한 각 요소는 . 으로 구분된다. Header에는 JWT 에서 사용할 타입과 해시 알고리즘의 종류가 담겨있으며 Payload에는 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨있다. 마지막으로 Signature 에는 Header, Payload 를 Base64 URL-safe Encode를 한 이후 Header에 명시된 해시함수를 적용하고, 개인키(Private Key)로 서명한 전자서명이 담겨있다. 전자서명 알고리즘으로 타원 곡선 암호화(ECDSA)를 사용한다고 가정하면,

Sig = ECDSA(SHA256(B64(Header).B64(Payload)), PrivateKey)

전자서명도 Base64 URL-safe Encode로 처리해서 합쳐줄 필요가 있다. 여기서 만든 전자서명은 Header, Payload 가 변조되었는지 확인하기 위해 사용되는 중요 정보이며 JWT 를 신뢰할 수 있는 토큰으로 사용할 수 있는 근거가 된다. 전자서명에는 비대칭 암호화 알고리즘을 사용하므로 암호화를 위한 키와 복호화를 위한 키가 다르다. 암호화(전자서명)에는 개인키를, 복호화(검증)에는 공개키를 사용한다.

이를 JWT 로 표현하려면, 다음과 같다.

JWT = B64(Header).B64(Payload).B64(Sig)

참고

https://pronist.dev/143