jwt 토큰의 구현이니 원리니 refreshToken이니에 관한건 다 집어치우고
최근 관련해서 굉장히 부끄러운 상황 이 일어나 다시는 그러지 말자고 생각해 남겨본다.
JWT 토큰을 store로 생각하지 말자
jwt 토큰에는 claim을 담을 수 있다.
참조 : https://velopert.com/2389
토큰의 담긴 정보는 compact 해야한다.
나의 큰 오해는 jwt토큰을 하나의 Cookie 라고 생각해
토큰 내부의 sub에다가 정보를 담아 프론트에 넘겨주었다.
실제 구현했었던 jwt 토큰 생성 메서드
물론 프론트 개발자분과 협의했던 상황이지만 claim 안에
회원pk와 상점pk를 담았던 경우이다.
사실 회원pk의 경우 토큰의 검증을 위해 담아서 권한인증을 해야하기에
필요한 상황이라고 봤었다.
하지만 상점pk의 경우 조금 애매한 상황이 생기는데
shopRepository.findByMemberId(member.getId()).orElse(null);일단 jwt토큰은 만료되기 전까지 강제로 로그아웃 후 로그인을 하지 않는 이상 변하지 않는 값이 된다.
이 프로젝트는 한명의 회원이 하나의 상점을 가질 수 있고 상점을 생성하지 않을 수도 있다.
즉, 상점을 가지지 않은 회원이 로그인이 된 후 상점을 생성했을 경우에는 jwt토큰에 상점의 값이 담겨있지 않는 상황이 발생하였다.
회원이 보유한 상점을 조회하는 api를 만드는게 당연했지만 짧은 생각을 하여 스스로 버그를 만든 상황이다.
제목으로 지정한 'JWT(Json Web Token) 내부에는 무엇이 들어가야하는가?'는 사실 2가지의 의미를 생각했다.
JWT 에는 '무엇'이 들어가야 하는가? 와 말그대로
JWT 에는 무엇이 들어가야하나 의 의미를 담았다.
하나의 시행착오라고 넘기겠지만 다시는 일어나서는 안될 실수라고 생각하여 마무리를 정리 후에 글을 마친다.
마무리
-
jwt토큰은 cookie의 역할을 부여해선 안된다.
-
jwt는 권한인증을 위한 수단으로 사용하여야 하며 최대한 filter 에서 검증 후 service layer까지 내려오면 안된다.
-
jwt 토큰 안에는 '변수값'을 넣어선 안된다.
