JWT(JSON Web Token)
소개
1. JSON Web Token의 약자로 전자 서명 된 URL-safe(URL로 이용할 수 있는 문자만 구성된)의 JSON이다.
2. JWT는 속성 정보 (Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준이다.
3. JWT는 서버와 클라이언트 간 정보를 주고받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정 없이 헤더에 포함되어 있는 JWT 정보를 통해 인증한다.
4. 이때 사용되는 JSON 데이터는 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 만든다.
5. JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있다.
클레임토큰
- 클레임 토큰에서 클레임이란 단어는 사용자의 정보나 데이터 속성등을 말한다. 따라서 사용자 정보 또는 데이터 속성을 담은 토큰이라고 볼 수 있다.
- 구분자는 .으로 나뉘어서 표현되며, 각 값은 base64로 인코딩 되어있다.
- 클레임 토큰은 크게 3가지의 구성요소가 존재한다.
- 헤더(header)
- typ과 alg 두가지 정보로 구성되어 있다.
- typ은 토큰의 타입을 지정하는 것이고, alg는 해싱 알고리즘이 저장되어있다. 주로 HMAC SHA 256 또는 RSA를 사용하며 이 alg는 서명(signature)에 사용된다.
- 페이로드(payload)
- 클레임 토큰은 사용자의 정보를 담은 토큰이라고 했는데 그 사용자의 정보가 여기에 담겨있다. Key/Value 방식으로 구성되어있고, 다수의 정보를 저장할 수 있다.
- 서명(signature)
- 서명은 헤더와 페이로드의 값들을 base64로 인코딩하고, 그 값을 비밀키(secret-key)를 이용해 헤더(header)에서 정의했던 알고리즘으로 다시 해싱한다. 그 후 해싱값을 다시 base64로 인코딩하여 생성한 값이다.
- 비밀키로 생성하며, 비밀키는 노출되면 토큰 위조 위험성이 존재하므로 절대로 노출하면 안된다. 서명값 자체는 숨기지 않아도 된다.
- JWT 토큰이 변조되더라도 서명을 검사해서 변조 여부를 검사할 수 있다.
- 헤더(header)
특징
JWT의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없다.
분산 마이크로 서비스 환경에서 중앙 집중식 인증 서버와 데이터베이스에 의존하지 않는 쉬운 인증 및 인가 방법을 제공하며 개별 마이크로 서비스에는 토큰 검증과 검증에 필요한 비밀 키를 처리하기 위한 미들웨어가 필요하다. 검증은 서명 및 클레임과 같은 몇 가지 매개 변수를 검사하는 것과 토큰이 만료되는 경우로 구성되며, 토큰이 올바르게 서명되었는지 확인하는 것은 CPU 사이클을 필요로 하며 IO 또는 네트워크 액세스가 필요하지 않으며 최신 웹 서버 하드웨어에서 확장하기에 용이하다. JSON 웹 토큰의 사용을 권장하는 몇 가지 이유는 다음과 같다.
장점
- URL 파라미터와 헤더로 사용
- 수평 스케일이 용이
- 디버깅 및 관리가 용이
- 트래픽 대한 부담이 낮음
- REST 서비스로 제공 가능
- 내장된 만료
- 독립적인 JWT
단점
- 토큰은 클라이언트에 저장되어 데이터베이스에서 사용자 정보를 조작하더라도 토큰에 직접 적용할 수 없다.
- 더 많은 필드가 추가되면 토큰이 커질 수 있다.
- 비 상태 애플리케이션에서 토큰은 거의 모든 요청에 대해 전송되므로 데이터 트래픽 크기에 영향을 미친다.
뭐 대충 요런 느낌이지 않을까 싶은데 내가 JWT를 이용해 로그인과 사용자 인증 프로세스를 구현했을 때 원했던 건 한가지다.
"사용자에 대한 정보를 매번 데이터베이스를 통해 얻는것이 아니라 JWT에 저장된 사용자 정보를 사용하는 것" 이다.
처음부터 많은 것을 고려한 것이 아니기 때문에 이정도면 충분하다고 생각되고, 다른 부분들은 앞으로 더 공부해서 알아가보자