• 이미지 출처 : Refresh Tokens

1. 리프레시 토큰(Refresh Token)의 역할

액세스 토큰은 영원해서는 안된다

• 액세스 토큰은 보안을 위해 짧은 만료 시간(예: 15분 ~ 1시간)을 가져야한다.

• 만료된 액세스 토큰으로는 더 이상 요청을 처리할 수 없도록 해야한다.

리프레시 토큰의 사용:

• 리프레시 토큰은 보통 더 긴 만료 시간(예: 7일 ~ 30일)을 가지며, 액세스 토큰을 재발급받는 데 사용한다.

• 사용자가 다시 로그인할 필요 없이 새로운 액세스 토큰을 발급받아 인증 상태를 유지할 수 있다.

2. 리프레시 토큰(Refresh Token) 사용 시 동작 흐름

• 사용자가 로그인.

->

• 서버는 액세스 토큰과 리프레시 토큰을 생성하여 클라이언트에 전달.

->

• 클라이언트는 요청마다 액세스 토큰을 Authorization 헤더에 포함하여 서버에 전송.

->

• 액세스 토큰이 만료되면 서버는 요청을 거부(401 Unauthorized).

->

• 클라이언트는 서버의 리프레시 토큰 엔드포인트(/refresh-token)로 리프레시 토큰을 전송하여 새로운 액세스 토큰을 요청.

->

• 서버는 리프레시 토큰이 유효하다면 새로운 액세스 토큰을 발급.

3. 리프레시 토큰(Refresh Token)은 어디에 저장되어야 하지?

• 민감한 정보를 포함하고 있는 토큰은 안전한 저장 위치를 선택하는 것이 매우 중요하다. 도대체 어디에 저장해야하는 것인가?

클라이언트?

• 쿠키 혹은 웹 스토리지에 저장.

• 가장 간단하지만.. 외부 공격에 가장 취약하다!

• 토큰이 탈취당하는 순간, 공격자는 액세스 토큰을 무한정 발급받아 시스템에 침투할 수 있기 때문.

• 웹 스토리지는 구조 특성상 방어가 불가능하다. 쿠키를 사용한다면 HttpOnly, Secure, SameSite 속성을 설정하여 JavaScript 접근을 차단하고, HTTPS를 통해 안전하게 전송해볼 수 있다.

서버?

• 더 정확하게는 서버 측 데이터베이스에 저장하는 방식.

• 데이터베이스에 사용자별로 리프레시 토큰을 저장, 클라이언트는 토큰의 식별자(ID)만 보관하고, 서버에서 이를 조회하여 유효성을 검증하는 식.

• 클라이언트에서 침입이 발생해도, 서버에서 이를 막을 수 있으니 안전하다.

• 다만 서버에서 수행하는 작업이 많아지므로 리소스 소모가 커진다.

• 당연하지만, 데이터베이스에 저장되는 토큰은 필히 암호화해주어야 한다.