JWT 어떤식으로 사용해야할지 잘모르겠습니다
조회수 454회
제가 jwt 적용했던 과정은
로그인처리 -> refresh, access token 발급 -> 화면에서 가져와서 refresh는 localstorage 에 저장 access 는 요청헤더에 적용
인증요청시 -> access token 검증 -> 검증에 통과 안되면 오류 리턴 -> 화면에서 다시 refresh을 얹어서 재 검증 -> access 재발급 후 화면에서 요청헤더에 재적용 후 이전에 요청했던 정보를 재요청함
인증과정에서 문제가 있는게 제가 구현했던 환경에서는 데이터를 불러올때 각각 컴포넌트 단위로 나눠져있기 때문에 각각 해당되는 부분에서 따로따로 요청을 보내는 상황입니다 access가 검증에 통과되지 않으면 refresh로 재검증 과정을 거치기 때문에 쓸데없이 화면에 오류를 내야하거나 200으로 떨궈서 오류코드로 분기를 태운다음 refresh로 재검증 절차거쳐야하는 건데 로그인정보에 따라 로그인 화면으로 가고 안가고 라서 중간에 그걸 판단한다고 껌뻑 거리는 현상이 있어서 더효율적인 방법이 없는지 궁금해서 질문합니다
그래서 묻고싶은건 jwt 가지고 어떤식으로 사용하고 있는지 알고싶습니다. 위에 적은 문제점은 어차피 제가 알아서 해야할 문제이라서 무시해도 됩니다
-
(•́ ✖ •̀)
알 수 없는 사용자
1 답변
-
JSON Web Token도 기본적으로 토큰이거든요. 그래서 그게 서버쪽에서 디코딩만 잘 되면 실은 그것만으로도 이미 기본 유효성 검증은 끝난 게 됩니다. 그 디코딩된 내용 payload 의 회원번호나 만료일시 같은 것에 따라서 추가 처리를 거칠 수도 있다는 거구요.
그런 차원에서, JWT라고 겁먹을 필요 없고 그냥 일반적인 액세스 토큰 기반 신원확인의 플로우를 생각하시면 됩니다. 클라이언트는 최초 단 1번 로그인 과정에서 유효한 토큰을 받고, 이후 자기 신원을 확인받아야 할 때마다 그 토큰만 내미는 겁니다. 토큰이 유효하지 않다는 응답이 돌아오면, 짤없이 로그인으로 돌아가야 하는 거구요.
핵심은 토큰의 획득 경로를 일원화해야 한다는 겁니다. 현재 구현하신 앱은 로그인 외의 다른 경로를 통해서 토큰을 갱신/재발급하는 부분이 있는가 본데, 그러지 마세요. 그냥 무적권 로그인으로 돌려보내세요. 그리고 그 대신 토큰 유효성 판별 기준을 느슨하게 잡아 주세요. (유효기간을 늘린다, 동시접속 수를 늘려준다, 토큰 안의 expire 값 대신 서버에 저장해둔 값을 이용해서 만료기간을 확인한다, expire 가 3일 이상 미래의 일이라면 토큰 갱신은 안한다 등등)
하나의 토큰을 여러 요청이 수시로 각각 따로따로 사용한다는 것 자체가 문제가 될 수는 없습니다. 그것 때문에 문제가 생긴다면 그건 인증 기법에 문제가 있다기보다는 그 적용을 잘못한 것입니다. 잘 생각해 보셔요.
댓글 입력