2토큰 전략
오 아주 예리해! 👏
"토큰이 2방향"이라고 하는 건, Spring Security 기반의 인증 시스템에서
보통 Access Token + Refresh Token의 "2개 토큰 체계"를 말해.
🪙 Access Token + Refresh Token = 2토큰 전략
✔️ 보안성과 사용자 경험을 모두 만족시키기 위한 방법이야.
✅ 1. Access Token (엑세스 토큰)
| 항목 | 내용 |
|---|---|
| ⏱ 유효 기간 | 짧음 (예: 10분 ~ 1시간) |
| 🎫 역할 | 인증된 사용자의 정보(권한 등)를 담음 |
| 🔐 포함 내용 | 사용자 ID, 권한, 만료시간 등 |
| 📡 전송 방식 | Authorization: Bearer <token> 헤더로 매 요청 시 서버에 전송 |
{
"sub": "user123",
"role": "ROLE_USER",
"exp": 1713299999
}✅ 2. Refresh Token (리프레시 토큰)
| 항목 | 내용 |
|---|---|
| ⏳ 유효 기간 | 김치냉장고급 김장 기간 (일주일 ~ 한 달) |
| 🛠 역할 | Access Token이 만료됐을 때 새로 발급해주는 역할 |
| ❌ 요청 시 전송 안 함 | 브라우저 또는 쿠키에 저장하고, 재발급 요청할 때만 사용 |
| 🧷 보관 주의 | 유출되면 계정 탈취 위험이 커짐 → HttpOnly 쿠키로 저장 추천 |
🔄 동작 흐름 요약
[1] 로그인
↓
[2] Access Token + Refresh Token 발급
↓
[3] 클라이언트는 Access Token을 헤더에 담아 요청
↓
[4] Access Token 만료 시 → Refresh Token으로 재발급 요청
↓
[5] 서버는 Refresh Token 유효성 검사 후 새로운 Access Token 발급🔐 왜 두 개를 쓰냐?
| 이유 | 설명 |
|---|---|
| ✅ 보안 강화 | Access Token은 짧게 → 유출돼도 피해 최소화 |
| ✅ UX 개선 | 로그인 다시 안 해도 Refresh Token으로 갱신 가능 |
| ✅ 서버 무상태 유지 | 세션 없이도 인증 처리 가능 (Stateless) |
💡 Refresh Token 저장 위치?
| 위치 | 장점 | 단점 |
|---|---|---|
| 🍪 Cookie (HttpOnly) | 보안 좋음 | CSRF 대비 필요 |
| 💾 localStorage | 구현 간단 | XSS에 취약 |
실전에서는 Access Token은 localStorage / Refresh Token은 HttpOnly Cookie에
분리 저장하는 패턴이 가장 많이 쓰여.
🧠 Spring Security 배우면 앞으로 하게 될 흐름
[JWT 인증 필터 등록]
→ Access Token 검사 (SecurityContext에 유저 설정)
→ 만료되면 Refresh Token 요청 → 새로운 Access Token 응답원하면 Spring Security에서
- ✅ JWT Access + Refresh 인증 구조 설계
- ✅ Redis로 Refresh Token 관리 (만료/블랙리스트)
- ✅ 실시간 재발급 흐름도 도식으로
다 정리해줄 수 있어!
혹시 지금 기초 세팅 단계야, 아니면 실제 인증로직 구현 단계야? 😎
@mgkick