refresh token

Refresh Token

Login 구현방식

우리가 사용하는 koa 프레임워크는 우선 passport 지원이 안된다.

그래서 인증 미들웨어를 직접 구현해야 했다.

GitHub OAuth를 보면 어떤방식으로 구현했는지 알 수 있다.

---

Refresh Token?

AccessToken

기존에는 로그인 시에 토큰을 하나만 발급했고, 그 토큰을 Local Storage 에 저장했다.

이 방법은 좋지 않다는 사실을 토큰에 관하여 찾다가 알았다.

토큰이 탈취당하면, 이 토큰을 가지고 해당 사용자의 서비스에 접근하여 어떤 짓이든 할 수 있다는 것이다.

Refresh Token!?

그래서 찾아낸 방법이 Refresh Token이다.

Refresh Token는 Access Token( 기존 토큰 ) 에 만료기간을 정하고, 만료가 되면 Refresh Token을 사용하여 Access Token을 재발급받는다.

이 방법이 Access Token을 탈취당해도 만료된 후에는 사용할 수 없는 토큰이 되므로 더 안전했다.

구현에는 여러가지 정보를 수집, 참고했지만 가장 많이 참고한 구조는 RFC 6749 였다.

모두 해결되었는가?

Refresh Token 관리

구현방식

Refresh Token을 구현했으나, 어디서 관리할 것이냐가 문제였다.

대부분의 웹 서버는 Resouce Server와 Auth Server를 따로두고 관리했다.

우리는 Resource Server와 Auth Server가 나뉘어있지 않았다.

하지만, Access Token이 expired 된 상태에서 Refresh Token을 사용하려면 아무래도 Front 단에 있어야 했다고 생각했다.

그래서 Front End의 local storage 에 보관하기로 했다.

문제인식

사실상 local storage에 저장하면 Access Token과 마찬가지로 취약해진다.

다만 Access Token "만" 탈취 당했을 경우를 생각하면 그래도 조금 더 안전해졌다고 생각해 볼 수 있다.

대안

여러가지 방법을 더 찾아봤다. 이중 내가 얻은 방법은 약 3가지가 있다.

1. Black List
   • 이 방법은 "로그아웃"이나 기타 다른 방법으로 Refresh 토큰이 만료됐을 경우에 사용한다.
   • 기존에 사용하고 있던 DB나 Redis 와 같은 In memory 방식의 DB에서 Refresh 토큰을 저장한다.
   • 저장된 토큰을 Black List로 관리하며, Refresh Token이 탈취 되었을 경우, 이 리스트를 확인하여 유효한 Refresh Token인지 확인한다.
2. Sliding Session
   • 슬라이딩 세션은 일정 시간동안 사용되지 않으면 만료되는 세션이다.
   • 요청이 있을 경우에 새로운 Access Token 혹은 Refresh Token을 발급하여 유효 기간을 늘려주는 방법이다.
   • 이 방법은 Access Token 혹은 Refresh Token에 적용한다.
   • Access Token에 적용했을시
     • Refresh Token을 굳이 발급하지 않아도 된다.
     • 요청이 올때마다 새로운 Access Token을 발급한다.
     • Access Token 의 유효기간을 최소한으로 줄일 수 있다.
     • Access Token이 탈취되고 사용하지 않으면 금방 만료가 되기 때문에 이런 조건에선 유리하다.
     • 다만, Access Token이 탈취되고 유효기간안에 계속해서 요청을 보내는 조건에선 불리하다.
     • Access Token의 만료 시간에 대해 고민해야할 필요가 있다.
   • Refresh Token에 적용했을시
     • 상대적으로 유효기간이 긴 Refresh Token에 적용하는 방법
     • Access Token 처럼 매 요청마다 새로운 Access Token을 발급하지 않아도 된다.
     • 토큰의 만료시간에 대해 고민할 필요가 없다.
     • 다만, 만료기간이 길기 때문에, 추가적인 인증이 필요할 수 있다.
     • 또, 인증정보에 변화가 있을시 Server에서 자체적으로 토큰을 만료 시켜야한다.
3. Refresh 토큰의 보관방식 변경
   • Resource 서버와 Auth 서버 분리
     • 최근에 생각한 방법이다.
     • 인증 서버를 따로두고, Refresh Token을 Resource 서버에서 보관한다면?
     • Front에서 요청을 보냈을 때, 만료된 토큰이면 Resource 서버에서 Auth 서버로 Refresh 토큰을 보낸다.
     • Auth 서버에서 Refresh 토큰을 확인하고, 새로운 Access Token을 발급해준다.
     • Resouce 서버는 받은 Access Token을 Client의 요청에 대한 응답과 함께 보내준다.
     • 이 방법은 Backend에 Refresh Token을 저장하므로 탈취 가능성을 배제할 수 있을 것 같다.
     • 하지만, Resource 서버와 Auth 서버에서 Refresh Token의 정보를 맞춰줘야 수월하게 동작할 것 같다.
       • Resource 서버에서는 Access Token과 Refresh Token에 대한 관리를 해줘야하고 ( Access Token과 Refresh Token의 정보를 맞춰야함 )
       • Auth 서버에서는 Refresh Token의 블랙리스트를 관리해야할 것 같다.

앞으로 시도해볼 것 들

• Refresh Token 역시 보안적으로 완벽하지 않기 때문에 위에 있는 대안을 하나씩 적용해볼 생각이다.

1. Black List 구현
2. Sliding session 을 구현
3. Black List + Sliding Session
4. Server 분리
   • Resource Server
   • Auth Server
5. Black List + Sliding Session + Resource, Auth Server