Access Token & Refresh Token

daybreak·2020년 9월 1일
4

Refresh Token?

로그인 요청을 하고 나서, 서버에서 토큰을 프론트에게 넘겨줄 때, 토큰을 하나 더 만들어서 넘겨준다. 하나 더 만든 토큰을 refresh token이라고 하고 기존에 발행하던 토큰을 access token이라고 한다.

refresh tokenaccess token이 만료되었을 때, access token을 다시 발행하기 위한 용도로 쓸것이기 때문에 access token보다 유효기간이 길어야 한다.

**Access Token(JWT)**를 통한 인증 방식의 문제는 해킹을 당했을 경우 보안에 취약하다는 점이 있다.
유효기간이 짧은 토큰의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 토큰을 발급 받아야 하므로 불편하다. 그렇다고 유효기간을 늘리면 토큰을 해킹당했을 때 보안에 더 취약해지게 된다.

이러한 점들을 보완하는게 **Refresh Token**이다.

  • refresh token은 access token과 같은 형태의 JWT이다. refresh token은 처음에 로그인을 완료 했을 때 access token과 동시에 발급된다. access token보다 긴 유효기간을 가지면서 access token이 만료되었을 때 새로 발급해 주는 열쇠가 된다.

  • access token이 해킹 당하면 정보가 유출된다. 하지만 유효기간을 짧게 해두면 그 기간 안에서만 사용이 가능하기 때문에 더 안전하다는 의미가 된다.

  • refresh token의 유효기간이 만료되면, 사용자는 새로 로그인 해야 한다. refresh token도 해킹될 가능성이 있기 때문에 적절한 유효기간 설정이 필요하다.

Access Token & Refresh Token 인증 과정

  1. 사용자가 로그인을 한다.

  2. 서버에서 사용자가 입력한 id, pw를 회원 DB에서 값을 비교한다.

3-4) 로그인이 완료되면 Access token, Refresh token을 발급한다. 이때 일반적으로 회원 DB에 refresh token을 저장해 둔다.

  1. 사용자는 Refresh token은 안전한 저장소에 저장 후, Access token을 헤더에 실어 요청을 보낸다.

6-7) Access token을 검증하여 이에 맞는 데이터를 보낸다.

  1. 유효기간이 지나면 Access token이 만료됐다고 보낸다.

  2. 사용자는 이전과 동일하게 Access token을 헤더에 실어 요청을 보낸다.

10-11) 서버는 Access token이 만료됨을 확인하고 권한 없음을 신호로 보낸다.

Access token 말료가 될 때마다 계속 과정 9~11을 거칠 필요가 없다. 프론트에서 Access token의 payload를 통해 유효기간을 알 수 있다. 따라서 프론트단에서 API요청 전에 토큰이 만료 됐다면 바로 재발급 요청을 할 수 도있다.

  1. 사용자(프론트)는 Refresh token과 Access token을 함께 서버로 보낸다.

  2. 서버는 Access token이 조작되지 않았는지 확인을 한 후, Refresh token과 사용자의 DB에 저장되어있던 Refresh token을 비교한다. 토큰이 동일하고 유효기간도 지나지 않았다면 새로운 Access token을 발급해 준다.

  3. 서버는 새로운 Access token을 헤더에 실어 다시 API요청을 진행한다.

장점

  • 기존 access token보다 안전하다.

단점

  • 구현이 복잡하다. 검증 프로세스가 길기 때문에 자연스럽게 구현하기 힘들다.
  • Access token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP요청 횟수가 많아진다. 이는 서버의 자원 낭비로 이어진다.

참고

https://tansfil.tistory.com/59?category=255594

profile
if not now, when?

관심 있을 만한 포스트

0개의 댓글