항해 99 24일 차
Refresh Token
해커의 Access Token 탈취를 방지하기 위해서, Access Token 의 유효기간을 짧게 두고
Access Toekn 의 유효기간이 만료되었을 시, 다시 서버에게 Request 헤더에 Refresh Token 을 삽입한채로
인증(Silent Authentication)을 요청하기 위해 사용되는 토큰.
서버는 Refresh Token 을 검수한 후, 클라이언트에게 Access Token 을 재발급한다.
주로 Refresh Token 은 서버 DB에 저장한다고 한다.
Access Token 은 다양한 정보를 담고 있으며, Refresh Token 은 재발급때 도움을 주는 짤막한 정보만 담아야 할 것이다. (뇌피셜)
# 의문점
1. Refresh Token 자체에도 인증정보가 있을텐데 굳이 서버 DB에 저장해야 되는가?
DB에 저장하지 않으면, 서버는 해당 토큰을 발급한 사실을 알 수가 없음.
Refresh Token 의 payload 로만 Access Token의 발급여부를 판단할 경우
해커가 Refresh Token 을 탈취 후, 임의로 payload의 정보를 유사하게 변경하여 생성하여
탈취당한 유저의 정보뿐 아니라 다른 유저의 정보까지도 접근가능해짐
이를 막기 위한 것으로 보인다.
2. Access Token 이 탈취되는 것처럼 Refresh Token 또한 탈취 되지 않을까?
보통 대부분의 경우, 네트워크를 통하여 탈취가 진행된다고 한다. (HTTP 요청을 탈취)
(그럼 Refresh Token도 HTTP Header에 포함이되기 때문에 탈취되지 않나?)
---- [해결못한 궁금증] -----
(??? 링크 본문엔 탈취하면 해커가 아주 길게 서버에 안락하게 접근가능하다고 적혀있다..)
---- [또 다시 커지는 궁금증] ----
이를 막기 위해 Refresh Token Rotation (RTR) 기법이 사용된다고 한다...
---- [점입가경] ----
* [RTR 기법에 대한 짤막정리]
Refresh Token 을 One time Use Only 로 설정한다. (한번 쓰면 다음 refresh token 을 발급) ---- [오오...]
한번 이상의 Refresh Token 의 사용이 감지되면, 탈취된 것으로 간주하고
탈취된 것으로 간주 된 Refresh Token으로 인해 발급된 모든 Refresh Token 들을 폐기한다.
(Token Chain 을 만들어야 하고, 관리해야 한다.) --- [Token Chain 길이가 너무 길어지지 않게 제한하면 좋을듯?]
RTR 기법 그림예시 (https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implications.html)
* 해커가 지속적으로 Access Token 만 탈취한다면, 무용지물이 된다.
해커가 AccessToken 만 계속 가져다 쓰는 경우....
# 결론
Refresh Token의 의의는 Access Token의 수명을 단축시키는데 있다.
또한 서버에서 관리되기에, Refresh Token이 탈취되었다는 걸 인지하면 폐기시킬 수 있다.