이번 글은 Web에서 Access Token, Refresh Token 사용 및 관리에 대해 정리했습니다.
1.로그인 인증 성공 후
AccessToken
전달 받은 Access Token은 메모리에 저장합니다. React 의 경우 Context, Redux 등에 저장합니다 . 메모리에 저장한다는 것은 페이지를 새로고침했을 때 Access Token이 메모리에서 날아간다는 의미이고 Access Token 이 유출되었을 때 Access Token의 생명주기를 최소화하여 리스크를 최소화하기 위함입니다. 새로고침해서 날아간 Acceess Token은 Refresh Token으로 갱신합니다.
Refresh Token
Refresh Token은 Cookioe로 발급 받습니다. Local Storage는 사용하지 않는 이유는 XSS공격에 취약하기 때문이고 Cookie는 HTTP Only와 Secure 등의 보안 옵션등이 있어 Local Storage 보다 안전합니다.
이 글 후반부에 고려되어야할 보안 옵션등을 정리하였습니다.
2. Access Token 사용
Access Token은 조회 API 호출할 때 Header에 담아서 보내고 서버로 부터 조회 결과를 받습니다. 이때 올바르지 않은 토큰일 경우 401 HTTP Code 등을 전달 받습니다.
3. Access Token 만료 또는 새로고침
Access Token 만료 또는 새로고침을 할때 Access Token 갱신 API를 호출합니다. Cookie에 Refresh Token이 있기 때문에 Refresh Token을 헤더에 담아서 전송하지 않아도 됩니다.
4. Refresh Token 만료
Refresh Token 만료 시, 절절한 HTTP Code를 전달 받고 로그인 페이지로 이동합니다. 사용자는 다시 로그인 인증을 통해 Token을 새로 발급 받습니다. 필요에 따라 Access Token을 갱신할 때 Refresh Token의 만료 시간을 같이 갱신할 수 있습니다.
지금까지 Access Token과 Refresh Token 사용과 관리에 대해 알아보았습니다. 이제 가장 중요한 보안 옵션들을 알아보겠습니다.
Cookie 보안
HTTP Only
Cookie를 HTTP 통신에서만 사용될 수 있도록하는 옵션입니다. 설정을 하지 않을 경우 XSS 공격을 통해 쿠키에 쉽게 접근할 수 있습니다. Cookie에 Refresh Token을 저장한다면 필수로 사용합니다.
Secure
Secure 설정이 활성화되면 HTTPS 를 통해서만 Cookie가 발급됩니다. 필수로 사용합니다.
SameSite
Strict 설정으로 같은 사이트에서만 쿠키를 사용할 수 있습니다. abc.mediume.com 처럼 서브도메인도 포함하여 동작합니다. Strict 설정을 권장합니다.
Referrer
Referrer 통해 웹사이트 방문 정보를 서버에서 확인할 수 있습니다. API 호출정보에서 Referrer 를 확인해서 허용하지 않은 도메인 일 경우 적절한 HTTP Code가 리턴되도록 합니다.
그외 고려해야할 것들
- Refresh Token 이나 Access Token 이 유출될 경우를 대비해서 Refresh Token은 언제든지 폐기될 수 있어야 합니다.
- Token의 Payload는 최소한의 정보로 구성되어야 합니다. 중요한 정보는 Payload에 포함되어 있으면 안되며 Payload의 내용이 많아질수록 Token의 크기는 많이 무거워집니다. Token은 최대한 가볍게 만들어줍니다.
Web에서 고려해야할 것들
- 위에서 애기했듯이 Access Token은 메모리에 저장합니다. 새로고침할 경우 Access Token 갱신됩니다. 이 방법은 Access Token이 유출되었을 경우 리스크를 최소화하기 위해서입니다.
2. Access Token이 만료되는 시점에서 동시에 API호출이 여러번 생긴다면Access Token 갱신 API 여러번 호출되지 않도록 주의 해야합니다. Promise 를 적절히 사용하거나 Queue를 사용하여 AccessToken 갱신 API가 동시에 여러번 호출되지 않도록 합니다.
여기까지 Access Token과 Refresh Token에 대해서 알아보았습니다.
