JWT
JWT(Json Web Token)란 말 그대로 웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격이다.
주로 사용자의 인증(Authentication) 또는 인가(Authorization) 정보를 서버와 클라이언트 간에 안전하게 주고 받기 위해 사용한다.
JWT는 웹에서 보통 Authorization HTTP 헤더를 Bearer <토큰>의 형태로 설정하여 클라이언트에서 서버로 전송되며, 서버에서는 토큰에 포함되어 있는 서명(Signature) 정보를 통해 위변조 여부를 빠르게 검증할 수 있다.
JWT는 Base64로 인코딩 되어 있어 육안으로 보면 eyJ로 시작하는 아주 긴 문자열이며, 온라인 디버거를 활용하면 어렵지 않게 실제 저장되어 있는 내용을 JSON의 형태로 디코딩하여 확인해볼 수 있다.
JWT 구조
하나의 JWT는 헤더(Header)와 페이로드(Payload), 서명(Signature) 이렇게 세 부분으로 이루어져 있으며, 각 구역은 . 기호로 구분되어 진다.
<Header>.<Payload>.<Signature>첫 번째 부분인 헤더(Header)에는 토큰의 유형과 서명 알고리즘이 명시되고, 페이로드(Payload)에는 소위 Claim(조각)이라고도 불리는 사용자의 인증/인가 정보가 담긴다. 마지막 부분인 서명(Signature)에는 헤더와 페이로드가 비밀키로 서명되어 저장된다.
JWT는 네트워크로 전송되어야 하기 때문에 공간을 적게 차지하는 것이 유리한데, 때문에 독특하게도 JSON 형식으로 데이터를 저장할 때 키(Key)를 3글자로 줄이는 관행이 있다.
아래는 전형적인 JWT 디코딩 결과이다.
// 헤더
{
"alg": "HS256",
"typ": "JWT"
}// 페이로드
{
"sub": "1234567890",
"lat": 1516239022
}이 외에도 JWT에서 자주 사용되는 JSON 키 이름은 다음과 같다.
- sub: 인증 주체(subject)
- iss: 토큰 발급처
- typ: 토큰 유형(type)
- alg: 서명 알고리즘(algorithm)
- iat: 발급 시간(issued at)
- exp: 만료 시간(expiration time)
- aud: 클라이언트(audience)
JWT의 장점
JWT가 등장하기 전에는 웹에서 쿠키(cookie)와 세션(session)을 이용한 사용자 인증을 구현하는 경우가 많았다. JWT가 기존 방법 대비 어떤 강점이 있는지 살펴보자.
아마도 가장 큰 이유는 확장성에 있을 것이다.
쿠키와 세션을 사용할 경우 서버 단에 로그인한 모든 사용자의 세션을 DB나 캐시(Cache)에 저장해놓고 쿠키로 넘어온 세션 ID로 사용자 데이터를 매번 조회해주어야 한다.
반면 JWT는 토큰 자체에 사용자의 정보가 저장되어 있기 때문에 서버 입장에서는 토큰만 검증해주면 되며, 토큰 자체도 클라이언트 단에 저장되기 때문에 서버에서는 신경쓸 부분이 줄어들게 된다.
따라서 JWT를 사용하면 사용자가 늘어나더라도 사용자 인증을 위해 추가로 투자해야하는 인프라 비용을 크게 절감할 수 있는 것이다.
뿐만 아니라 쿠키를 사용하지 않으므로 CORS(Cross Origin Resource Sharing)와 같은 문제에서 자유로워진다는 것도 장점으로 여겨질 수 있겠다.
CORS는 출처가 다른 자원들을 공유한다는 뜻으로, 한 출처에 있는 자원에서 다른 출처에 있는 자원에 접근하도록 하는 개념이다.
JWT의 한계
위와 같은 JWT의 장점에도 불구하고 어느 정도 규모가 있는 서비스에서 사용자 인증 용도로 JWT를 사용하기에는 부족한 경우가 있다.
예를 들어, 현재 로그인된 사용자의 모든 장비들을 나열해주거나, 특정 장비에서 로그아웃을 허용하는 등의 기능은 서버 단에 사용자 세션을 저장하지 않고는 구현하기 힘들기 때문이다.
JWT 사용 시 주의 사항
서명이 되어 있는 JWT는 서버에서만 유효성을 검증할 수 있지만 그 안에 저장된 데이터는 누구나 쉽게 열람이 가능하다. 따라서 민감한 사용자 정보를 JWT에 그대로 저장하게 되면 큰 보안 문제로 이어질 수 있어 각별한 주의가 필요하다.
가급적 JWT에는 사용자를 식별할 수 있는 아이디 정도만 저장하는 것이 좋으며, 해당 사용자에 대한 추가 정보가 필요한 경우에는 서버에서 사용자 DB를 조회하는 것이 안전할 것이다.
불가피한 이유로 JWT에 민감한 사용자 정보를 저장해야 한다면 반드시 암호화를 하여 JWT를 디코딩한 후에도 알아볼 수 없게 해야할 것이다.
📌 References
