[로그인 인가 인증] Refresh Token Rotation

 

Refresh Token Rotation으로 인증 & 인가 안전하게 처리하자

 

✨ 먼저, refreshToken이란 무엇일까?

 

JWT 로그인에서 AT(accessToken)와 RT(refreshToken)가 등장한다. 

accessToken은 사용자를 인증하고, API 호출 시 권한을 부여하기 위해 사용하며, refreshToken은  accessToken이 만료되었을 때, 새 accessToken을 발급받기 위해 AT 갱신 용도로 사용되는 토큰이다.

 

 

이 토큰과 DB에 관해 말해보려한다!

 

토큰은 DB에 저장하지 않는다. JWT를 쓰는 이유가 자체 검증이 가능하기 때문이라 따로 매핑이 필요 없다.

다만 보안때문에 저장을 하는 경우가 있는데 이는 어떤 사용자의 토큰인지 알기위함이 아니라 특정 토큰이 탈취 됐을 경우 해당 토큰을 더이상 사용하지 못하도록 하기 위함이다.

 

이때, 휘발성이 강한 Redis 같은 인메모리 데이터베이스를 많이 사용한다고 한다. Refresh Token은 영구적으로 저장될 필요가 없기 때문에 인메모리 DB를 사용해도 충분하고, 성능 이점을 챙길 수 있다.

 

추가적으로 아래는 redis를 사용하는 경우인데 토큰의 경우에는 후자에 속한다고 볼 수 있겠다. ( I/O가 빈번한 경우를 들었지만, 가장 많이 사용되는 건 사용자의 세션 관리, 메시지 큐잉, API 캐싱 이라고 한다.)

 

1. 운영 중인 웹 서버에서 키-값 형태의 데이터 타입을 처리해야 하고
2. I/O가 빈번히 발생해 다른 저장 방식을 사용하면 효율이 떨어지는 경우

 

 

RTR(Refresh Token Rotation)

Access Token이 만료될 때마다 Refresh Token도 함께 교체를 해주는 것.

Refresh Token을 최대한 짧게 유지하고, 재사용 불가능하게 만들어 보안을 보장하는 방법

출처: https://velog.io/@chchaeun/%EC%9D%B8%EC%A6%9D%EA%B3%BC

 

 

보통 Refresh Token을 통한 인증/인가 플로우는 다음과 같이 흘러간다.

일반적으로 Access Token은 30분~1시간, Refresh Token은 2주 정도의 유효 기간을 가지는데

 

⚠️이때 주의해야 할 점이 바로 Token 탈취이다.

 

Access Token 탈취로 인한 공격을 막기 위해 Refresh Token을 사용하지만 Refresh Token 역시 탈취 가능성이 있어 

탈취한 공격자는 이것으로 Access Token을 발급받아 유저 정보에 접속할 수 있다..

 

이를 예방하기 위한 방법이 바로 Refresh Token Rotation(RTR)이다.

 

출처: https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-rotation

 

1. 서버에 Authorization 요청을 보낸다.
2. User확인 후 Authorization Code를 클라이언트에 return!
3. 클라이언트가 서버에 Authorization Code를 Access Token으로 교환한다.
4. 서버는 AT-1와 RT-1를 반환한다.
5. AT-1이 만료되면, 클라이언트가 새 AT-2를 얻기 위해 RT-1를 전달한다.
6. 서버는 새 AT-2와 새 RT-2 반환하고, RT-1는 만료된다.

 

자동 재사용 감지 (Automatic reuse detection)

자동 재사용 감지는 새 AT를 발급받을 때, 함께  보낸 Refresh Token은 무효화되는데 이때 이 무효화된 Refresh Token으로 AT 발급 요청을 하는 Reply Attack 상황으로부터 보호하는 것이다.

Reply Attack이란?
: 공격자가 자격을 얻기 위해 이전에 보낸 메시지를 가로채 다시 보내는 것

무효화된 Refresh Token이 인증 서버로 전송되면 가장 최근 발행된 Refresh Token도 즉시 무효화되며 같은 Token Family에 속한 어떤 RT도 새로운 AT를 얻을 수 없게 막히게 된다. 

 

시나리오를 확인해보자.

 

1. 사용자가 RT를 탈취당했다.

2. 사용자는 RT-1로 AT발급을 요청한다.

3. 서버는 RT-2/AT-2를 반환한다.

4. 공격자가 RT(1)으로 AT를 얻으려고 시도

5. 서버는 RT(1)이 재사용됨을 인지

6. RT(2)을 포함한 RT Family를 무효화

7. Access Denied를 응답→  Re-authentication이 요구

 

 

이러한 방법으로 단순히 AT, RT만을 이용해 탈취를 예방하는 것이 아니라 RTR을 활용해 더 안전한 인증, 인가가 이루어질 수 있다는 것을 알 수 있다. 😊🙌

 

 

 

---

 

 

*참고자료*

Auth0

 

인증과 인가를 안전하게 처리하기 (Refresh Token Rotation)

[맵필로그 + NestJS] Access-Token과 Refresh-Token 전략 정리와 수정해야 할 부분 in NestJS? (약간 장문주의)

Refresh Token Rotation 과 Redis로 토큰 탈취 시나리오 대응

 

Redis) 싱글벙글 Refresh Token을 Redis에 저장하고 사용해보자

[Redis] EC2 환경에서 Docker에 Redis 설치 후 실행하기

[도커]도커에서 레디스 사용하기