[보안] JWT(Json Web Token)

JWT는 JSON 포맷으로 정보를 저장하고 이를 서명(Signature) 하여 위·변조를 방지하는 토큰이다.

서버가 클라이언트를 인증한 후, 인증 정보를 담은 토큰을 발급하여 클라이언트에게 전달하고, 이후 요청마다 이 토큰을 함께 보내도록 한다.

stateless하다는 특징을 가진다.

 

JWT의 구조

JWT는 총 3개의 부분으로 구성되며, 각 부분은 .으로 구분된다.

• [헤더].[페이로드].[서명]

헤더 (Header)

• 토큰의 타입과 해싱 알고리즘 정보를 담고 있다.
• 예: alg: HS256, typ: JWT

 

페이로드 (Payload)

• 실제 인증 정보나 기타 데이터(클레임)가 담기는 부분이다.
• 예: sub: 사용자ID, exp: 만료시간, role: ADMIN
• ※ 이 부분은 암호화되어 있지 않기 때문에 노출될 수 있으며, 민감한 정보는 넣지 않아야 한다.

 

서명 (Signature)

• 앞의 헤더와 페이로드를 합쳐서 비밀 키로 서명한 결과이다.
• 클라이언트가 변조한 토큰은 서버의 서명 검증을 통과할 수 없다.

 

 

동작 방식

로그인

사용자가 로그인하면, 서버는 사용자 정보를 확인한 뒤 JWT를 생성한다.

로그인 시 토큰 발급
클라이언트가 아이디/비밀번호로 서버에 로그인 요청을 보낸다.
서버는 사용자의 자격 증명을 검증한 뒤, 두 개의 토큰을 발급한다.

- 액세스 토큰: 사용자 인증 정보(예: ID, 권한 등)를 담은 JWT,  짧은 만료시간(보통 15분~1시간)
- 리프레시 토큰: 재인증 없이 액세스 토큰을 재발급받을 수 있도록 하는 토큰, 긴 만료시간(보통 1주~2주) 이 두 토큰은 클라이언트에게 전달된다.

액세스 토큰은 짧게 유지하여 보안성을 높이고, 자주 재발급되게 한다.
리프레시 토큰은 세션 전체를 대표하는 장기 토큰으로, 사용자가 일정 기간 동안 다시 로그인하지 않고 서비스를 쓸 수 있게 하기 위해 긴 유효 기간을 가진다.

액세스 토큰과 리프레시 토큰은 보통 레디스에 저장된다.

 

1. JWT는 클라이언트(브라우저나 앱)에게 전달되며, 주로 Authorization: Bearer <액세스 토큰> 헤더에 담겨 전송된다.

서버는 이 토큰을 검증하여 다음을 확인한다.

• 서명이 유효한가?
• 만료되지 않았는가?
• 권한이 적절한가?

 

2. 클라이언트는 이후의 모든 요청에 이 액세스 토큰을 포함시킨다.

3. 서버는 이 토큰의 서명을 검증하여, 사용자가 유효한지 판단한다.

4. 검증이 완료되면 요청을 처리하고, 그렇지 않으면 401 응답을 보낸다.

 

액세스 토큰 만료 시

• 액세스 토큰은 수명이 짧기 때문에 자주 만료된다.
• 이때 클라이언트는 리프레시 토큰을 사용해 새로운 액세스 토큰을 요청한다.(다시 로그인 하는 것이 아님.)
• 서버는 리프레시 토큰을 검증하고, 만료되지 않았고 탈취되지 않았음을 확인한 뒤 새로운 액세스 토큰을 발급한다.

 

 

리프레시 토큰 만료 시

• 리프레시 토큰까지 만료된 경우, 클라이언트는 다시 로그인을 해야 한다.
• 로그인 시에만 새로운 액세스/리프레시 토큰을 발급한다.
• 새롭게 리프레시 토큰을 받았다면 기존 리프레시 토큰은 블랙리스트 처리된다.
• 블랙리스트 처리된 리프레시 토큰은 남은 TTL동안 레디스와 같은 서버에 저장된다.(TTL만료시 삭제)

리프레시 토큰 재사용 감지와 블랙리스트 처리
- 리프레시 토큰을 재발급받을 때 기존 리프레시 토큰을 제출한다.
- 이때 이미 재발급한 리프레시 토큰이 있는데, 기존 리프레시 토큰으로 요청하면 토큰 탈취의 가능성을 강하게 의심할 수 있다.

이 시점에서 또 다시 블랙리스트 처리 및 전체 세션 무효화가 이루어져야 한다.
그렇기 때문에 새롭게 발급받은 리프레시 토큰도 블랙리스트 처리되고, 정상적인 사용자는 다시 로그인을 해서 리프레시 토큰을 다시 발급받아야 한다.

즉각적으로 블랙리스트 토큰을 레디스에서 삭제하는것이 아닌, 남은 TTL동안 보관하는 이유
블랙리스트에 등록된 토큰을 즉시 삭제하지 않고 남은 TTL 동안 Redis에 보관하는 이유는, 해당 토큰이 다시 사용될 경우 이를 탈취나 재사용 공격으로 감지하고 차단하기 위함이며, 동시에 토큰의 만료 시점과 블랙리스트의 무효 시점을 일치시켜 보안성과 시스템 일관성을 유지하기 위해서이다.

블랙리스트 방식 (Blacklist)
- 블랙리스트 방식은 "무효화된 리프레시 토큰들만 따로 관리"하는 방식이다.
- 상태를 최소한만 저장하므로 시스템 부하가 적다.
- stateless를 추구하는 JWT와 보안 문제의 절충안인 셈이다.

화이트 리스트 방식은 리프레시 토큰을 서버가 반드시 저장하고 관리하는 방식이다.
이는 세션 방식과 크게 차이가 없기 때문에 JWT의 stateless 추구와는 맞지 않는다.