JWT란 무엇인가?!

조성권·2022년 8월 15일

JWT

오늘은 JWT에 대해 알아보도록 하겠다.

JWT 개요

JWT의 이론적인 정의는 다음과 같다.

JWT: Json Web Token의 약자로 Json 포맷을 이용하여 Self-Contained 방식으로 사용자에 대한 정보를 저장하는 Claim 기반 Web Token

어려운 문구가 몇가지 보이는데 사용하는 입장에서 간단히 JWT를 정의하면 "회원인증과 같은 정보를 비밀리에 전달하거나 인증할 때 사용하는 토큰"이라고 할 수 있다.

JWT 구조

그렇다면 회원인증에 주로 사용되는 JWT는 어떤 형태로 이루어져 있는지 알아보자.

JWT는 점(.)을 기준으로 총 3개 파트로 나뉘어진다.

Header: JWT에서 사용할 타입과 해시 알고리즘 종류가 담겨있다.
Payload: 서버에서 첨부한 사용자 권한 정보와 실데이터가 담겨있다.
Signature: Base65 URL-safe Encode를 한 이후, Header에 명시된 해시함수를 적용하고 개인키(Private Key)로 서명한 전자서명이 담겨잇다.

위 이미지를 통해 실제 토큰값에 대해 디코딩했을 때, 어떤 구조를 가지고 있는지 한눈에 볼 수 있다.

그럼, 위 내용을 토대로 JWT 구조에 대해 더 상세하게 들어가보도록 하겠다.

Key 종류

alg
: 알고리즘 방식에 대해 정의한다. ex) HS256(SHA256) or RSA
: Header 정보를 암호화하는데 사용하는 것이 아니라 서명(Signature)을 해싱하기 위한 알고리즘을 정의한다.

typ
: 토큰 타입을 지정 ex) JWT

Payload

payload에는 토큰에서 사용할 정보 조각(=Claim)이 담겨있다.
Claim은 총 3가지로 나뉘며 JSON 형태로 다수의 정보를 포함할 수 있다.

1. Registered Claim(등록된 클레임)
: 토큰 정보를 표현하기 위해 이미 정해진 종류의 데이터들
: 모두 선택적으로 작성가능하며 사용할 것을 권장

iss: 토큰 발급자(issuer)

sub: 토큰 제목(subject)

aud: 토큰 대상자(audience)

exp: 토큰 만료 시간(expiration), NumericDate 형식

nbf: 토큰 활성 날짜(not before), 해당 날짜 이전 토큰 비활성화

iat: 토큰 발급 시간(issued at), 토큰 발급 이후, 경과 시간 확인

jti: JWT 토큰 식별자(JWT ID), 중복방지 위함

2. Public Claim(공개 클레임)
: 사용자 정의 클레임으로, 공개용 정보를 위해 기술
: 충돌방지를 위해 URI 포맷 사용
{
	"https://velog.io/@cho876" : true
}

3. Private Claim(비공개 클레임)
: 사용자 정의 클레임으로, 서버와 클라이언트 사이 임의 지정 정보 저장
{
	"token_type" : access
}

Signature

서명(Signature)은 토큰을 인코딩하거나 유효성 검증을 할 경우, 사용하는 고유한 암호화 코드이다.

Signature 만드는 과정
1. Header와 Payload의 값을 각각 BASE65Url로 인코딩한다.
2. 1에서 인코딩한 값을 비밀키를 통해 Header에서 정의한 알고리즘으로 해싱한다.
3. 이 값을 다시 BASE64Url로 인코딩하여 생성

JWT 장점

1. Cost 절약

과거 많은 인증서버는 Session 방식을 통해 처리했다.

Session 인증 방식
1. Client의 로그인 요청
2. Server는 해당 Client를 위한 Session 생성
3. Client 접속
4-1. 일정 시간 내, Client 재접속할 경우 유지되고 있는 Session을 통해 처리
4-2. 일정 시간 지난 경우, 새로운 Session 다시 생성

문제가 무엇인지 보이는가??
Session을 유지하기 위해선 해당 Session을 Server쪽에서 기억하고 있어야 하기 때문에 이를 위한 Cost가 든다는 것이다.
Session을 생성하는 것 역시, 추가적인 데이터 인입이기 때문에 이에 따른 Cost가 드는게 당연한다.

JWT 방식은 이러한 Cost를 줄이는데 한몫 한다.
JWT는 Client가 해당 토큰 정보를 보관하고 인증이 필요한 경우, 직접 Server에 보내 확인하는 구조이다.
Server는 해당 JWT에 대한 검증만 하면 되기 때문에 기존처럼 각 Client별로 무언가를 별도로 저장하거나 해야할 필요가 없는 것이다.

이러한 면에서 훨씬 편리하다고 볼 수 있다.

2. Self-Contained 구조

JWT는 토큰 자체적으로 모든 정보를 담고있는 구조이다.
그렇기 때문에 별도로 Auth Server로 보내 실데이터를 불러오거나 하는 불필요한 호출 없이 Client에 대한 정보를 스스로 알아낼 수 있다.

JWT 단점

1. Self-Contained 구조

위에서 방금 장점으로 내세웠던 Self-Contained 구조가 경우에 따라 단점이기도 하다.
토큰 자체적으로 실정보를 포함하고 있기 때문에 해당 내용이 노출될 경우, 보안적으로 이슈가 발생할 수 있다.

2. 네트워크 대역폭 낭비

앞서 JWT 구조에 대해 알아보면서 payload에 실데이터(=claim)가 들어간다는 것을 알아보았다. 이때, claim이 많아질 경우, 그만큼 토큰값의 길이 역시 함께 늘어나게 된다.
토큰의 길이가 늘어날수록, 그러한 토큰이 많을수록 서버에 전달하는데 있어 대역폭 낭비가 심해질 수 있다.

고찰

오늘은 JWT에 대해 알아보았다.
JWT는 로그인 구현에 있어 중요한 부분에 해당하며 아직도 많은 곳에서 JWT를 통한 인증을 채택하고 있다.
이번 기회를 통해 JWT의 구조, 장/단점에 대해 알아보면서 어떻게 하면 기술적으로 보안을 강화하면서도 사용자 입장에서 UX적으로 편하게 사용할 수 있을까에 대해 고민해보는 시간을 가져볼 수 있었던 것 같다.