Access Token, Refresh Token

참고자료

• https://cotak.tistory.com/102
• https://tansfil.tistory.com/59

Access Token

• 기본적을 http 통신은 stateless 상태가 없음
• Access Token는 http의 stateless 특성으로 인한 비효율 작업을 해결하기 위해 권한을 유지하기 위함 이라는 점이 가장 중요한 포인트
• Access Token은 인증을 위한 JWT이면서, 동시에 보안을 위해 유효기간이 매우 짧음
• access token만을 이용한 인증 방식
  1. 사용자 로그인
  2. 서버에서 사용자 인증을 진행한 후 access token을 발급
  3. 생성한 토큰을 클라이언트에게 반환하고 클라이언트는 이를 저장
  4. 클라이언트는 권한 인증이 필요할 때마다 이 토큰을 헤더에 실어서 보냄
  5. 서버는 헤더의 토큰을 검증하고 payload의 값을 디코딩하여 사용자의 권한을 확인하고 데이터를 반환
  6. 토큰이 valid하지 않거나 만료되면 새롭게 로그인하여 토큰을 발급해야함

Refresh Token

• Access Token만을 이용한 인증 방식의 문제는 제 3자에게 토큰을 탈취당하게 되면, 토큰의 유효기간이 만료되기 전까지는 막을 방법이 없다는 점
• 그렇기에 대부분 토큰의 유효기간을 짧게 설정합니다. 하지만, 짧게 설정하면 로그인을 자주해야하는 단점이 있어 사용자가 불편
• 따라서 Refresh Token을 통해 위의 문제를 보완. Refresh Token은 아주 긴 유효기간을 가지며 Access Token이 만료되었을 때 새로 발급을 해주기 위한 토큰
• ex) Acess Token의 유효기간을 1시간, Refresh Token의 유효기간을 2주정도로 정함. 그후 Access Token이 만료되었을 때, Refresh Token이 만료되지 않았다면 Access Token을 재발급하는 형태로 인증을 하게 됨
• access token && refresh token을 이용한 인증 방식
  1. 사용자 로그인
  2. 서버에서 사용자 확인 후 access token 및 refresh token 생성하여 두 토큰을 모두 클라이언트에게 반환
  3. 클라이언트는 두 토큰을 저장
  4. 클라이언트는 권한 인증이 필요한 요청을 할 때마다 access token을 헤더에 실어서 보냄
  5. 서버는 헤더의 토큰을 검증하고 payload의 값을 디코딩하여 사용자의 권한을 확인하고 데이터를 반환
  6. 만약 토큰이 만료되었다면 서버는 클라이언트에게 만료되었다는 응답을 보냄
  7. 클라이언트는 만료된 토큰을 재발급 받기 위해 만료된 access token과 refresh token을 헤더에 실어 서버에게 새로운 토큰 발급을 요청
  8. 서버는 access token과 refresh 토큰을 모두 검증한 후 refresh token이 만료되지 않았다면 새로운 access token을 발급하여 클라이언트에게 반환
  

Access Token, Refresh Token을 모두 사용할 때의 장점

• access token 만을 사용한 방식보다는 복잡하지만 확실히 access token만을 사용했을 때보다는 보안상의 큰 이점을 얻을 수 있음
• access token의 경우 로그가 그대로 노출됌. 이 토큰의 유효기간을 너무 길게하면 공격자가 이를 악용할 수 있음. 따라서 api 요청 시 잘 노출되지 않는 refresh token을 사용하면 보안상 보다 안전함

Access Token, Refresh Token을 모두 사용할 때의 단점

• 구현이 복잡함. 검증 프로세스 단계가 길기 떄문에 구현이 상대적으로 힘들어짊
• access token이 만료 될 때마다 새롭게 발급하는 과정에서 생기는 http 요청 횟수가 많아짐. 이는 서버의 자원 낭비로 귀결 될 수 있음