stateless 인증과 jwt, 그리고 위변조에 대한 이야기

항상 개발을 하다보면, 인증 처리 방식에 대한 고민이 많다.

 

모바일이 보편화 되고, SPA 웹앱으로 개발하는 일도 많다보니, 세션을 사용하는 일은 거의 없다.

 

대세의 jwt를 쓰면서도, 자유롭게 설정 가능한 payload는 가끔 또 고민의 고민을 낳고 있다.

 

그렇게 사용하게 된 jwt의 장,단점에 대해 이야기를 해본다.

 

stateless 인증으로 jwt를 채택하여 얻게 되는 장점은 많다.

서버사이드 세션관리가 필요없으므로, scale-out하기에 용이하다.

단순하고 직관적이면서도, 위변조는 안된다.

 

하지만 , payload가 노출은 되므로, 신경 쓸 부분이 많다.

예를 들어 payload에 중요한 정보를 넣어서는 안되고

탈취에는 취약하므로, 방지책도 고려해야 한다.

 

또한, Issuer나 Audience, Iat 등등 값을 잘 사용하는 것은 까다롭다.

 

위에서 말했든 탈취가 쉽다는 점이 언제나 마음에 걸린다. (http 요청 헤더에 떡하니 들어있으니..)

토큰의 유효시간을 길게 만들면, 개발은 변하겠지만, 탈취한 토큰을 사용한 해킹우려가 있다.

 

고려해볼만한 사항으로

토큰 발급 시점의 사용자 ip를 payload에 넣거나, db에 넣어서, ip가 변경되면 해당 토큰을 불허하는 방법이 있다.

하지만, 모바일 환경에선 사용자 ip가 가변인 경우가 많아, 불가능 하다.

모바일에서 ip 대신 device 정보를 사용하여, device 변경을 탐지하는 것도 가능하다.

(device 대한 고유식별자 이슈는 별개의 문제이므로, 이글에서는 다루지 않는다.)

 

ip든 device정보든 여전히 찜찜하다.

 

결국 토큰의 유효시간을 짧게 줄여야, 좀 더 안정해진다.

긴 유효시간을 지닌 토큰, 예를 덜어 30일짜리 토큰이라면, 공격자가 토큰을 탈취하였을시, 사용할 수 있는 기간 또한 길어지므로, 위험해진다. 심지어 유효시간도 토큰에 적혀있으니, 얼마나 편리한가

 

토큰 유효시간을 짧게하여, 계속 로그인상태가 풀린다면 사용자는 불편하다.

(30분마다 재로그인을 해야하는 어플이 있다면, 얼마나 불편한가?)

 

이럴 경우 사용하는 것이 Refresh Token이다.

(OAuth2의 그것과 유사하다. Access Token보단 긴 유효시간을 지니고, Access Token이 만료되었을 때, 재발급하는 용도)

 

Refresh Token은 payload가 없는 단순 hash값 등로 만들어지므로, 탈취가 되어도, 문제가 되지 않는다.

아니다. 이또한 탈취에는 방법이 없다.

일반 API들보다 요청횟수가 적어서, 탈취될 확률이 낮을뿐,

탈취되면, Access Token을 계속 발급받을 수 있는 대단히 위험한 일이 발생한다.

그래서 추가정보를 또 받아서, 검증에 검증을 하는것이 현실이다.

 

탈취를 막기 위해, https사용을 권장되는 것이고, 그럼에도 불구하고 2FA(2차인증)까지 사용하는 것

 

보안에는 끝이 없다.