왜 토큰을 2개로 나눌까? 🤔

- 토큰 유효기간이 긴 경우, 탈취 시 장시간 악용 가능 (보안 취약)

- 토큰 유효기간이 짧은 경우, 로그인 빈도 수가 많아짐 (사용자 불편)

Access Token (접근 토큰)

API 요청 시 인증된 사용자임을 증명하기 위한 토큰 → “지금 이 요청을 해도 되는 사용자인가?”

GET /api/products HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "sub": "20",
  "role": "USER",
  "exp": 1736073600
}

• API 인가 판단에 필요한 정보 포함 (필수)
  • 사용자 식별자(sub)
    • userId로 DB를 조회해야 인가 판단이 가능하다면,
    • 그 요청 처리는 외부 상태에 의존하므로 Stateless가 아니다.
  • 권한 정보(role)
    • 서버는 DB 조회 없이 토큰만 보고 권한 판단 하고 싶다면 role은 사실상 필수이다.
    • 매 요청마다 DB 조회를 하면 트래픽 증가, 성능 저하가 발생
    • role이 없으면 사용자가 ADMIN인지 USER인지 알 수 없어 결국 DB 조회가 필요
  • 만료 시간(exp)
    • 토큰의 유효 여부를 판단

Refresh Token (갱신 토큰)

만료된 Access Token을 재발급받기 위한 토큰

{
  "sub": "20",
  "exp": 1738675200
}

• Access Token의 Payload와는 차이가 있다.
• 최소한의 정보만 포함
  • 사용자 식별자 (userId)
  • 만료 시간
• 권한(role) 정보 포함 ❌
• API 접근에 사용 ❌
• 오직 Access Token 재발급 요청에만 사용

Access Token 만료 시 전체 흐름

[1] Access Token 만료
      ↓
[2] API 요청 → 401 Unauthorized
      ↓
[3] Refresh Token으로 재발급 요청
      ↓
[4] 새 Access Token 발급
      ↓
[5] 기존 API 재요청