Refresh Token에 대한 고찰

What Is a Refresh Token?

Refresh token은 새로운 Access Key을  받아오기 위한 별도의 key이다. 

 

What Is the Purpose of a Refresh Token?

Refresh token이 존재하는 이유는 access token의 짧은 주기 때문이다. 짧은 주기로 User Experience가 나빠질 가능성이 있으므로, 상대적으로 수명이 긴 Refresh token을 제공

 

이 Refresh Token을 어느 Layer에서 관리해야할지에 대한 고민들을 하고 있다. Client가 관리해야 할지, 서버에 저장해야 할지 고민하고 있다. 관련해서 한 포스팅을 보고 정리하고자 한다.

 

※ 관련포스팅 : https://tecoble.techcourse.co.kr/post/2021-10-20-refresh-token/

refresh token 도입기

 

1) Refresh Token을 Frontend Side Server 에 저장하는 경우

장점

• 새로 고침 상황에서 공통기능-Backend side Server 까지 요청이 전달되지 않아도 된다 : Frontend Side Server 에 refresh token과 access token이 사용자마다 저장되어 있기 때문에 access token을 얻기 위해 추가로 공통기능-Backend side Server 로 요청을 보낼 필요가 없다. 요청 횟수에서 경제적이라 할 수 있다.
• access token 재활용이 가능 : refresh token을 백엔드 서버에 저장하는 경우는 새로 고침 했을 때, access token 만료 기간이 한참 남았음에도 access token을 재발급받는다. 왜냐하면, Frontend Side Server 를 거쳐 공통기능-Backend side Server 까지 이미 요청이 도달했기 때문에 access token을 재활용하는 것보다 재발급하는 것이 오히려 경제적일 수 있기 때문이다. 예를 들어 만료 기간이 10초 남은 access token을 재활용해봤자 금새 access token 재발급을 위해서 공통기능-Backend side Server 로 요청을 보내야 한다. 그래서 새로 고침 시에 공통기능-Backend side Server 에서 그냥 token을 재발급하는 것이 오히려 더 경제적이다. 하지만 Frontend Side Server 에 refresh token과 access token을 저장하는 경우는, token을 얻기 위한 요청이 백엔드 서버까지 전달될 필요가 없기 때문에 access token을 재활용함으로써 요청에 드는 비용을 절약할 수 있다.

단점

Refresh Token은 AccessToken을 재발급 받을 수 있는 보안이 중요한 Key로써 Frontend Side 어디에서 저장할지가 중요해보인다. Client Side에는 노출되지 않는 저장소가 필요하다.

 

2) Refresh token을 백엔드 서버에 저장하는 경우

장점

서버 issue를 백엔드 서버에서 대부분 처리하기 때문에 관리에 용이하다 : 사용자가 많아짐에 따라 생기는 서버 issue를 공통기능-Backend side Server 에서 모두 처리하기 때문에 관리 포인트가 Frontend Side Server, 공통기능-Backend side Server 둘로 나뉘지 않고 공통기능-Backend side Server 서버 한 곳에서 처리된다. 따라서 서버 issue 관리에 용이하다.

 

단점

새로 고침하면 항상 Frontend Side Server 를 거쳐 공통기능-Backend side Server 까지 요청이 전달된다 : token이 Frontend Side Server 에 따로 저장되지 않기 때문에 access token을 얻기 위해서는 항상 공통기능-Backend side Server 까지 요청이 전달되어야 한다. 요청 횟수, 요청에 드는 간접비용 등을 고려해봤을 때 비효율적일 수 있다

 

 

그렇다면 빅테크 기업과 구글은 어떻게 하고 있나.

 

구글,카카오의 경우, 소셜로그인에서 Oauth 및 Refresh Token 체계는 제공하고 있다. 하지만 정작 자신들 고유 서비스(포털사이트 등)는 별도의 인증 체계를 가져가고 있다. Oauth, RefreshToken 등 기존 프레임워크가 아닌 별도의 인증체계를 가져가고 잇음

 

소셜로그인은 OAuth2.0 표준을 지키고 있고, Refresh Token에 대해서는 Frontend가 되었건 Backend가 되었건 Server Side에 저장하는것으로 가이드되어 있다.