[인증] Access Token, Refresh Token

앞서 작성한 글 에서, JWT(JSON Web Token)의 단점 중, 한 번 발급된 경우 유효기간이 지날 때까지 계속 사용할 수 있기 때문에 만약 토큰이 악의적으로 활용될 경우 Access Token의 유효기간이 다 될 때까지 정보가 계속 털릴 수 있다는 점을 얘기했다. 그리고 이러한 JWT의 문제점을, Access Token의 유효기간을 줄이고, Refresh Token이라는 새로운 토큰을 발급함으로써 해결할 수 있다고 하였다. 그래서, 각자는 정확히 무엇인지, 그리고 위의 문제점을 어떻게 해결하는 것인지를 알아보고자 한다.

 

Refresh Token

상술했듯 Access Token(JWT)를 통한 인증 방식의 문제는, 제3자에게 탈취당할 경우 유효기간이 끝날 때까지 계속 정보가 털릴 수 있다는 점이다. 그렇다고 해서 Access Token의 유효기간을 막 줄이자니, 그만큼 사용자가 로그인을 자주 해서 Token을 다시 발급받아야 하므로 여간 불편하고 귀찮은 일이 아닐 수 없다. 이런 상황에서, "유효기간을 짧게 하면서 보안을 강화할 수 있는 방법이 있지 않을까?" 라는 질문의 해답을 Refresh Token이 제공한다.

 

Refresh Token은 Access Token과 똑같은 형태의 JWT이다. 처음 로그인했을 때, Access Token과 동시에 발급이 되며, Access Token의 유효기간이 지났을 때 새롭게 발급해주는 역할을 한다.

예를 들어 Access Token의 유효기간은 1시간이고, Refresh Token의 유효기간은 2주라고 하자. 이 때에 1시간이 지났더라도 2주가 되기 전까지는 Access Token을 계속 새롭게 발급받을 수 있다.

• Access Token의 보안 취약성은 여전히 존재하지만, 유효기간이 짧기 때문에 좀 더 안전하게 사용할 수 있게 되었다는 뜻이다.
• Refresh Token은 유효기간이 지나면 다시 발급받아야 하고, 이 또한 탈취의 위험성이 있기 때문에 기간을 적절하게(통상적으로 2주) 지정해야 한다.

Access Token + Refresh Token 인증 과정

출처: https://tansfil.tistory.com/59?category=475681

(Access Token만을 사용한 JWT 인증방식에서 좀 더 복잡해졌다. 그렇지만, Access Token의 약점을 Refresh Token이 보완해주므로 사용하기를 권장한다.)

1. 사용자가 ID, PW를 통해 로그인한다.

2. 서버에서는 회원 DB에서 값을 비교한다. (보통 PW는 일반적으로 암호화됨)

3, 4. 로그인이 완료되면 Access Token과 함께 Refresh Token이 발급된다. 회원 DB에는 일반적으로 Refresh Token이 저장된다.

5. 사용자가 Refresh Token을 안전한 장소에 보관한 후, Access Token을 헤더에 실어 요청을 보낸다.

6. Access Token을 검증한다.

7. 이에 맞는 요청 데이터를 보낸다.

8. Access Token의 유효기간이 만료되었을 경우

9. 다시 한 번 사용자가 Access Token을 헤더에 실어 요청을 보낸다.

10, 11: 서버가 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.

(이 때, Access Token이 만료될 때마다 9~11의 과정을 다시 할 필요는 없다. 프론트엔드 단에서 Access Token의 Payload를 통해 유효기간을 알 수 있으므로, API 요청 전에 토큰이 만료되었다면 재발급 요청을 할 수 있다.)

12. 사용자는 Refresh Token과 함께 Access Token을 서버로 보내며 Access Token 발급 요청을 한다.

13. 서버에서는 우선 Access Token이 조작되었는지 확인한 후, 사용자가 보낸 Refresh Token과 DB에 저장되어있는 Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 Access Token을 새로 발급한다.

14. 사용자는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행한다.

 

장점

• 기존의 Access Token만 있는 상황과 비교했을 때 훨씬 안전하다.

단점

1. 구현이 복잡하다. 검증 프로세스가 길어졌기 때문에 서버 단과 프론트엔드 단 모두에서 구현이 어려워진다.
2. Access Token이 만료될 때마다 재발급 요청을 해야되는데, 이 과정에서 생기는 HTTP 요청 횟수가 많아진다. 이는 서버의 자원 낭비로 귀결된다.

OAuth가 Access Token + Refresh Token의 방식으로 이뤄진다. 이제 OAuth에 대해 알아보자.

 

출처 및 참조

https://tansfil.tistory.com/59?category=475681