Access Token 클라이언트 보안전략

1. Access Token 만 사용 #

사용자가 로그인 할 때 클라이언트에게 AccessToken을 발급한다. 이때 AccessToken은 서버에서 관리할 필요가 없고 메모리상에서 미리 정의 된 비밀키를 이용해서 AccessToeken의 유효성을 검증한다.

짧은 만료 시간으로 설정 (30분 내외) #

장점
- 기기나 AccessToken이 탈취되더라도 빠르게 만료됩니다.

단점
- 사용자는 자주 로그인을 해서 인증 받아야한다. 한 사용자가 오랫동안 사용하는 서비스일경우 서비스를 이용하다 도중에 인증이 만료되어 다시 로그인해야하는 불편함을 겪는다.

긴 만료 시간으로 설정(2주 에서 한달) #

장점
- 사용자가 로그인을 자주 할 필요가 없어서 편하다
단점
- 기기나 AccessToken이 탈취되면 오랫동안 제약 없이 사용한다.

Sliding Sessions / AccessToken #

유효한 AccessToken을 가지 클라이언트의 요청에대해서 서버가 새로운 AccessToken을 발급해주는 방법을 사용한다. ( 매요청마다 AccessToken을 발급하다보면 글작성시 시간이 오래걸려 토큰이 만료되고 글작성하던게 다 날아갈수있다... 이것을 방지 하기위해서 AccessToken은 글작성 시작을 할 때도 발급하거나, 쇼핑몰에서 장바구니에 아이템을 담을 때도 새로 발급해주는것도 괜찮은 전략이다)

장점
- 사용자가 로그인을 자주 할 필요가 없다
- 글을 작성하거나 결제를 하는 등의 세션 유지가 필요한 순간에 세션이 만료되는 문제를 방지 할 수 있다.

단점
- 접속이 주로 단발성으로 이루어지는 서비스의 경우 Sliding Sessions 전략은 미비
- 긴 만료 시간을 갖는 AccessToken을 사용하는 경우 로그인을 전혀 하지 않아도 된다. ( 매번 accessToken을 받는 쿼리 자체가 낭비된다.)

AccessToken / RefreshToken #

`사용자가 로그인을 할 때 AccessToken과 RefreshToken을 함께 발급한다. 이 때 ResfreshToken은 AccessToken보다 긴 유효시간을 부여한다.

클라이언트는 AccessToken으로 요청을 하다. 만료되었다는 오류를 받으면 클라이언트 DB에서 저장해 두었던 RefreshToken으로 다시 한번 요청하고 AccessToken을 재발급 받는다. ( RefreshToken도 만료되었다는 오류를 받으면 로그인을 폼으로 보내서 다시한번 인증을 받는다)

AccessToken같은 경우 서버에 저장할 필요는 없다. RefreshToken은 서버는 JWT 스펙에 포함되지는 않지만 빠른 인증 처리를 장점으로 내세운다. (refreshToken은 서버에서 따로 저장을 하고 있다. 따라서 만료시키는것이 가능)`

장점
- 짧은 만료 기간을 사용 할 수 있기 때문에 AccessToken이 탈취되더라도 다소 안전
- 사용자가 로그인을 자주할 필요 없다.
- RefreshToken에 대한 만료를 강제로 설정 할 수 있다.

단점
- 클라이언트 AccessToeken의 만료에 대해 연장 요청을 구현해야한다.
- 인증 만료 기간의 자동 연장이 불가능
- 서버에 별도의 storage를 만들어야 합니다.

Sliding Sessions / AccessToken / RefershToken #

`위의 Sliding Sessions 전략이 AccessToken 의 완료시키는 전략이었다면 지금 전략은 RefreshToken의 만료 기간을 늘려주는 전략입니다.

RefreshToken의 만료기간이 늘어나기 때문에 AccesToken / SlidingSessions 전략처럼 빈번하게 만료기간을 늘릴 필요가 없다. RefreshToken 기간을 늘려주기 때문에 accessToken의 유효성이 짧아도 상관없다.

문제점으로 RefreshToken 자체가 탈취될 위험성인데 , 핸드폰이 탈취되거나 비밀번호가 변경되는 경우 RefreshToken의 만료시키는 처리를 추가해야한다.`

장점
- RefreshToekn 만료 기간에 대한 제약을 받지 않는다.
- 글을 작성하거 세션을 유지해야할 필요가 있는 순간에도 만료문제를 방지 가능

단점
- 서버에서 강제로 RefreshToken을 만료하지 않는 한 지속적으로 사용기 가능하다.
- 보안 강화가 필요하다.

AccessToken 저장 위치는 어디로? #

Cookie Header에 저장 #

장점
- HttpOnlty 옵션과 Secure 옵션을 통해서 XSS 공격을 방어할 수 있다.
- javascript가 쿠키를 조작하는 것을 막아 준다(사용자의 토큰값이 변경될 염렬를 하지 않아도 된다.)

단점
- CSRF에 대한 공격을 막을 수 없다.

Authorization Header에 저장 #

장점
- Oauth2.0에 사용하는 형식 XSS공격과 CSRF 공격에 대해서도 안전하다.
단점
- 결국 이 Token은 어디에다가 저장하느냐...? (이것을 어떻게 하냐에 따라 보안이 달라진다.)

결론 #

이러니 저러니 해도 편의성이 띄어날수록 보안이 취약해지고 인증 절차가 까다롭고 불편할수록 보안성이 올라가는 것같다. 지금으로서는 AccessToken 과 RefreshToken을 이용해서 운영하는것이 가장 합리적으로 보인다. 이유는 accessToken 만료기간을 늘리면 늘릴수록 편안?? 은 하겠지만 토큰의 로그가 그대로 노출 되기때문에 공격자가 토큰을 탈취할 가능성이 높다.. 하지만 토큰의 만료기간이 짧으면 탈취되었다 할지라도 아무것도 할 수가 없다. 서버쪽에서도 AccessToken은 유효기간이 짧을수록 유효하다.