앞선 글에서 구글 소셜 로그인을 클라이언트단에서 구현해보았는데, 이를 수행하면서 생긴 질문들을 글로 정리해보도록 하였다.
JWT 기반 로그인 통신 로직
우선 백엔드 팀에서 구현한 API JWT 기반 로그인 통신 로직은 다음과 같다.
-
로그인 성공시
-> access token 및 refresh token 발행 -
Authorization Header에 access token 또는 refresh token을 세팅해서 API 호출
-
결과 처리
3.1 access token이 유효한 경우(정상)
-> API 결과 반환
{access token, access token expire at,
refresh token, refresh token expire at} 을 response로 반환해줌3.2 access token/refresh token이 만료된 경우
-> 401 에러 반환3.3 access token/refresh token이 변조된 경우
-> 403 에러 반환3.4 access token이 없을 경우 (2번에서 토큰을 세팅 안한 경우)
-> 401 에러 반환3.5 refresh token이 유효한 경우(정상)
-> Authorization Header에 access token 세팅 및 API 결과 반환
-> access token이 만료되어 refresh token을 넘겼을 때 access token 발급(갱신) 해줌
-
refresh token의 요청 시간과 db에 저장된 refresh token의 만료 시간과 비교해서 72시간 미만으로 차이가 나면 (refresh token의 만료시간 까지 72시간 이내) 서버에서 자동으로 refresh token의 만료 시간을 갱신
간단하게 diagram으로 나타내면 다음과 같다.
정리
reference token은
-
access token이 만료 되려고 할때 access token을 다시 발행하기 위한 용도로 쓰인다. 따라서 access token 보다 유효기간이 더 길어야 한다.
-
access token은 유효시간을 짧게 하는게 정석이라고 한다. access token 과 refresh token은 만료일자만 다르고 나머지는 같은 내용을 담고 있다.
-
세션을 유지한다는 말은 만료되지 않는 access(혹은 refresh) 토큰 값을 프론트 에서 가지고 있다는 말과 같다.
토큰이 있어야 서버에서는 이 토큰이 만료가 되지 않았는지 검사하고 안됐으면, 유효 한 값을 리턴하도록 로직을 구현한다.
생각해볼 거리
-
그러면 프론트에서 access token이 만료된 access token인지 아닌지 계속 검사(감시)를 하고 있어야되는건가?
-> 해당 사항에 대해 백엔드 개발자께 질문을 드려봤는데 api를 사용하기위해 Jwt token(access token)을 보냈는데 만약 401에러를 뱉으면(UnAuthorized error) refresh token을 다시 보내도록 request 설정을 해주면 된다고 하셨다.(api를 두번 호출해라)
access token의 만료는 프론트에서는 신경안써도 되고, 서버에 보냈을 때 응답값으로만 판단하면 된다!
-
세션을 유지하는데에 있어서는 access token만 있어도 가능한 것 같은데 굳이 refresh token이 필요하다는 견해도 있다.
access token의 유효 시간이 짧아야 보안에 유리할 것 같긴한데 공격자가 refres token을 통해서 access token을 얻어낼 수 도 있으니 무엇이 정답인지는 확실히 단정하기 어려울 것 같다.쨌든 오늘 공부한 내용을 바탕으로 블로깅한 로그인 구현부를 전체적으로 손봐야겠다...
레퍼런스
