jwt에 대해 이렇게 이해하고 있는데 맞을까요..?

Question

세션으로만 하다가 최근에 jwt를 도입하려고 독학중인데요 일단 jwt를 만들고 검증하는건 만들었습니다예전엔 세션에 데이터를 저장해서 검증했다면, 이번엔 세션에 데이터가 없어도 로컬스토리지에 저장된 jwt를 헤더에 넣음으로서 체크를 할 수 있게 되었는데요여기에 jwt의 기간을 짧게 잡고, 리프레시 토큰을 추가하려고 합니다. 리프레시 토큰도 비슷한 방식으로 만들어서 로컬 스토리지에 저장하고 있고 엑세스 토큰은 유저 아이디로, 리프레시 토큰은 무작위 문자를 이용해서 하고 있습니다.사용자가 로그인 - 엑세스 토큰(1시간) &#43; 리프레시 토큰(1개월) 발급 및 리프레시 토큰을 특정 할 값을 db에 저장데이터 요청 - 엑세스 토큰을 서버에 건내서 검증하고 데이터를 받음엑세스 토큰 만료시서버가 엑세스 토큰 검증중 만료된걸 확인하고 만료 메시지를 보냄프론트에서는 리프레시 토큰을 서버에 전달(또는 3-5번 대신, 요청시 엑세스&#43;리프레시를 항상 같이 보내서 시간에 따라 연장시킴)서버는 리프레시 토큰의 정합여부(db등)을 확인새로운 엑세스 토큰 &#43; 리프레시 토큰 발급2번~7번 반복이렇게 이해하고 있습니다리프레시 토큰은 엑세스 토큰이 만료되었을때만 검증해서 사용하고 엑세스 토큰이 발급 될 때 리프레시 토큰을 다시 만들어서 저장엑세스 토큰은 기간이 짧으니 누가 가져가도 비교적 피해가 적고 리프레시 토큰은 로그인할때 새로 등록하며 db에 저장된 다른 항목들은 지워버리고 엑세스 토큰 만료시에만 검증리프레시 토큰을 탈취당하면, 디비에서 지워버리는걸로 사용 못하게 막을 수 있다는건데... 그럼 탈취당한걸 어떻게 구분하는지는 또 궁금하군요-_- 그리고 여러기기에서 로그인할때 어떻게 대응하는지도..?그냥 세션에다가 최소 정보만 저장해서 쓰는 편할거같기도하고.. 복잡하군요ㅠㅠ

kotliner · Answer

(또는 3-5번 대신, 요청시 엑세스+리프레시를 항상 같이 보내서 시간에 따라 연장시킴)이러면 refresh token을 만드는 이유가 없어집니다. refresh token은 access token에 비해 더 안전하게 보관되고 더 적게 노출되어야합니다. 탈취당한걸 감지하기보다는 보통 다른 기기에서 로그인될때 기존 refresh token과 access token을 만료시키는 방식으로 1 디바이스 정책을 구현가능합니다. 여러 디바이스 정책을 허용할때에는 그냥 서버에서 서명한 올바른 jwt면 다 허용해주면 됩니다.

jwt에 대해 이렇게 이해하고 있는데 맞을까요..?

1개의 답변

Q&A 목록