[JWT] 2-2. Practical Application: 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. 요청
   • 서버에 요청을 보낼때마다 AccessToken을 보냄
   • Authorization 헤더를 사용하여 Bearer 형태로 전송
2. 토큰 검증
   • 요청에 포함된 AccessToken 검증 (서명 유효성, 토큰의 만료 여부 등)
3. 응답
   • 검증에 성공하면 요청된 작업을 수행합니다.

 

과정) AccessToken 재발급 (RefreshToken)

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

 

 

참고

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