JWT

JWT는 JSON Web Token의 약자로, JSON 포맷으로 정보를 안전하게 전달할 수 있도록 하는 웹 표준이다. (RFC 7519) 필요한 모든 정보를 토큰 자체에 지니고 있기에, 자가 수용적(self-contained)이고 스스로 무결함을 입증할 수 있다.

회원 인증에 많이 사용되는데, 사용자가 서버에 로그인 요청을 하면 서버는 사용자 정보에 기반한 토큰을 생성하여 사용자에게 전달한다. 이후에 사용자는 서버에 요청을 할 때마다 토큰을 실어보내고, 서버는 토큰이 유효한지 검증하여 작업을 처리할 수 있다. JWT만을 사용해 인증을 구현한다면 서버는 세션을 관리할 필요가 없어 비용을 아낄 수 있다. 아래와 같이 HTTP 헤더로 전달할 수 있다.

{
  "Authorization": "Bearer {생성된 토큰 값}"
}

JWT의 구조

JWT는 Header, Payload, Signature 세 부분으로 이루어진다. 각자 JSON 포맷이었다가 Base64로 인코딩되어 토큰에 탑재되고, 사이에 . 문자를 통해 구분된다. 위 그림을 참고! 순서대로 빨간 부분은 Header, 보라색은 Payload, 푸른색은 Signature.

1) Header

typ : 토큰의 타입을 지정한다. 값은 "JWT".

alg : Signature 부분을 어떤 알고리즘으로 암호화할 것인지 지정한다. 보통 HMAC SHA256이나 RSA를 사용.

2) Payload

토큰에 담을 정보들이 들어가는 부분. 정보의 한 조각을 클레임(claim)이라고 부르며, (name, value) 쌍의 형태를 갖는다. 클레임의 종류는 등록된 클레임, 공개 클레임, 비공개 클레임 세 가지로 나뉜다.

등록된 클레임이란 토큰에 대한 정보를 담기 위해 이름이 이미 정해져 있는 정보들을 말한다. 필수로 작성해야하는 정보는 아니지만 사용할 것이 권장된다. 다음 일곱 가지의 이름을 갖는다.

• iss : 토큰 발급자 (issuer)
• sub : 토큰 제목 (subject), 유니크한 값을 사용하며 사용자 이메일을 많이 사용한다고 한다.
• aud : 토큰 대상자 (audience)
• exp : 토큰 만료 시간 (expiration), NumericDate 형식 (ex. 1480849147370)
• nbf : 토큰 활성 날짜 (not before), NumericDate 형식
• iat : 토큰 발급 시간 (issued at), 토큰의 age를 판단할 수 있음.
• jti : JWT 토큰 식별자 (JWT ID), 중복 방지를 위해 사용하며 일회용 토큰에 사용하면 유용.

공개 클레임은 사용자 정의 클레임으로, 말 그대로 공개용 정보를 위해 사용된다. 충돌을 방지하기 위해 아래와 같이 URI 형식의 이름을 짓는다.

{
    "https://sajagachi.ga/jwt_claims/is_admin": true
}

비공개 클레임은 사용자 정의 클레임이지만, 클라이언트와 서버간 임의로 지정한 정보들을 저장한다. 이름이 중복되어 충돌하지 않도록 유의해야 한다.

{
    "username": "web19"
}

등록된 클레임, 공개 클레임, 비공개 클레임을 하나의 JSON 포맷에 담아 Base64 인코딩하여 토큰에 탑재한다.

Header도 마찬가지지만, Payload는 Base64로 인코딩이 되는 것 뿐이지 암호화되지 않는다. 다음은 sajagach.ga에서 발급하는 user 토큰을 jwt.io 에서 디코딩한 것이다.

3) Signature

토큰의 유효성을 검증하기 위해 탑재되는 해시값. 생성 과정은 다음과 같다.

1. Header와 Payload를 각각 Base64 인코딩
2. 두 문자열을 . 문자를 사이에 두고 합친다.
3. 비밀키와 Header에서 지정한 알고리즘을 통해 암호화한다.
4. 암호화된 값을 Base64로 인코딩

즉 Signature는 Header와 Payload를 암호화한 값이므로, 비밀키가 노출되지 않는 한 토큰의 내용을 임의로 조작할 수 없다.

JWT의 장점과 단점

👍 JWT의 장점은...

• 인증에 필요한 정보를 토큰 자체에 모두 저장하기에, 서버 입장에서는 정보를 별도로 저장하고 관리할 필요가 없어 서버 자원을 줄일 수 있다.
• 다중 서버의 경우 세션 방식에서는 서로 다른 서버에 접속해도 로그인이 가능하도록 하기 위해 공통된 세션 저장소를 운영하지만, 토큰 방식은 어느 서버에 접속하든 스스로 검증이 가능하므로 편리하다.

👎 JWT의 단점은...

• 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.
• Payload가 기본적으로 암호화되어 있지 않으므로, 토큰이 탈취되면 정보가 노출될 수 있다. JWE(JSON Web Encryption)로 암호화하거나 Payload에 중요한 데이터를 넣지 말아야 한다.
• 한 번 발급되면 유효기간이 완료될때까지는 계속 사용할 수 있다. 유효기간이 끝나기 전에 서버에서 토큰을 임의로 만료시키고 싶다면 서버에서 블랙리스트를 관리해야 하는데, 매 요청마다 블랙리스트를 조회하게 되므로 서버의 부하가 커지고 JWT의 장점이 일부 희석되어 버리는 문제가 있다.

