JWT 란?
JSON Web Token의 약자로 json객체를 이용해서 토큰 자체의 정보를 저장하고 있는 웹 토큰
암호화된 토큰으로 복잡하고 읽을 수 없는 String 형태로 저장
JWT 사용 이유
Http는 state-less를 지향
(state-less(무상태)란 서버-클라이언트 구조에서 서버가 클라이언트의 상태를 가지고 있지 않은 것)
Http의 단점
- state-ful(세션) 방식보다 비교적 많은 양의 데이터가 반복적으로 전송되므로 네트워크 성능저하가 될 수 있음
- 데이터 노출로 인한 보안적인 문제 존재
위와 같은 단점을 보완하기 위해 JWT를 사용 (JWT로 데이터 압축 및 서명)
(+) Token의 단점
- 토큰 자체의 데이터가 김
- 이로 인한 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있음
- Payload 자체는 암호화되지 않기 때문에 중요 정보 저장 불가
- 네트워크 전송방식이기 때문에 토큰을 탈취 당할 우려있음
구성 요소
헤더(header).내용(payload).서명(signature) 로 이루어져 있고,
헤더는 해싱을 위한 알고리즘 정보가,
페이로드는 토큰에 담을 클레임 정보가,
시그니처는 헤더와 페이로드가 합쳐진 정보가 있다.
Header
헤더는 일반적으로 2가지 정보를 담고 있다.
alg: signature을 만드는데 사용한 알고리즘 정보typ: Token의 타입
{
"alg" : "HS256", //사용 알고리즘 :HS256
"typ" : "JWT" // 토큰의 타입 : JWT
}Payload
Playload은 실질적으로 전달해야 하는 정보를 가지고 있다.
Playload에 담긴 정보 하나를 Claim이라고 하며, 민감한 정보를 넣으면 안된다. (암호화X)
Claim의 종류는 Registered Claims, Public Claims, Private Claims로 3가지이다.
- Registered Claims : JWT 표준으로 지정된 Claim, 총 7가지가 존재
iss: 토큰 발급자sub: 토큰 제목aud: 토큰 대상자exp: 토큰 만료시간iat: 토큰 발급 시간nbf: 토큰 활성화 시간jti: JWT의 고유 식별자
- Public Claims : JWT를 사용하는 사람들이 정의 (공개적으로)
기존 Claims와의 충돌을 방지하려면 IANA JSON Web Token 레지스트를 참고
혹은 UUID, OID, 도메인 이름 등을 사용 - Private Claims : Public Claims과 달리 오직 사용자와 서버 사이에서만 합의하여 사용
{
"exp": "1245678900", //Registered Claims
"https://velopert.com/jwt_claims/is_admin": true, //Public Claims
"user_id" : 12345123 //Private Claims
}Signature
JWT의 서명 부분
(Header의 인코딩된 내용 +”.”+ Payload의 인코딩된 내용)을 Secret Key(서버의 개인키)와 알고리즘을 이용하여 암호된 값
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
(256-bit-secredfd)
)Token
토큰이 분리하는 이유는 토큰 주기를 다르게하여 토큰이 탈취당했을 경우 피해를 최소화하기 위함
Access Token
서버 API를 직접 요청할 때 사용 (짧은 주기)
Refresh Token
액세스 토큰이 만료되었을 때 액세스 토큰을 재발급할 목적으로 사용 (긴 주기)
Refresh Token의 실행 시점
1. 사용자가 로그아웃 후 재로그인할 때
로그아웃 시, 기존의 Refresh Token을 만료시키는 경우가 많습니다. 이때 사용자가 다시 로그인하면 새로운 Access Token과 Refresh Token이 발급됩니다.2. 보안 이벤트 발생 시 (예: 비밀번호 변경, 계정 설정 변경)
사용자의 계정 보안에 영향을 미칠 수 있는 이벤트(예: 비밀번호 변경, 2FA 설정)가 발생하면 기존 Refresh Token을 폐기하고, 이후 로그인 시 새로운 Refresh Token을 발급합니다.
Token Vs. Session
Session
Token
서버기반 Vs. 토큰기반
RTR ; Refresh Token Rotation
Access Token과 Refresh Token이 모두 탈취 되었을 경우
RTR 기법이란 RefreshToken을 한번만 사용하게 일회용 토큰으로 사용하는 기법
작동 원리
- Access Token1과 Refresh Token1을 얻음
- Refresh Token1을 사용하여 Access Token2와 Refresh Token2를 얻음
- Refresh Token2를 사용하여 Access Token3와 Refresh Token3를 얻음
- 위 과정을 반복
API 명세 예시 (ACCESS TOKEN 재발급)
Request
| 항목명(영문) | 항목크기 | 항목구분 | 샘플데이터 | 항목설명 |
|---|---|---|---|---|
| AccessToken | ||||
| RefreshToken |
Response
| 응답 코드 | 결과 | 응답 메세지 |
|---|---|---|
| 200 | 인증 성공 | 토큰이 인증되었습니다. |
| 400 | 에러 | 유효하지 않은 요청입니다. |
| 401 | 에러 | 토큰이 유효하지 않습니다. |
| 403 | 에러 | 권한이 없는 요청입니다. |
| 500 | 에러 | 서버 내부 오류로 인해 토큰 갱신에 실패했습니다. |
💡 일반적으로 POST 메소드의 성공 응답코드는
201 Created이지만
Access Token 재발급 API의 경우200 OK가 자주 사용됨
201은 서버가 클라이언트 요청을 받아 새 리소스를 생성하고, URI를 반환할 때 자주 사용Access Token 재발급의 경우, 새롭게 생성된 리소스라기보다 기존 인증의 갱신이라는 의미가 강하기 때문에, 상태 유지의 개념으로
200을 주로 사용
참고 블로그
💡 Token을 빠르게 처리하기 위해 Redis 사용
