JWT 에 대한 생각 정리

혼자서 JWT 를 구현하다가 든 여러 생각들을 정리한 글입니다.

---

1. JWT로 인증을 한 뒤 인가처리에 대한 의문점

 JWT를 구현하면서 여러 글들을 찾아보고 혼자서 생각해봤을 때 인가처리는 크게 2가지 분류로 나뉘는 것 같다.

첫 번째 방법은 payload에 유저의 고유 정보(로그인 아이디, uuid 등)를 저장해 놓고 토큰 검증 후 해당 정보를 이용하여 DB에서 유저 정보를 조회하고 인가하는 방법, 두 번째 방법은 payload에 권한과 관련된 정보를 저장하여 토큰 검증 후 해당 정보로 바로 인가처리하는 방법이다.

 개인적으로는 JWT라는 기술을 사용함에 있어서는 두 번째 방법이 더 적절하다고 생각한다. 물론 목적이나 정책에 따라 다르겠지만 JWT의 특징 중 하나인 무상태성(stateless)을 만족하기 때문이다. 서버는 토큰을 발급해주는 역할만 한 뒤 어떤 유저가 로그인 했는지에 대한 정보를 관리할 필요가 없기에 토큰이 유효한지만 체크하고 인가처리 해주면 된다고 생각한다. 하지만 여기서 생기는 문제가 JWT는 쉽게 정보를 확인할 수 있는데 권한과 관련된 정보를 그대로 노출 당했을 때 어떤 문제가 발생할지는 미지수인게 문제이다.

 해당 문제를 어떻게 해결할 수 있을까 혼자서 생각하다보니 여러 아이디어가 나왔는데

1. 권한을 payload에 저장할 때 일반적이지 않은, 내부에서 정한 규칙에 따라 만들어진 명칭을 저장한다.
2. 로그인 시 일반 유저의 경우 jwt를 반환(권한 정보 없이), 관리자인 경우 session에 저장
3. 아예 권한이 다른 프로젝트끼리 묶어서 분리하기

등등의 생각을 해봤지만 이런 생각과 관련된 글들이 없는데에는 이유가 있을거라 예상한다. ㅎ

---

2. Refresh Token을 이용한 Access Token 생성 시점

 Access Token을 이용한 인증에서 만료 시간에 따른 문제를 해결하기 위한게 Refresh Token이다. 때문에 Access Token이 만료되었을 때 Refresh Token을 이용하여 새로운 토큰을 발급해주는 것 까지는 이해를 했는데 다음에 생긴 의문점은 "그럼 새로운 토큰이 발급되는 시점은 언제인가?" 였다. 아래 그림에 추가 설명을 더해서 어떤 질문인지를 정리하겠다.

질문 요약

왼쪽 그림은 일반적으로 생각할 수 있는 토큰 재생성과 관련된 api를 구현해서 예외 발생 시 해당 api를 요청하는 방식이다. 해당 방법의 경우 만료된 토큰으로 요청했던 api를 자동으로 요청하지 않으면 UX가 매우 좋지 않을 것 같은데 어떻게 처리해야하는지 아직 생각나는 방법이 없다.

 오른쪽 그림은 백엔드 서버 내에서 토큰이 만료되었을 경우 토큰 재생성 로직을 실행하고 api의 결과값과 재생성된 토큰을 반환해주는 방법인데 이 때 어떻게 토큰 정보를 넘길지를 잘 모르겠다. api 결과 DTO에 함께 반환하자니 어떤식으로 설계해야할지 모르겠고, header에 담아서 반환하자니 프론트엔트에서 모든 api요청에 대해 항상 header도 감시하며 처리를 해야할 거같은데 프론트 쪽에서는 어떻게 처리할 수 있는 방법이 있는지 잘 모르겠다.