[JWT] 2. AccessToken과 RefreshToken

1. AccessToken

• 인증된 사용자가 자원 서버에 보안 리소스를 요청할 떄 인증을 대신하는 권한 토큰

항목	설명
클레임 (Claims)	- 인증 외의 부가 정보 저장 - 사용자 정의 클레임 추가 가능 (예: IP, 기기 정보 등)
유효기간 (Expiration)	- 보안을 위해 짧게 설정 (예: 1시간) - 노출 시에도 장시간 사용 방지 목적 - 만료 시 토큰은 무효 처리되고, 재요청 필요

 

2. RefreshToken

• AccessToken 갱신용 토큰: AccessToken이 만료될 때, 새로운 AccessToken을 요청하기 위한 토큰

항목	설명
사용자 경험 향상	- Access Token 만료 시 재로그인 없이 자동 재발급 가능 - 사용자 인증 요청을 줄여 UX 개선
유효기간	- Access Token보다 긴 유효시간을 가짐 (보통 며칠~수개월) - 장기 인증 유지에 사용
보관 위치 (서버)	- 주로 서버에 저장하여 관리 - 탈취 시 서버에서 무효화 가능 - 발급되는 Access Token의 속성 조정 가능
보안 위험성	- 긴 유효기간으로 인해 노출 시 위험 큼 (탈취 시 시스템에 장기간 무단 접근 가능) - 반드시 안전하게 저장 필요 (예: HttpOnly Cookie)

 

3. 동작 과정

로그인

1. 로그인
   • 클라이언트: 로그인 정보를 서버에 전송합니다.
2. 검증
   • 제공된 로그인 정보 검증
3. 응답
   • 서버: AccessToken와 RefreshToken 생성 및 응답 (Cookie: httpOnly)
   • 클라이언트: AccessToken와 RefreshToken을 보관 (Session Storage)

 

인증

1. 요청
   1. 서버에 요청을 보낼때마다 AccessToken을 보냄
   2. Authorization 헤더를 사용하여 Bearer 형태로 전송
2. 토큰 검증
   1. 요청에 포함된 AccessToken 검증 (서명 유효성, 토큰의 만료 여부 등)
3. 응답
   1. 검증에 성공하면 요청된 작업을 수행합니다.

 

AccessToken 재발급 (RefreshToken)

1. 인증 실패 (AccessToken 만료)
2. 재발급 시도
   • 클라이언트는 저장된 RefreshToken 사용하여 Authorization Server에 AccessToken 발급 요청
3. RefreshToken 유효성 검사
   
   • 서명 유효성, 만료 여부 등
   • 새로운 AccessToken를 생성하여 클라이언트에게 응답

 

 

참고

• Auth0 - JWT Handbook
• Wiki - JWT
• IEFE - RFC 7519