토큰 인증
인증 방식
- 사용자 로그인
- 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.
- 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰을 서HTTP 요청 헤더에 포함시켜 전달한다.
- 서버는 전달받은 토큰을 검증하고 유효시 처리
장단점
토큰 기반 인증은 세션과는 다르게 상태 정보를 유지하지 않는다. 또한, 서버가 전달받은 토큰을 검증만 하면 되기 때문에 서버의 부담을 줄이고 서비스의 확장성을 높일 수 있다.
하지만 토큰은 세션에 비해 데이터가 무겁고 보안적인 단점이 있다.
XSS, CSRF 공격을 통해 해커에게 쉽게 탈취 당할 수 있다는 점이다.
탈취를 당하면 유효기간 동안 서버는 어찌할 방법이 없다.
이러한 보안 문제를 위해 보통은 Access Token과 Refresh Token을 함께 사용한다.
Access Token & Refresh Token
하나의 토큰 (Access Token) 만을 통한 인증 방식의 문제는 탈취당할 경우 만료까지 누구나 접근 가능해서 보안에 취약하다는 점이다.
그렇다면 유효시간을 짧게하면 되지 않을까?
이렇게 되면 사용자는 잦은 로그아웃을 경험하게 된다.
이를 해결하기 위해 Refresh Token이 같이 쓰이게 된다.
둘다 같은 토큰이지만 Access Token은 접근을 위함이고 Refresh Token은 Access Token을 발급 받기 위함이다.
최초 로그인시 둘다 발급되고 Access Token의 시간을 짧게 설정하여 만료시 긴 만료시간을 가진 Refresh Token을 이용하여 재발급 받는 형태로 최근에는 많이 사용되어지고 있다.
저장위치
access token과 refresh token에 저장 위치에도 갑론을박이 많다.
- access token은 local storage에 refresh token은 쿠키
- access token은 XSS 공격에 취약
- access token, refresh token 둘다 cookie
- CSRF 취약 XSS에선 조금 더 나음
- access token은 variable , refresh token은 쿠키에 저장.
- 공격자가 response를 읽을 수 없어 access token이 보호된다라고 한다. 빈번하게 access token이 요청될 것 같긴한데 확실히 보안이 된다면 이 방법이 좋을 것 같다. 추후 토이 프로젝트를 하면서 적용해봐야겠다.
마치며
cookie & session , token 인증에 대해서 알아봤는데 보안에 대해서는 아직 잘 몰라서 어떤 방식을 채택하는게 좋을지는 회사나 프로젝트 사정에 따라서 다를 것 같다. 다만 아직 cookie & session 방식과 토큰의 경우 access token을 변수로 처리하는 방법은 해보지 않아서 토이프로젝트를 진행하면서 경험해보고 싶다.
