최근 들어 JWT를 사용해 사용자 로그인 시스템을 구현하는 부분을 담당하게 되었다. 그래서 우선 JWT가 무엇인지 조사부터 진행해보았다.
JWT
- JSON Web Token의 약자로 전자 서명 된 URL-safe(URL로 이용할 수 있는 문자만 구성된)의 JSON이다.
- JWT는 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준이다.
- JWT는 서버와 클라이언트 간 정보를 주고받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정 없이 헤더에 포함되어 있는 JWT 정보를 통해 인증한다.
- 이때 사용되는 JSON 데이터는 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 만든다.
- JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있다.
Claim Token(클레임 토큰)
클레임 토큰에서 클레이란 단어는 사용자의 정보나 데이터 속성등을 의미한다.
.(점) 을 구분자로 으로 나눠 표현된다. 각 값은 base64로 인코딩 되어있으며
크게 3가지의 요소로 구성된다.
- 헤더(header)
- typ과 alg 두가지 정보로 구성되어 있다.
- typ은 토큰의 타입을 지정하는 것이고, alg는 해싱 알고리즘이 저장되어있다. 주로 HMAC SHA 256 또는RAS를 사용하며 이 alg는 서명(signature)에 사용된다.
- 페이로드(payload)
- 페이로드는 토큰에서 사용되는 정보가 담겨 있다. 여기서 사용되는 정보가 위에서 설명한 클레임이라는 것인데 Key/Value 방식으로 구성되어 있고, 다수의 정보를 저장할 수 있다.
- 클레임은 총 세가지로 구분된다.
- 등록된 클레임
- 토큰정보를 표현하기 위해 이미 정해진 데이터 종류이며, 선택적으로 작성할 수 있습니다.
- 공개 클레임
- 공개 클레임은 서로 충돌이 일어나지 않는 이름을 가지고 있는 클레임이다.
- URL 형태로 작성되며, 중복을 허용하지 않는다.
- 비공개 클레임
- 비공개 클레임은 사전에 작업자, 즉 개발자가 지정하는 것인데 서버와 클라이언트가 서로 협의하에 사용되는 클레임이다.
- 서명(signature)
- 서명은 위에서 설명한 헤더와 페이로드의 각 값들을 base64로 인코딩하고, 그 값을 비밀키를 이용해 헤더에서 정의한 알고리즘으로 다시 해싱한 후 이 값을 다시 base64로 인코딩하여 생성한 값이다.
- 서명은 JWT 비밀키로 만든다. 이 비밀키가 노출되면 JWT 토큰을 위조할 수 있으므로 철저히 숨겨야한다. 서명(signature) 자체는 숨기지 않아도 된다.
- JWT 토큰이 변조가 되더라도 서명(signature)을 검사할 때 변조 여부를 검사할 수 있다. 따라서 사용자 이름이나 외부에 노출되어도 괜찮은 정보들을 넣고 사용하면 된다.
특징
JWT의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없다분산 마이크로 서비스 환경에서 중앙 집중식 인증 서버와 데이터베이스에 의존하지 않는 쉬운 인증 및 인가 방법을 제공하며 개별 마이크로 서비스에는 토큰 검증과 검증에 필요한 비밀 키를 처리하기 위한 미들웨어가 필요하다. 검증은 서명 및 클레임과 같은 몇 가지 매개 변수를 검사하는 것과 토큰이 만료되는 경우로 구성되며, 토큰이 올바르게 서명되었는지 확인하는 것은 CPU 사이클을 필요로 하며 IO 또는 네트워크 액세스가 필요하지 않으며 최신 웹 서버 하드웨어에서 확장하기에 용이하다.
장점
- URL 파라미터와 헤더로 사용
- 수평 스케일이 용이
- 디버깅 및 관리가 용이
- 트래픽 대한 부담이 낮음
- REST 서비스로 제공 가능
- 내장된 만료
- 독립적인 JWT
단점
- 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없다.
- 더 많은 필드가 추가되면 토큰이 커질 수 있다.
- 비 상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미친다.
이론적으로는 정리한 내용은 이렇다. 개인적인 생각이지만 JWT가 어떠한 장점이 있고,
어떠한 단점이 있고 그것을 이론으로만 파악하는 것에는 분명 한계가 있다.
나는 Java/Spring 기반 프로젝트에 로그인 및 인증을 JWT를 이용해서 작성했을텐데
기존 사용자 검증 방식과 이번에 공부한 JWT를 이용한 사용자 검증 방식을 그림으로 정리했다.
기존 구조
JWT 인증 구조
위와 같은 그림을 생각했으며, 실제로 적용해보면서 어떤식으로 바뀔지에 대한 부분도 기대가 된다!!
