[JWT] 2-2. Practical Application: AccessToken / RefreshToken

1. AccessToken

• 인증된 사용자를 대신해 클라이언트가 Resource Server에 보호된 자원에 접근할 수 있도록 권한을 증명하는 토큰
• ✅ 발급 주체: Authorization Server
• ✅ 검증 주체: Resource Server

 

Claim

• 인증 외 부가 정보를 의미함
• 사용자 정의 클레임 추가 가능

Claim	설명	특징
iss	토큰 발급자
sub	토큰의 사용자 또는 주체
aud	토큰을 사용할 Resource Server
exp	토큰 만료 시각	보안을 위해 짧게 설정 (약 2시간)
iat	토큰 발급 시각
scope	허용된 접근 범위
roles	애플리케이션의 사용자 역할

 

2. RefreshToken

• AccessToken이 만료되었거나 만료되기 전, 사용자가 다시 로그인하지 않고 새로운 AccessToken을 받기 위해 사용하는 토큰
• ✅ Access Token보다 긴 유효시간을 가짐
• ✅ Authorization Server는 검증하고 폐기할 수 있도록 저장소에 원본을 보관함
• ✅ 브라우저 클라이언트는 안전한 쿠키에 보관할 수 있음
  • Path 설정: 우리 서비스 도메인에서만 자동 포함하게 하기
  • HttpOnly 설정: 안전하게 보관하기
  • Secure, SameSite 설정: 안전하게 전송하기
• ➡️ 사용자 경험 향상 (만료될 때마다 백그라운드에서 로그인 → 다시 로그인하는 불편함을 줄일 수 있음)

 

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