보안 인증 토큰 처리: 클라이언트가 토큰을 필요로 할 때
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
웹 개발
대상자
프론트엔드 개발자, 보안 전문가, 인증 시스템 설계자
핵심 요약
- 접근 토큰은 메모리에만 저장 (
localStorage/sessionStorage사용 금지) → XSS 공격 예방 - 리프레시 토큰은
HttpOnly,Secure,SameSite=Strict쿠키로 저장 → CSRF 방지 및 보안 강화 - 보안 강화 전략:
- CSP (Content Security Policy) 적용
- JWT 클레임 기반 역할 기반 접근 제어
- 토큰 회전 정책 (정기적인 만료/재발급)
섹션별 세부 요약
1. 인증 토큰 처리의 위험성
- XSS 취약점으로 인해
localStorage/sessionStorage에 저장된 토큰이 유출될 수 있음 - CSRF 공격 시 잘못된 쿠키 설정으로 인해 비동의 요청 발생 가능성
- 프론트엔드에서 토큰이 필요할 경우 (3rd-party API, GraphQL, Electron 앱 등) 보안 취약점 발생
2. 안전한 토큰 처리 전략
- 접근 토큰: 메모리에 저장 (React 상태 변수, Context 등) → 페이지 새로고침 시 소멸
- 리프레시 토큰:
HttpOnly,Secure,SameSite=Strict쿠키로 저장 → JavaScript 접근 차단 및 HTTPS 강제 - 예시 코드:
```javascript
// ❌ 비추천 (XSS 취약)
localStorage.setItem("token", yourJWT);
// ✅ 추천 (메모리 저장)
let accessToken = null;
function callAPI() {
fetch("/api/data", {
headers: { Authorization: Bearer ${accessToken} }
});
}
```
3. 하이브리드 토큰 관리 아키텍처
- 토큰 타입 | 저장 위치 | 유효 기간 | 사용 목적
- Access Token | 메모리 | 5~15분 | HTTP 헤더에 직접 전달
- Refresh Token | HttpOnly 쿠키 | 7~30일 | 백엔드에서 새로운 Access Token 발급
- 리프레시 토큰 사용 시:
- 클라이언트가 401 오류 발생 시 /api/refresh 엔드포인트 자동 호출
- 백엔드가 리프레시 토큰 검증 후 새로운 Access Token 발급
4. 보안 강화 추가 조치
- CSP 적용: 인라인 스크립트 차단
- XSS 방지: 입력/템플릿 값 sanitize
- 헤더 보안:
X-Content-Type-Options,X-Frame-Options설정 - JWT 클레임 기반 권한 제어:
role,scope등으로 접근 범위 제한
결론
- 접근 토큰은 메모리 저장, 리프레시 토큰은
HttpOnly쿠키로 관리하는 하이브리드 방식이 권장 - CSP, XSS 방지, 토큰 회전을 통한 보안 강화 필수
- 인증 토큰 처리는 보안과 편의성의 균형을 유지하는 핵심 설계 요소