개인적으로 진행하는 프로젝트에 로그인 보안에 jwt 을 이용하려고 하고 있다.
이 때 jwt 사용 시 refresh token 은 어디서 관리해야 할까에 대해서 굉장히 많은 고민을 했다.
refresh token 은 어디서 관리해야 할까?
우선 토큰 사용의 목적은 stateless 하게 가져가기 위함이다. 세션을 사용한다면 매 요청마다 redis 든 DB 든 어디선가 세션 정보를 저장하고 있고, 이 세션이 올바른지 체크를 하게 된다.
이 때 토큰을 사용 시 토큰이 유효한가? 에 대해서만 체크하면 되는데 이 때 access token 과 refresh token 으로 관리를 하게 된다면 access token 으로 유효성 검증 후 access token 내에 만료 시간 데이터를 넣어서 매 요청마다 단순히 access token 내에 존재하는 만료 시간 데이터를 체크한 후에 서버에서는 만료가 된 토큰일 때 401 을 내려주면 된다.
그러면 클라이언트에서는 refesh token 을 가지고 서버에서 다시 access token 과 optional 인 refresh token 을 재발급 시키는 식으로 구현이 될 것이다.
그러면 이 refresh token 은 어디서, 어떻게 관리해야 할까?
access token, refresh token 이 존재하는 이유는 access token 은 중간에 탈취가 되더라도 공격자가 access token 의 만료 기간동안만 계정을 사용? 할 수 있도록 하고 access token 이 만료되는 시점에 공격자는 refresh token이 없어 access token 을 다시 재발급하지 못해 계정에 접근하지 못하도록 하기 위해 존재하는 듯 하다.
위 사진은 rfc 에서 정의한 oauth 관련 내용이다.
여기서 뜻하는 Client 는 뭘까,, 어쨌든 Client 에서 관리를 해야 한다. 이 때 이 클라이언트에서 관리를 해야 하는데 어떻게 관리를 해야 할 지 모르겠다. 해당 rfc 내용을 모두 읽은 것은 아니라서 어딘가에 관련 내용이 있을 수도 있다. 내일 한 번 다시 자세히 보긴 할건데,,
서버에 SSL 인증서 적용하고 웹 클라이언트에서 access token, refresh token 을 httponly cookie 를 통해 네트워크 통신할 때만 쿠키만 보내도록 설정. 이렇게 하면 js 상으로는 건드릴 수 없다고 한다.
이런 식으로 해서 rfc 처럼 구성할 수 있을 듯 하다