[JWT] jwt Access/Refresh 토큰을 사용해보면서 의문스러운 점이 있습니다

Question

스프링부트 기반으로 jwt를 만들어보고 있는데요,다들 아시다시피 jwt access 토큰이 탈취되면(당연히 탈취 안되겠끔 고려해야겠지만) api 접근이 가능하기 때문에 refresh 토큰을 검증하잖아요?access 토큰 만료 -> DB의 refresh 토큰 검증 ─> refresh 토큰이 유효하면 access 토큰 새로 발급 └─> refresh 토큰이 만료가 됬으면 로그인 창으로 이동(저는 access 토큰이 만료되면 DB에 저장된 refresh 토큰을 조회해서 검증하고 다시 발급하도록 했습니다. 혹시 잘못된 부분이 있으면 피드백 부탁드려요)제가 의문을 가진 부분은, 탈취한 access 토큰이 만료가 됬다하더라도 refresh 토큰 검증을 통해 access 토큰을 새로 발급해주게 되서 refresh 토큰이 만료 될 때까지 새 access토큰을 발급받아 계속 사용할 수 있다고 생각되서 개인적으로는 안전하지 않은것 아닌가 싶습니다.혹시 제가 놓친 부분이 있거나, 제가 생각한 방식에 보완점을 추가해야하는 것이 있을까요??

WRITE_IN_DART✎ · Answer

맞습니다. 다만 접속하는 환경은 어느 정도 신뢰 가능하다는게 전제되지 않는다면 다른 방법을 써도 크게 달라지지 않을 겁니다. OAuth의 경우 해당 부분에 대하여 토큰이 접근 가능한 스코프를 지정함으로서 보완합니다. JWT에도 subject였던가가 있었던거 같은데 그 부분이 어느정도 도움이 되지 않을까 합니다.

남해밤바다 · Answer

&#64;WRITE_IN_GO 님, 답변 감사합니다말씀하신 scope에 대해 제가 알고 있는 부분을 말씀드리자면, jwt 토큰에 스코프를 지정하게 되면 claims(속성 정보)Set에 지정됩니다. JWT.create() .withHeader(new HashMap<>() {{ put(&#34;typ&#34;, &#34;JWT&#34;); }}) .withExpiresAt(expiration) .withSubject(USER_ID) .withClaim(&#34;nickName&#34;, NAMW) .withClaim(&#34;IssuedDate&#34;, DATE_TIME)) .sign(Algorithm.HMAC512(SECRET_KEY));그런데 이 jwt의 claims은 누구나 파싱이 가능해 값을 들여다 볼 수 있어서 scope를 지정한다 하더라도 보안성을 높여주지는 않을 것 같습니다...아 참고로, 스프링부트에서 사용하는 jwt 관련 라이브러리는 'com.auth0'의 'java-jwt'입니다.

장독깨기 · Answer

클라이언트 : 액세스토큰으로 자원액세스 요청서버 : 액세스 토큰 유효성 및 만료기간 체크 후 유효하지 않으면 invalidation 반환클라이언트 : 리프레시 토큰으로 액세스 토큰 요청서버 : 리프레시 토큰 검증 후 유효하면 액세스토큰과 리프레시 토큰 재 생성해서 반환클라이언트 : 액세스토큰으로 자원엑세스 요청 대략 이런 흐름인데요.. 액세스토큰 만료 시 DB의 리프레시 토큰 검증?&#61;> 이 부분이 이상합니다. 뭘 기준으로 DB에 있는 리프레시 토큰을 검증하는지 모르겠네요..혹, 만료된 액세스토큰과 매핑 된 리프레시 토큰을 검증하나요? 리프레시 토큰은 액세스토큰이 유효하지 않을 때,다시 인증(로그인) 절차를 거치지 않고,액세스 토큰을 발급받기 위해 있습니다.그리고, 이 리프레시 토큰도 유효하지 않으면 인증(로그인) 절차를 거처야 하구요.. 액세스토큰과 리프레시 토큰은 둘다 클라이언트가 가지고 있어야 하는데뭔가 좀 이상합니다.

남해밤바다 · Answer