Refresh Token을 사용하는 방법

기존의 Access Token만을 사용하는 방법은 토큰이 탈취당했을 경우, 토큰의 유효기간이 만료되기 전까지 정보가 탈취되는 것을 막을 수 없다는 문제가 있다. 이를 위해 단순히 토큰의 유효기간을 줄여버리면 사용자가 Access Token을 얻기 위해 더 자주 로그인을 해야 하므로, 사용자가 불편해진다.

이 문제를 해결하기 위해, 유효 기간이 짧은 Access Token과 유효 기간이 더 긴 Refresh Token 두 가지를 모두 사용한다. 최초 토큰 발급시 서버에서 Access Token과 함께 Refresh Token을 발급해 클라이언트에 전달하고, Access Token이 만료되면 클라이언트에서 Refresh Token을 제출해 Access Token을 재발급 받는다. 자세한 내용은 해당 링크에서 매우 잘 설명하고 있는 것 같고, 내 글에서는 Refresh Token 방식에 대한 개인적인 궁금증과 의구심에 더 초점을 맞추고 싶다.

1) Access Token과 Refresh Token의 적절한 유효 기간은?

Access Token과 Refresh Token 유효 기간의 적정선은 어디일까?

Access Token의 유효 기간을 너무 짧게 잡으면 재발급이 자주 발생하여 서버의 부담이 증가할 것이다. 서버는 Access Token의 재발급을 위해 DB에 저장해둔 Refresh Token을 확인하거나, Token의 암호화 과정을 거쳐야 하기 때문이다.

Access Token의 유효 기간을 너무 길게 잡으면 토큰이 탈취당하는 경우 사용자의 정보가 더 오랫동안 위험에 노출된다. Refresh Token을 사용하는 의미가 흐려지기도 하고..

Refresh Token도 적절한 유효 기간이 필요할 것이다. Refresh Token 자체가 탈취당하는 경우도 고려해야할 것이기 때문이다.

일단 몇 가지 서비스의 토큰 유효 기간을 조사해보았다. 아무래도 자체 로그인보다는 OAuth 인증의 토큰 유효 기간 정도만 안내가 되어있는 것 같다.

서비스	Access Token	Refresh Token
카카오 OAuth	JavaScript 2시간, REST API 6시간	2달 (유효기간 1달 남은 시점부터 갱신 가능)
네이버 OAuth	1시간	확인 불가
Facebook OAuth	약(?) 1~2시간	약 60일
Google OAuth	1시간 추정	최대 6달

2) 여전히 정보의 탈취를 막을 수 없는 것 아닐까?

나는 Refresh Token 방식을 Access Token의 유효 기간을 줄이기 위한 것으로 이해하고 있다. 즉, Refresh Token 방식의 핵심은 해커가 Access Token으로 사용자의 정보를 빼내는데 사용할 수 있는 시간을 줄이는 것이다.

그런데 유효 기간을 줄인다고 해서 정보의 유출을 막을 수 있는 것인지 의문이 들었다. 가령 Access Token의 유효 기간이 5분이라고 해도, 5분 안에 정보가 유출될 수 있는 것 아닐까? Access Token의 유효 기간을 5분보다 더 줄여간다고 해도, 해커의 여유 시간은 줄어들겠지만 그 Trade-off로 서버의 부담은 증가하고 Access Token의 의미는 흐려져간다.

3) 클라이언트에서 Refresh Token을 안전하게 보관하는 방법

해커가 Refresh Token을 탈취하면 서버에 Access Token의 재발급을 요청할 수 있기 때문에, Refresh Token 방식 자체가 무용지물이 될 것이다. 클라이언트에서 Refresh Token을 안전하게 보관할 수 있는 방법에는 어떤 것들이 있을까? 추가로, Refresh Token이 탈취당한 경우의 안전 대책이 있을까?

Refresh Token을 저장하는 위치에 대해 조사해보았다. 첫 번째는 브라우저의 Local Storage에 저장하는 것인데, 자바스크립트로 Local Storage에 쉽게 접근할 수 있기 때문에 XSS 공격에 취약하다. 두 번째는 브라우저의 쿠키에 저장하는 것인데, HttpOnly 옵션을 적용하면 XSS 공격을 방지할 수 있고 CSRF 공격 방지(Referrer 검증, CSRF 토큰, Double Submit Cookie)까지 해주면 나름 괜찮은 방식으로 보였다.

하지만 결국 클라이언트에 저장하는 것은 한계가 있는 것인지 세션, DB와 같이 서버에 저장하는 방법도 사용하는 것 같다. 그런데 이 방법은 또다시 아래와 같은 궁금증들을 만들었다.

1. 브라우저의 쿠키에 저장된 세션 아이디가 탈취되면 위험하지 않을까?
2. 결국 서버에 저장해야 한다면 그냥 토큰을 사용하지 않고 세션 로그인을 구현하는게 낫지 않나?

참고자료

• https://velopert.com/2389
• https://mangkyu.tistory.com/56
• https://lewisxyz000.tistory.com/25
• https://velog.io/@kshired/Express에서-JWT로-인증시스템-구현하기-Access-Token과-Refresh-Token