Refresh Token
- Access Token 은 쉽게 탈취당할 수 있는 환경에 노출되어 있기 때문에 주로 짧은 주기의 유효기간을 갖는다.
- Access Token 이 만료 되었을 때 새로운 Access Token 을 발급받기 위해 Refresh Token 을 사용한다. Access Token 보다는 긴 유효기간을 갖는다.
- Access Token 이 만료되었을 경우 만료된 Access Token 과 Refresh Token 을 함께 담아서 새로운 토큰 발급 요청을 하는 방식
Access token 과 Refresh token 시퀀스 다이어그램
Access Token 을 DB 에 저장해서 사용하는 이유
중복 로그인 방지를 위해 가장 최근에 생성된 토큰을 DB 에 저장하고 토큰 검증할 때 최근 발급된 토큰인지 검증하기 위함.
문제점
- 데이터 베이스가 해킹되거나 무단 접근을 당할 경우, 공격자가 Access Token 을 탈취하여 사용자의 권한을 악용할 수 있습니다.
- API 요청이 올 때마다 DB 에 액세스 해야하므로 데이터베이스에 대량의 요청이 발생할 수 있어 성능 이슈가 발생할 수 있습니다.
- 사용자가 로그아웃 하거나 사용자 정보가 변경되거나 세션을 종료해야할 때 DB 에서 토큰을 삭제해야하는 추가 작업이 발생합니다.
- 여러 서버에서 애플리케이션을 실행할 경우, 동일한 데이터베이스를 공유하여 관리해야하기 때문에 스케일링에 어려움이 생기고 데이터베이스에 부하가 발생합니다.
- 토큰은 stateless 하기 때문에 서버는 한번 발급한 토큰에 대해서 제어권을 가지고 있지 않습니다. 따라서 Access Token 이 탈취되었을 경우 토큰이 만료될때 까지 속수무책으로 당할 수 밖에 없습니다.
Refresh Token 도입
- 보안이 강화됩니다. Access Token 의 유효 기간을 짧게 둘 수 있으며, 토큰을 자주 재발급 하게 함과 동시에 사용자에게 잦은 로그아웃 경험을 주지 않을 수 있습니다.
- 만약 Refresh Token 이 탈취되었을 경우를 대비해 RTR(Refresh Token Rotation) 을 도입합니다. Refresh Token 을 통해 새로운 Access Token 을 발급 받을 때 Refresh Token 도 새롭게 발급하는 방식입니다. 간단히 말하면, Refresh Token 을 일회성으로 사용하여 보안을 더욱 강화할 수 있습니다.
- 매 api 요청마다 DB 에 접근하지 않아도 되기 때문에 성능이 저하되지 않습니다.
- 데이터베이스에서 토큰을 삭제해야하는 번거로운 작업이 필요하지 않습니다.
Access Token 만 사용하는 경우와 Refresh Token 을 함께 사용하는 경우 장단점
| Access Token 만 사용하는 경우 | Refresh Token 을 함께 사용하는 경우 | |
|---|---|---|
| 장점 | - 간단하고 직관적인 인증 방식이다. - Access Token의 유효 기간 동안 사용자가 서비스를 계속 이용할 수 있다. - 인증 서버에 추가적인 부하나 복잡성이 없어 구현이 간단하다. | - Access Token의 - 유효 기간이 짧아도 Refresh Token을 사용하여 Access Token을 갱신할 수 있어서 보안이 강화된다. - 사용자의 로그인 상태가 변경되면 Refresh Token을 사용하여 Access Token을 즉시 만료시킬 수 있다. - Access Token이 탈취되더라도 Refresh Token은 서버에서만 관리되기 때문에 보안이 향상된다. |
| 단점 | - Access Token의 만료 시간이 짧으면 자주 재발급을 해야 하며, 긴 경우에는 보안에 취약해질 수 있다. - 웹사이트를 이용 중에 Access Token이 만료되면 사용자는 잦은 로그아웃 경험을 하게 된다. - 사용자의 로그인 상태가 변경되면 직접 Access Token을 만료시키는 것이 어렵다. | - 구현 및 관리가 좀 더 복잡해진다. - Refresh Token을 사용하여 Access Token을 갱신할 때 추가적인 네트워크 요청이 필요하다. - Refresh Token을 안전하게 보관해야 하며, 이를 위해 추가적인 보안 메커니즘이 필요할 수 있다. - 토큰을 별도로 저장해야해서 JWT를 쓰는 장점이 사라진다. |
Access Token 을 DB 에 저장해서 쓰는 경우 문제점
| 문제점 | 해결 방안 |
|---|---|
| 데이터 베이스가 해킹되거나 무단 접근을 당할 경우, 공격자가 Access Token 을 탈취하여 사용자의 권한을 악용할 수 있습니다. | 토큰을 DB에 저장할 때 보안을 강화하기 위해 데이터 암호화 및 접근 제어를 적용하여 보안 취약점을 최소화합니다. |
| API 요청이 올 때마다 DB 에 액세스 해야하므로 데이터베이스에 대량의 요청이 발생할 수 있어 성능 이슈가 발생할 수 있습니다. | 서버의 메모리에 최근에 접근한 사용자의 토큰을 저장합니다. 이를 통해 같은 사용자가 다시 요청할 때 DB에 접근하지 않고 메모리에서 데이터를 반환할 수 있습니다. => 지양 스케일링이 필요한 경우 Redis 에 토큰을 저장해서 공통으로 활용한다. |
| 사용자가 로그아웃 하거나 사용자 정보가 변경되거나 세션을 종료해야할 때 DB 에서 토큰을 삭제해야하는 추가 작업이 발생합니다. | - |
| 여러 서버에서 애플리케이션을 실행할 경우, 동일한 데이터베이스를 공유하여 관리해야하기 때문에 스케일링에 어려움이 생기고 데이터베이스에 부하가 발생합니다. | 분산 캐시 시스템을 도입하여 데이터베이스 부하를 줄일 수 있습니다. Redis 같은 분산 캐시 시스템을 사용하여 자주 접근되는 데이터를 메모리에 저장하고, 서버 간에 데이터를 공유할 수 있습니다. |
| (jwt 문제점) 토큰은 stateless 하기 때문에 서버는 한번 발급한 토큰에 대해서 제어권을 가지고 있지 않습니다. 따라서 Access Token 이 탈취되었을 경우 토큰이 만료될때 까지 속수무책으로 당할 수 밖에 없습니다. | Access Token의 만료 시간을 가능한 짧게 설정하여 탈취된 토큰이 오랫동안 유효하지 않도록 해야 합니다. Refresh Token 을 도입하여 Access Token 의 만료 시간을 줄입니다. |
reference
Web Developer