[TIL]JWT

영태·2022년 4월 6일

JWT TIL

[TIL]

목록 보기

17/21

JWT

존맛탱의 약..
아니..
JSON Web Token의 약자다.
전자 서명 된 URL-safe의 JSON을 말한다

JWT의 등장배경

이전 포스팅에서 언급한 쿠키와 세션...

이 두가지는 다음과 같은 단점을 가지고 있다.

쿠키와 세션의 단점

session storage의 문제가 발생하면 인증 체계가 무너져 이전에 인증된 유저 또한 인증이 불가능해진다.

stateful 하기 때문에 http의 장점을 발휘하지 못하고 scale out에 걸림돌이 생긴다.

session storage가 필수적으로 존재해야 하기 때문에 이를 사용하기 위한 비용이 든다.

세션 ID가 탈취되었을 때, 대처는 가능하지만...탈취자가 작정하고 클라이언트인척 위장했을 때는 보안의 약점이 생길 수 있다.
-사용자가 많아질수록 메모리를 많이 차지한다

매번 요청시 세션저장소를 조회해야한다는 단점이 있다.

이 중 가장 큰 단점은 요청을 진행할때마다 세션 저장소에 세션 ID를 조회하는 작업을 통해서
DB접근 로직이 한번 더 수행되어야 한다는 것

이를 위해 등장한 것이 JWT다

말 그대로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰이다

기본적인 인증 구조는 쿠키와 크게 다르지는 않지만, 강조되는 점은 서명된 토큰이라는 점이다.
공개 키와 개인 키를 쌍으로 사용하여 토큰에 서명할 경우,

개인 키를 보유한 서버가 서명된 토큰을 정상적인 토큰인지 확인할 수 있다는 것이다.

이러한 구조 때문에 인증 정보를 담아 안전하게 인증을 시도하게끔 전달할 수 있는 것이다.

JWT 구조

각 요소는 .으로 구분되어있으며 구성요소는
Header.Payload.Signature

Header
Payload
Signature
이렇게 세가지다.

Header
토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있다.

Header 예시

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

type : 토큰의 타입을 지정한다.
alg : Signature Hashing 알고리즘을 지정한다. 해싱 알고리즘으로는 보통 HMAC-SHA256 혹은 RSA가 사용된다.

Payload(정보)
토큰에 담을 클레임 정보를 포함하고 있다. Payload에 담는 정보의 한조각을 클레임이라 하고 이는 JSON(name/value) 형태의 한 쌍으로 이뤄져있으며 토큰에는 여려개의 클레임을 넣을 수 있다.

Payload 예시

{
    "iss": "dnjscksdn98.com",
    "exp": "1485270000000",
    "https://dnjscksdn98.com/jwt_claims/is_admin": true,
    "userId": "dnjscksdn98",
    "username": "alex"
}

Signature(서명)
서명은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드다.
서명은
1) 위에서 만든 헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64로 인코딩하고,
2) 인코딩한 값을 비밀 키를 이용해 헤더에서 정의한 알고리즘으로 해싱
3) 이값을 다시 BASE64로 인코딩하여 생성합니다.

JWT 토큰 예시

JWT 속성

전자 서명은 JSON의 변조를 체크할 수 있게 되어있다.
JWT는 속성 정보(Claim)를 JSON 데이터 구조로 표현한 토큰으로 RFC7519 표준으로 지정되어있다.

JWT는 서버와 클라이언트 간 정보를 주고 받을 때 Http 리퀘스트 헤더에 JSON 토큰을 넣은 후 서버는 별도의 인증 과정없이 헤더에 포함되어 있는 JWT 정보를 통해 인증을 진행한다.

이때 사용되는 JSON 데이터를 URL-Safe 하도록 URL에 포함할 수 있는 문자만으로 구성한다.

JWT는 HMAC 알고리즘을 사용하여 비밀키 또는 RSA를 이용한 Public Key/ Private Key 쌍으로 서명할 수 있습니다.

JWT의 장점

사용자 인증에 필요한 모든 정보는 토큰 자체에 포함되기 때문에 별도의 저장소가 필요없다.
쿠키를 사용하지 않아도 됨으로써 쿠키사용의 취약점이 사라진다.
URL 파라미터와 헤더로 사용
트래픽 부담이 낮음
REST 서비스로 제공 가능
내장된 만료
독립적

JWT의 단점

self-contained : 토큰 자체에 정보가 있음으로 양날의 검이다.
토큰 길이 : 토큰의 페이로드는 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 강한 부하를 가할 수 있다.
payload 인코딩 : 페이로드 자체는 암호된 것이 아니라 BASE64로 인코딩 된 것이기 때문에, 중간에 페이로드를 탈취당해 디코딩 당한다면 데이터를 볼 수 있으므로, 암호화 과정을 거쳐야 한다.
Stateless : JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능하다. 즉 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어줘야한다.