Access Token,Refresh Token이란?
-
Access Token (JWT 기반 토큰)
- 역할:클라이언트 인증 요청 시마다 헤더에 포함되어 사용자를 인증하는 토큰입니다.
- 특징:JWT 특성상 서버는 세션 저장 없이 self-contained 토큰만으로 인증 가능 (stateless) → 사용자 인증 시 데이터베이스 조회 불필요합니다.
- Stateless:서버가 사용자 인증 상태(state)를 따로 기억하지 않아도 된다는 의미
- 로그아웃 처리 방식
- 클라이언트 저장소에서 삭제 (메모리 등)
- HTTP-only 쿠키의 경우, 서버가 쿠키 만료를 강제
- Blacklist 방식으로 무효화 (하지만 상태 저장 필요 → Stateless성 일부 상실)
- 취약점: 유효 기간 동안 탈취 시 악용 가능. 서버는 토큰이 탈취된 사실을 알 수 없기에 만료될 때까지 대응 불가. 토큰 자체를 짧게 설정하는 것이 방어책 중 하나
-
Refresh Token
- 역할:만료된 Access Token을 재발급받기 위해 사용하는 “긴 수명의 토큰”입니다.
- 동작구조
- Access Token 만료 시 클라이언트는 Attach Token 대신 Refresh Token을 서버에 보내 새 Access Token을 요청합니다.
- 서버는 Refresh Token의 유효성을 검증한 뒤 새 Access Token(및 필요 시 Refresh Token)을 발급합니다
- 보안이슈
- 만료된 토큰 대신 새 토큰 자동 요청 가능 → 사용자 경험 유지
- 그러나 Refresh Token이 탈취되면 공격자가 또다시 토큰을 발급받을 수 있는 위험이 존재합니다
- JWT 형태 사용
- Refresh Token도 JWT로 구현할 수 있으며, self-contained 특성을 활용해 DB 조회 없이 인증할 수 있지만, 보안 취약성을 고려해 self-contained 구조는 지양하는 것이 좋습니다.
Self-contained Token, Reference Token 이란?
Self-contained Token
- 토큰 자체에 인증/인가에 필요한 모든 정보가 들어있는 토큰
- 토큰 내부에 사용자 식별자, 권한(Role), 만료 시간 같은 정보가 직접 포함되어 있음
- 서버가 별도의 저장소(DB, 세션 스토어)를 확인하지 않고도 토큰만으로 검증 가능
- 대표적인 예: JWT (JSON Web Token)
Reference Token
- 토큰 자체에는 의미 없는 랜덤 문자열만 있음
- 서버는 토큰을 DB/Redis 등에서 찾아보고 그 안의 사용자 정보를 확인
- OAuth2에서 흔히 opaque token이라고 부름
| Self-contained (JWT 등) | Reference (Opaque) |
|---|
서버 확장성 좋음 (stateless) DB 조회 없이 빠른 인증 | 토큰 탈취 시 서버에서 무효화 가능 토큰 자체에 민감 정보 없음 |
탈취되면 만료 전까지 무조건 사용 가능 토큰 강제 무효화 어렵다 | 매 요청마다 서버 DB/캐시 조회 필요 부하가 증가할 수 있음 |
✍ 결론
- 액세스 토큰은 짧은 수명으로 발급해 매 요청마다 인증을 처리하고, 리프레시 토큰은 긴 수명으로 보관해 만료 시 새로운 액세스 토큰을 발급받도록 하여, 보안성과 사용자 편의성을 동시에 확보하는 것이 인증 시스템의 핵심 구조이다.
참고
블로그
OAuth Refresh Tokens 공식문서
마이크로소프트 Access Tokens 공식문서