JWT(Json Web Token)

• JSON 객체를 사용하여 유저를 인증하고 식별하기 위한 정보를 전달.
• 필요한 모든 정보를 한 객체에 담아서 전달하기 때문에 JWT 한 가지로 인증을 마칠 수 있음.

HTTP 헤더에 토큰을 추가하는 방식을 (주로) 사용. (특히 Authorization 필드에 추가함) ex) Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT 구조

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT 사용 이유

HTTP는 기본적으로 state-less를 지향

• 클라이언트의 상태를 서버에 저장하지 않아도 됨.
• 트래픽에 대한 부담이 적음. but, JWT PAYLOAD에 많은 정보를 담으려고 할 경우 트래픽에 영향을 끼칠 수 있음.
  • 따라서,
  • 서버에서 최소한 유저를 식별할 수 있는 데이터만 담을 것 (성능)
  • 털렸을 때 가장 쓸모없는 데이터만 담을 것 (보안)

Access Token과 Refresh Token

• Access Token이 인증을 위한 토큰
• Refresh Token은 주기적으로 Access Token을 재발급 받는 용도로만 사용하는 토큰 (탈취의 위협때문)
• Access Token은 생명주기가 10분 정도로 짧게, Refresh Token은 생명 주기가 하루 정도로 길게

토큰 사용 시나리오

• 로그인 성공 시 Access, Refresh 토큰을 발급
• 권한이 필요한 모든 요청에 Access 토큰을 Header의 Authorization에 담아서 전송
• 서버에서 Access Token을 검증
• 세 가지 상황이 존재

  1. 데이터 정상 응답

  2. 유효하지 않은 토큰 (401, UNAUTHORIZED)

  3. 토큰 만료 응답 (어떻게 응답할지 협의 필요)

     1. Refresh Token을 통해 Access Token을 재발급 받아야 함.

        

     b. 프론트에서는 Refresh Token을 서버로 보내서, Token을 재발급 받음. (이때 Refresh Token도 새걸로 바꿔줌.)

     c. 재발급 받은 토큰을 실어서 다시 원래 요청을 보냄.

     • ex) "프로필을 입장 하려고 했으나, 토큰이 만료 ⇒ 토큰 재발급 ⇒ 다시 프로필 입장”과 같은 로직으로 진행