글의 내용중 틀린 부분이 있거나, 얘기 할 부분이 있으시면 댓글로 적어주시면 좋겠습니다.
말하고자 하는것?
- 자사 웹사이트를 구축할 때, 또는 본인만의 사이트를 만들 때 refresh token을 이용한 token 방식을 사용해야 하는가?
- 당신이 타사 어플리케이션에 리소스를 제공하는 주체가 아니라면 굳이 refresh token을 사용하여 인증을 구현 할 필요가 없다.
- 용도와 상황에 맞는 기술을 쓰는건지 다시 한번 생각해보자.
왜 그런 생각을 하였는지?
refresh token 구현하기 귀찮아서
어느 순간부터, 웹사이트에서의 인증 방식을 보면, Refresh Token을 사용한 token 기반의, 서버 <-> 클라이언트(브라우저) 인증방식을 많이 차용을 하는데, 해당 서비스의 환경에서, 차용한 이유가 나에게는 납득이 되지 않기 때문이다.
Refresh Token 사용 이유가 납득이 되지 않는 이유
납득이 되지 않은 포인트는 크게 3가지 정도로 나눠진다.
1. token 기반 인증의 장점이 퇴색된다.
설명에 앞서 token 기반 인증의 장점과 인증 흐름에 대해 대략적으로 살펴보자.
흔히 알려진 token 기반의 장점
- 서버에서 정보를 가지고 있지 않기에 가볍다.
- 위와 같은 이유로, 확장성이 뛰어나다.
- 플랫폼에 독립적이지 않다. (주제 범위 밖이라 제외)
Token의 인증 흐름
(대부분이 jwt를 통해 구현함으로 jwt토큰이라 가정하고 흐름을 작성하였다.)
Access Token만 사용할 경우
Refresh Token까지 사용할 경우
(Refresh Token 전달 시점의 경우 구현에 따라 조금씩 다를 수 있으니 대략적으로 봐주면 되겠다.)
위의 장점과 흐름을 살펴보았으니, 이제 퇴색되는 이유를 적어보겠다.
정보를 가지고 있지 않기에 가볍다?
Refresh Token을 적용한 시점에서, DB에 정보를 저장해야한다. (Access Token 의 BlackList 적용, 또는 Client에 Refresh Token을 두지 않게 하기 위해) 이 시점부터 StateLess 하여 가볍다는게 성립 할 수 없다.
또한, 일반적으로 구현하는 JWT 에서는 저장하려는 정보가 늘어날수록 Token의 길이 또한 늘어나게 된다.
간단한 사이트의 경우 이 사항이 상관이 없을 수도 있지만, RBAC(Role Base Access Control), ABAC(Attribute Base Access Control) 등을 이용할 복잡한 권한이 필요한 서비스의 경우, 토큰 사이즈가 매우 늘어날 것이다.
즉, 네트워크의 오버헤드가 증가하기에 가볍지 않을 수 있다.
성능상으로도 가볍지 않다.
단순히 토큰 자체의 값이 변질되었는지를 복호화를 통해 알아내는게 가벼울 수는 있다. 그러나, 위의 Access Token을 활용한 악의적인 사용자의, 비정상적인 활동을 차단하거나, 로그아웃에 대한 처리를 위해 BlackList 의 적용을 가정한다면, Token에서도 Session이 SessionId를 통해 정보를 조회하는 과정이 추가된 것과 같으며, Token의 비용이 더 클 확률이 높다.
확장성이 뛰어나다?
세션과 비교하였을때, 확장성이 뛰어나다는게 장점이라 하나,
세션도 일반적인 저장 방식인 File이 아닌 Redis cluster와 같이 별도의 세션 저장소를 두게 될 경우엔 Session 방식도 확장성이 뛰어 나다고 할 수 있다.
2. SPA(Single Page Application) 이라서?
React, Vue 등의 SPA에서도 세션 사용은 가능하다.
SPA로 구현한 APP은 단순히 정적인 파일이지만, 그 APP이 요청을 보내는 서버는 '서버'이기에 SSR이든 SPA든 결국 동일하다는 소리이다.
다른 예시로는, 세션방식에서의 로그인 흐름을 pseudo code로 간단히 적어보자
1. 클라이언트는 로그인 정보를 서버로 요청한다.
2. 로그인이 성공할 경우 서버는 유저 정보를 세션저장소에 저장한다.
3. 세션 아이디가 담긴 쿠키를 클라이언트로 전달한다.
4. 세션 쿠키가 저장된다.위와 같이 결과적으로는 '쿠키'가 클라이언트로 전송이 된다.
이것이 SPA에서 달라지는것이 있는가? 달라지는 것은 없다.
또한, PHP 프레임워크 중 하나인 laravel의 sanctum이라는 인증 시스템에서는 아래와 같이 SPA환경에서의 인증을 지원한다
3. 용도가 다르지 않을까?
Refresh Token에 대해 찾아보다 보니, 대부분 Oauth에 관한 말들이 있어, Oauth 2.0에 관한 RFC문서를 보게 되었다.
여기서 설명하는 Refresh Token의 흐름을 보면
크게 인증서버, 리소스 서버, 클라이언트로 나누어져 있다.
여기까지만 보면 인증서버 따로, 리소스 API 서버를 따로 두고 client는 브라우저와 같이 취급되면 될 것처럼 보인다.
그러나, 해당 문서의 Abstract 을 보면 아래와 같다.
(papago 번역결과)
OAuth 2.0 인증 프레임워크를 통해 타사 제품 지원 가능
HTTP 서비스에 대한 제한된 접근을 얻기 위한 응용 프로그램, 또는 위에서
승인 상호 작용을 조정하여 리소스 소유자 대신
자원 소유자와 HTTP 서비스 사이에 또는 허용함으로써
제3자의 신청을 통해 스스로 접근할 수 있습니다... (일부 생략)내가 이해한 바에 따르면, 타사 인증에 제한적 접근을 위해, 사용하는 방식이었으며, 해당 문서에 있는 Refresh Token의 흐름은 인증서버와 리소스 API 서버, client가 아니다는 것이며,
해당 방식을 구현한다면 나는 Kakao, Google과 같은 타사 어플리케이션에 리소스를 제공하는 제공자 이어야한다는 것이다.
하지만 Refresh Token을 구현하는 서비스에서 타사에 리소스를 제공하는 형태보다는(서비스를 나누어 분리하는 경우 포함) 서비스와 인증이 1대 1로 대응하는 방식으로 구현을 많이 하니, 용도에 다른 방식으로 구현하는게 아닐까 라는 생각이 든다.
끝으로
쓰지 말라는게 아니다
이 글을 쓴 이유는 Refresh Token 에 대해 개인적인 생각을 쓴 글일 뿐이며, 어디까지나, 이 방식을 적용할 이유가 있어야 하고, 이 방식을 적용할 리소스(인력, 시간, 개발능력)를 고려해야 한다 말하고 싶었다.(Token 자체를 부정하는 것 또한 아님)
또한, 본인이 개인 프로젝트나, 학습 차원에서의 개발에서는 마음가는 방식으로 하면 되니, 가볍게 생각해주시면 되겠다.
참고한 링크 :
https://datatracker.ietf.org/doc/html/rfc6749#section-1.5
https://datatracker.ietf.org/doc/html/rfc7519
https://jwt.io/
etc :
처음 쓴 블로그 글이라 생각 한 것 보다 시간이 오래 걸렸다. (앞으로 자주 쓰도록 노력하겠다.)
