JWT & Redis

JWT

jwt는 서버가 발급한 토큰을 사용자에게 넘겨주면 끝이다.

서버는 발급한 토큰을 기억할 필요 없는 stateless 방식이다.

(토큰을 발급하면 그 토큰에 필요한 정보가 포함되어 있어, 서버가 별도로 세션상 태를 저장하지 않아도 된다.)

 

서버는 토큰에 대한 내용을 기억할 필요 없이, 

사용자가 발급 받은 토큰으로 요청하면 해당 토큰을 복호화하고

그 결과에 따라 인가한다.

 

사용자 인증 (토큰 생성) -> 토큰 저장 (사용자) -> 요청 시 토큰 포함 (사용자) -> 토큰 검증 및 복호화 (서버가 유효성 검사하고 인가)

 

 

Refresh Token과 Access Token

하지만 토큰을 탈취 당하면 서버 측에서 해당 사용자의 유효성을 확인할 방법이 없다.

stateless한 방식이라 서버는 토큰에 대한 내용을 기억하고 있지 않기 때문이다.

 

이런 단점을 극복하기 위해 Refresh Token과 Access Token 방식이 사용된다.

 

사용자 인증 {토큰 생성(유효기간 짧은 엑세스 토큰, 액세스 토큰 받을 때 쓸 리프레쉬 토큰)} -> 토큰 저장 (사용자) -> 요청 시 토큰 포함 (사용자) -> 토큰 검증 및 복호화 (서버가 유효성 검사하고 인가, 엑세스 토큰 만료시 리프레쉬 토큰 검증 후 재발급)

 

1. JWT의 기본 개념:
   - 서버는 사용자가 인증에 성공하면 JWT를 발급.
   - 클라이언트는 이 JWT를 저장하고, 이후 요청에 포함.
   - 서버는 요청을 받을 때 JWT를 검증하고, 복호화하여 인가.

2. JWT의 단점 및 리프레시 토큰의 도입:
   - JWT가 탈취되면 유효기간 동안 악용 가능.
   - 이를 해결하기 위해 리프레시 토큰이 사용됨:
     - 짧은 유효기간의 액세스 토큰과 긴 유효기간의 리프레시 토큰 발급.
     - 액세스 토큰 만료 시 리프레시 토큰으로 새로운 액세스 토큰 발급.

3. 리프레시 토큰의 장점:
   - 보안 강화: 액세스 토큰의 짧은 유효기간으로 피해 최소화.
   - 사용자 편의: 리프레시 토큰으로 지속적인 인증 유지.

 

1. JWT의 기본 개념:
   - 서버는 사용자가 인증에 성공하면 JWT를 발급.
   - 클라이언트는 이 JWT를 저장하고, 이후 요청에 포함.
   - 서버는 요청을 받을 때 JWT를 검증하고, 복호화하여 인가.

2. JWT의 단점 및 리프레시 토큰의 도입:
   - JWT가 탈취되면 유효기간 동안 악용 가능.
   - 이를 해결하기 위해 리프레시 토큰이 사용됨:
     - 짧은 유효기간의 액세스 토큰과 긴 유효기간의 리프레시 토큰 발급.
     - 액세스 토큰 만료 시 리프레시 토큰으로 새로운 액세스 토큰 발급.

3. 리프레시 토큰의 장점:
   - 보안 강화: 액세스 토큰의 짧은 유효기간으로 피해 최소화.
   - 사용자 편의: 리프레시 토큰으로 지속적인 인증 유지.

 

Redis에 토큰 정보를 저장

하지만 이런 Refresh Token과 Access Token 방식도 여전히 같은 문제가 발생한다.

 

토큰의 강제 취소나 유효기간 관리를 위해 서버는 발급한 토큰에 대한 데이터를 저장할 필요가 있고,

이를 위해 

서버는 인메모리 방식의 Redis를 일반적으로 사용해 토큰 관리를 사용한다. 

 

 

Redis

Redis는 인메모리 방식이라 속도가 매우 빠르고,

TTL 기능이 있어 유효기간이 지난 토큰 데이터를 자동으로 관리할 수 있으며(Time To Live),

분산 시스템을 지원하므로, 대규모 트래픽을 효율적으로 처리할 수 있다. 

 

 

 

저장되는 토큰 정보

탈취당해 무효화된 토큰이나 (블랙리스트)

사용자에게 발급한 리프레시 토큰을 저장한다. 

 

 

 

결론

이렇게 JWT와 Redis를 함께 사용하면 

JWT의 stateless한 장점과 토큰을 저장하고 그 상태를 관리하는 stateful 장점이 결합되어 보다 안전하고 유연한 인증 시스템이 구현된다.