서버 인증

정리 원본 링크 : 쉽게 알아보는 서버 인증 2편

• 기본 JWT 방식의 강화 버전인 Access Token & Refresh Token 방식에 대한 내용

Refresh Token

• Access Token를 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점
  • 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편
  • 그러나 유효기간을 늘리자면 토큰을 탈취당했을 때 보안에 더 취약해지게 됨
  • 이때 “그러면 유효기간을 짧게 하면서 좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 Refresh Token
• Refresh Token은 Access Token과 똑같은 형태의 JWT
  • 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서 Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됨
    • 여기서 만료라는 개념은 그냥 유효기간을 지났다는 의미

• 사용 예시
  • Refresh Token의 유효기간은 2주, Access Token의 유효기간은 1시간이라 했을 때
    • 사용자는 API 요청을 신나게 하다가 1시간이 지나게 되면 가지고 있는 Access Token은 만료됨
    • 하지만 Refresh Token의 유효기간 전까지는 Access Token을 새롭게 발급받을 수 있음

Tip!

• Access Token이 탈취 당했을 때 정보가 유출되는건 동일
• 다만 짧은 유효기간 안에만 사용이 가능하기에 상대적으로 안전하다는 의미

Tip!

• Refresh Token의 유효기간이 만료됐다면 사용자는 새로 로그인해야 함
• Refresh Token도 탈취될 가능성이 있기 때문에 적절한 유효기간 설정이 필요
  • 2주로 설정하는 경우가 많음

인증 과정

• ① 사용자가 로그인 함
• ② 서버에서는 회원 DB에서 값을 비교 (PW는 일반적으로 암호화해서 저장)
• ③-④ 로그인이 완료되면 Access Token, Refresh Token을 발급
  • 이때 일반적으로 회원DB에 Refresh Token을 저장
• ⑤ 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보냄
• ⑥-⑦ Access Token을 검증하여 이에 맞는 데이터를 보냄
• ⑧ 시간이 지나 Access Token 만료
• ⑨ 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보냄
• ⑩-⑪ 서버는 Access Token이 만료되었음을 확인하고 권한없음을 신호로 보냄
  • Access Token 만료가 될 때마다 계속 ⑨-⑪ 과정을 거칠 필요는 없음
  • 사용자(프론트엔드)에서 Access Token의 Payload를 통해 유효기간을 알 수 있기 때문에 API 요청 전에 토큰이 만료됐다면 바로 재발급 요청을 할 수도 있음
• ⑫ 사용자는 Refresh Token과 Access Token을 함께 서버로 보냄
• ⑬ 서버는 받은 Access Token이 조작되지 않았는지 확인한 후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교
  • Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급
• ⑭ 사용자(프론트엔드)는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행

장점

• ❶ 기존의 Access Token만 있을 때보다 안전

단점

• ❶ 구현이 복잡
  • 검증 프로세스가 길기 때문에 자연스레 구현하기 힘들어짐
• ❷ Access Token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP 요청 횟수가 많음
  • 이는 서버의 자원 낭비로 귀결