현대의 애플리케이션은 일반적으로 로그인을 거친 후 접근 권한을 부여받습니다. 부여받은 접근 권한 token을 저장하고 api요청할 때마다 token을 빈번히 전달하다 보면 보안에 많이 취약해집니다. 그러기 위해 token의 유효기간을 짧게 하면 웹사이트를 이용하는 과정에서 계속적인 로그인을 필요로 할 수 있어 불편함을 줄 수 있습니다. 이를 해결하기 위해 access token과 refresh token을 나눠서 설계하면 보안성을 높일 수 있습니다.
Access Token
Access token은 사용자 인증 이후, 애플리케이션에 접근하기 위한 인증 자격을 부여 받는 토큰입니다. Access token은 일반적으로 일정 시간이 지나면 만료됩니다. 이러한 만료 시간을 설정함으로써, 보안을 강화하고 시스템의 안정성을 유지할 수 있습니다.
Refresh Token
Refresh token은 access token의 만료시간이 지나면, 새로운 access token을 얻기 위한 인증 자격을 부여받는 토큰입니다. Refresh token은 일반적으로 access token과 함께 발급됩니다. Refresh token을 이용하면, 사용자는 새로운 access token을 발급받을 수 있으며, 이를 통해 지속적으로 애플리케이션에 접근할 수 있습니다.
두 개의 Token을 사용하는 이유
안그래도 관리하기 힘든 token을 굳이 두 개로 구분해서 관리하는 이유가 있습니다. Access token 같은 경우 빈번히 사용되는 대신 유효기간이 짧아서 해커들이 Access Token을 탈취하여 사용할 수 있는 시간을 최소화할 수 있습니다.
반면에, Refresh Token은 Access Token을 발급하는 용도로만 사용되기 때문에, Access Token보다는 사용 빈도가 적습니다. 따라서 Refresh Token의 만료 시간을 상대적으로 길게 설정하여, 해커들의 Refresh Token 탈취 시도를 최소화하고 보안성을 높일 수 있습니다.
Token 저장 위치
그렇다면 Token을 저장하는 위치는 어디가 좋을까요?
아무래도 탈취당해도 짧은 유효기간덕분에 Access token 같은 경우 웹 브라우저 저장소(local storage, sesstion storage), 쿠키에 저장을 해놓습니다.
하지만 Refresh Token을 탈취당하는건 비교적 긴 유효기간을 가지고 있기 때문에 보안상 위험합니다. XSS(Cross-site scripting)와 같은 공격으로부터 보호하기 위해 쿠키 속성 중 HTTP Only를 이용해서 보안을 강화할 수 있습니다.
HTTP Only 속성은 웹 쿠키의 속성 중 하나로, 클라이언트 측에서 쿠키에 접근할 수 없도록 하는 보안 기능입니다. 이를 이용하여 Cross-site scripting(XSS)과 같은 공격으로부터 쿠키를 보호할 수 있습니다.
댓글