&#64;장독깨기 님개발 초기에 제가 구글링하면서 조사한 바로는 장독깨기 님 말씀처럼 클라이언트가 Access/Refresh 토큰을 쿠키에 저장해 관리하여 jwt 검증 로직을 개발하는 방법도 있더라구요다른 방법으로는 Refresh 토큰은 외부에 노출이 되어서는 안된다는 전제를 두어 Redis나 DB 등을 이용해 서버 측에서 Refresh 토큰을 관리해서 jwt를 검증하는 케이스도 있더라구요그래서 저는 후자의 케이스에서 클라이언트가 로그인을 (성공적으로) 수행했을 때 Access/Refresh 토큰 동시에 생성하거나 기존에 저장되어있는 Refresh 토큰을 검증해서 클라이언트에게 Access 토큰을 전달하는 방식을 채택했습니다.후자는 굳이 DB에 저장해서 관리할 필요가 있냐는 이야기도 있지만, 어떤 방법이든 간에 제가 물어보려는 의도와는 크게 다르지 않은 것 같아요

장독깨기 · Answer

음.. 세션 인증 대신 사용하는걸로 보이는군요..그러면, 리플레시 토큰은 사용할 필요 없어보입니다..질문에 있는 님의 로직을 보더라도결국 토큰의 만료기간은 리플레시 토큰의 만료기간이 됩니다.액세스토큰의 만료기간을 조정하면 될 일입니다.그리고, 뭘 기준으로 DB에 있는 리플레시 토큰을 조회해서 검증하는지 모르겠지만,DB를 조회한다는거 자체가 JWT 의 목적에도 부합하지 않는걸로 보입니다. 그리고, 리플레시 토큰은 이름에서도 알 수 있듯이 그 목적이 있어 클라이언트에서 관리해야하는 걸로 알고 있습니다만,님이 또 알아보신바 그런 사례가 있다하니 저도 뭐가 뭔지 모르겠습니다. ㅋ시간이 되면 천천히 다시 알아봐야겠습니다.

남해밤바다 · Answer

&#64;장독깨기 님 답변 감사합니다.말씀하신대로 저도 DB에 Refresh 토큰을 관리하는 것은 비효율적이라 생각합니다그렇지만 refresh를 외부에게 알려져서는 안되는 토큰으로 취급해서 클라이언트에서 관리시키게 하지 않는다고 하네요.장독깨기 님이 제시하신 방법에서 클라이언트 측에서 Access/Refresh 토큰 모두 관리한다고 하면서 리프레시도 탈취당했다는 가정 하에, 계정 정보는 얻지 못하더라도 외부인이 Refresh 토큰이 만료 되기 전까지 자신의 api 자원을 이용하게 될 수 있는 무서운(?) 상황이 될 수도 있지 않을까요? (제가 찾아본 바로는 Cookie에 httpOnly 또는 Secured 옵션을 설정하고 저장하면 된다고 하던데...) 그래서 DB 대신 Redis라는 것을 통해 캐시 메모리를 이용하는 것 같습니다 제가 초보 개발자라 Redis는 이름만 들어봤지, 이번 기회에 한번 공부해서 사용해볼까 고민 중입니다장독깨기 님의 의견을 묻고 싶습니다!

장독깨기 · Answer

좀 길게 댓글을 달았는데 다 날라가 버렸네요..ㅋ오키는 이 부분 좀 개선해야 되지 싶습니다.ㅎ 답변 간단하게 달겠습니다.JWT 목적을 한번 생각해보셨으면 좋겠습니다.JWT를 사용하는데 서버 자원(DB,Redis,..)을 액세스 하면 사용할 이유가 없어집니다.JWT를 세션인증 대안으로 사용한다면 리프레시 토큰 필요없어보입니다..리프레시 토큰은 OAuth 표준으로 있는 내용이며,인증을 너무 브라우저에 한정해서 생각하시는게 아닌가 하는 생각이 듭니다.

남해밤바다 · Answer

넵 우선 좀더 공부해보도록 해보겠습니다!

[JWT] jwt Access/Refresh 토큰을 사용해보면서 의문스러운 점이 있습니다

8개의 답변

#oauth 목록