JWT 토큰

- 웹에서 사용되는 json 형식의 토큰에 대한 표준 규격

- 사용자의 인증과 인가 정보를 서버와 클라이언트간에 안전하게 주고 받기 위해서 사용

 

- 보통 Authorization HTTP헤더를 Bearer <토큰>의 형태로 설정하여 클라이언트에서 서버로 전송

- 서버에서는 토큰에 포함되어 있는 서명 정보를통해 위변조 여부를 검증

 

- Base64로 인코딩 = 육안으로 보면 eyJ로 시작하는 아주 긴 문자열

- 온라인 디버거를 통해 어렵지 않게 실제로 저장되어 있는 내용을 json 형태로 디코딩하여 확인해볼 수 있다

 

JWT 구조

하나의 JWT 토큰은 헤더, 페이로드, 서명

 

헤더 : 토큰의 유형, 서명 알고리즘에 명시

페이로드 : 소위 claim이라고 불리는 사용자의 인증/인가 정보

서명 : 헤더와 페이로드가 비밀키로 서명되어 저장

 

jwt 토큰은 네트워크로 전송되어야 하기 때문에 공간을 적게 차지하는 것이 유리

 

ex)

헤더

{
    "alg" : "HS256",
    "typ" : "JWT"
}

 

페이로드

{
	"sub" : "1234234"
	"lat" : 123123
}

 

 

jwt에서 자주 사용되는 json키

sub	인증 주체(subject)
iss	토큰 발급처
typ	토큰의 유형(type)
alg	서명 알고리즘(algorithm)
iat	발급 시각(issued at)
exp	말로 시작(expiration time)
aud	클라이언트(audience)

 

 

jwt를 통한 인증/인가

- 보통 OAuth, OIDC 프로토콜과 함께 api의 인증이나 인가를 위해 주로 사용이 된다

 

장점

- 확장성 : 토큰 자체에 사용자의 정보가 저장되어 있기 때문에 서버 입장에서 토큰을 검증만 해주면 됩니다

{ 쿠키와 세션을 사용할때는 서버 단에 로그인한 모든 사용자의 세션을 db나 캐시에 저장해놓고 쿠키로 넘어온 세션id 로 사용자 데이터를 매번 조회해야함

그리고 쿠키 사용안하므로 cors 문제에서 자유로워진다는 것도 장점

 

한계

- 어느정도 규모가 있는 서비스에서 사용자 인증 용도로 jwt를 사용하기에는 부족한 경우가 있다

ex) 현재 로그인된 사용자의 모든 장비들을 나열해주거나 특정 장비에서 로그아웃을 허용하는 기능을 구현하려면 서버 단에 사용자 세션을 저장하지 않고는 어렵기 때문

 

주의 사항

- 서명이 되어 있는 jwt 토큰 서버에서만 유효성을 검증할 수 있지만 그 안에 저장된 데이터는 누구나 쉽게 열람 가능 -> 민감 정보를 jwt 토큰에 그대로 저장하게 되면 큰 보안 문제로 이어질 수 있어 각별한 주의가 필요

- 가급적 사용자를 식별할수있는 아이디정도만 저장하는것이 좋음

- 추가 정보가 필요한 경우 서버에서 사용자 db를 조회하는 것이 안전

- 불가피한 이유로 jwt 토큰에 민감한 정보를 저장해야한다면 반드시 암호화를 하여 jwt 토큰을 디코딩한 후에도 알아볼  수 없게 해야함