01. 개요
JWT로 다양한 프로젝트의 인증/인가 를 구현하며, 들었던 고민들이 있어 적어보고자 한다.
02. JWT 란?
Json Web Token의 약자로, Json 포맷을 사용하여 사용자와 토큰에 대한 정보를 저장하는 Claim 기반의 Web Token 이다. 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 전달하며, 회원 인증이나 정보 전달에 사용된다.
해당 글은 JWT에 대한 이론적 설명을 하기 보다는, JWT의 방식에 대한 의문과 고민에 대해 적는 글이므로 설명은 위 문단으로 정리하고, 이론적 부분에 대해 잘 작성된 글이 있어 추천드리며, 고민에 대해 적고자 한다.
[Server] JWT(Json Web Token)란?
02.00. 고민
보안성 측면을 고려하면서 Refresh Token을 도입하였고, 더 복잡한 고민이 들엇다.
RefreshToken을 서버에서 저장한다면, Session 저장소를 사용하지 않는다는 단점을 보완하지 못할 것 같다는 생각이 들었고,
그렇다면 클라이언트쪽에서 계속 RefreshToken을 들게하고 있을지,
그러면 RefreshToken의 Claim에 유저에 대한 정보까지 저장을 해두어야 하는지 등에 대한 고민이 들었다.
이와 관련해 아래의 링크들을 확인해보았다.
참조링크1: 리프레시토큰을 db에 넣어도 될까요?
참조링크2: JWT 혹은 OAuth2 의 refresh 토큰을 어디다 저장해야 할까?
참조링크3: [TIL] Refresh Token 저장 위치는 어디???
03. 결론
가장 중요한 부분은, Access Token과 Refresh Token의 보안성에 대한 측면이다.
일단, 두 토큰은 모두 탈취되면 안된다는 것은 기본적인 상식이다.
Front Side에 두면, 쉽게 탈취가 가능하다는 특징이 있다.
따라서, Access Token 에 대한 적절히 짧은 유효기간을 설정하고
Refresh Token은 Server Side에 저장하는 대신 session 저장소를 사용하는 방식보다는 DB에 저장하고, 1회성 Refresh Token 을 사용해야 한다고 생각했다.
이와 관련해, Redis와 같은 In-memory DB를 사용하거나 이와 관련해 보안성을 더욱 생각해 Hash 값이나 Index 값을 통한 무의미한 값 제공을 통해 RefreshToken에 대한 접근이 가능하도록 구현하는 방식을 채택할 수 도 있을 것 같다.
실제로, 클라이언트쪽에는 Access Token만 던져주고, Refresh Token은 서버단에서 관리하는 것이 추세라고 한다.
또한 Refresh Token은 Access Token의 재발급을 위한 토큰으로 사용자에 대한 정보를 담기보다는, 적절한 유효기간의 설정과, 어디에 담아 안전하게 보관할지, 어떻게 접근이 가능할지에 대한 고민이 필요한 것 같다.
하지만, 물론 이 모든 방법이 절대 정답은 아니고, 모든 방법에 취약점이나 단점이 어느정도 존재한다고 생각했고, 적절한 Trade-Off 를 생각해 프로젝트의 규모나, 편의성, 보안성 등에 대해 고려한 JWT 방식의 채택을 해야겠다.
04. 오늘의 한 문단
보안성, Trade Off
