MSA 기반 환경에서의 인증과 인가 - 3. 토큰 탈취 대처

Session이 아닌 JWT 기반의 토큰을 사용하여 보안을 처리하는 경우 토큰 탈취에 대한 이슈에 민감하며 이에 대해 충분한 대처가 필요하다. (단지 토큰 사용 시 뿐만아니라 모든 보안 이슈는 민감하게 다뤄져야한다)

 

이번 포스팅에서는 서버 입장에서 토큰 탈취 시 어떤 식으로 보안 이슈를 최소화할 수 있을 지에 대해 고민하고 적용한 것에 대해 정리해본다.

 

---

Access Token 탈취

Access Token을 통해 직접적으로 요청에 대한 인가 처리를 수행하기 때문에 이 토큰이 탈취되면 꽤나 치명적이다.

또한 서버에서는 왠만하면 인증(로그인)이 완료되면 Access Token을 발급은 해주지만, 발급된 Access Token의 유효성을 관리하기 위해 DB에 저장하지 않을 것이다.

(사용자 보안에 대해 하나하나 모든 것을 제어해야하는 경우 Access Token을 DB에 저장할 순 있겠지만 개인적으로 이정도면 차라리 세션을 사용하는 것이 날 것 같다 👀)

 

그렇기 때문에 한 번 발급된 Access Token은 서버에서 만료를 시킬 수가 없다를 전제로하면 이에 대한 대처는

Access Token Payload에는 되도록 개인정보를 담지 않는다

Payload는 secret이 없더라도 Access Token을 통해 값을 빼올 수 있다.

(https://jwt.io/#debugger-io 에서도 간단하게 확인할 수 있다)

그렇기 때문에 탈취가 되더라도 해당 Access Token을 발급 받은 계정의 개인정보를 되도록 담지 않도록 한다.

 

혹시라도 탈취되어 외부에 노출되더라도 문제가 되지 않을만한 값들(e.g. User ID 값)만을 담도록한다.

 

Access Token의 유효 시간을 짧게 갖도록 한다

Access Token 사용 시 클래식한 탈취 시 대비책이지만 그 만큼 의미가 있다.

Access Token이 탈취된다 하더라도 이를 사용할 수 없게 사용할 수 있는 시간 자체를 짧게 줄인다.

이렇게 함으로써 Access Token을 탈취를 하더라도 이를 사용할 수 있는 여지를 최소화 시키도록 한다.

 

다만 Access Token의 유효 시간이 짧아질 수록 토큰을 Refresh 하는 주기 또한 짧아진다.

이는 추가적인 비용이 드는 부분이지만, 이 비용이 토큰 탈취로 인해 개인정보 노출 및 기타 피해로 이어지는 피해에 대한 보상 및 서비스에 대한 부정적인 이미지보다는 훨씬 싸게 먹히지 않을까 싶다.

 

Refresh Token 탈취

Refresh Token은 이를 직접적으로 사용하여 인가 처리를 하진 않지만 이를 통해 새로운 Access Token을 발급받을 수 있고 유효기간이 길기 때문에 탈취될 경우 이를 Access Token에 비해 사용되기가 좋다.

때문에 Refresh Token 같은 경우 DB에 저장하여 발급된 Refresh Token을 만료시킬 수 있는 방법을 두는게 좋다.

이렇게 하면 Refresh Token을 탈취하였다 하더라도 해당 Refresh Token을 사용하여 다시 Access Token을 발급받을 수 있는 방법이 없어지게 되어 해당 토큰이 무용지물이 된다.

 

이를 위해서 사용자가 자신의 계정이 다른 곳에서 사용된다고 느끼는 경우 발급받은 Refresh Token을 만료시키는 기능이 필요하다.

(물론 'Refresh Token 만료시키기'와 같은 기능이 아니라 '내 계정이 다른 곳에서 사용되는 것 같아요'와 같은 비기술적인 용어로 변경해야겠지만)

예를 들면 본인 확인 등과 같이 해당 계정 소유를 증명할 수 있는 수단등을 통해 만료시키거나, 비밀번호 변경 시 기존에 발급한 Refresh Token을 만료하는 등, 발급된 Refresh Token을 만료시켜줄 수 있는 수단을 사용자에게 제공해줘야할 것이다.