세션 기반 인증 vs 토큰 기반 인증
Source: Dev.to
TL;DR
- Session 기반: 서버가 세션을 저장, 간단함, CSRF에 취약, 전통적인 웹 앱에 적합.
- Token 기반: 클라이언트가 토큰을 저장, 무상태(stateless), 확장성 좋음, XSS에 주의, API와 SPA에 최적.
Session-Based Authentication
Session 기반 인증은 많은 웹 애플리케이션에서 사용되는 전통적인 접근 방식입니다.
사용자가 로그인하면 서버가 세션을 생성하고 사용자 데이터를 서버에 저장합니다. 세션 ID가 포함된 쿠키가 브라우저에 전송됩니다. 브라우저는 모든 요청에 이 쿠키를 자동으로 포함시켜 서버가 사용자를 인식할 수 있게 합니다.
Advantages
- 구현과 이해가 쉬움
- 로그인·로그아웃 흐름이 단순함
- 전통적인 서버‑렌더링 애플리케이션에 잘 맞음
Limitations
- 서버‑사이드 세션 저장소가 필요함
- 분산 시스템에서 확장하기 어려움
- 쿠키가 브라우저에 의해 자동 전송되므로 CSRF 공격에 취약
Token-Based Authentication
Token 기반 인증은 현대 애플리케이션에서 흔히 사용됩니다.
로그인에 성공하면 서버가 토큰(보통 JWT)을 발급합니다. 클라이언트는 이 토큰을 저장하고 각 요청에 보통 Authorization 헤더에 담아 전송합니다. 서버는 세션 데이터를 저장하지 않고 토큰만 검증합니다.
Advantages
- 무상태이며 높은 확장성 제공
- API, 모바일 앱, SPA에 최적화
- 마이크로서비스 아키텍처에서 원활히 동작
Limitations
localStorage에 저장된 토큰은 XSS 공격에 취약- 로그아웃 및 토큰 폐기가 더 복잡함
보안을 강화하기 위해 토큰을 HttpOnly 쿠키에 저장할 수도 있습니다. 이렇게 하면 JavaScript에서 접근할 수 없어 XSS 위험을 줄일 수 있지만, 쿠키가 자동으로 전송되기 때문에 다시 CSRF 방어가 필요할 수 있습니다.
Storage and Security Trade‑Offs
보안은 인증 데이터가 어디에 저장되는지에 크게 좌우됩니다.
-
쿠키에 저장된 세션
쿠키는 요청과 함께 자동 전송되므로 CSRF 공격에 더 취약해집니다.HttpOnly와Secure플래그를 사용하면 다른 위험을 줄이는 데 도움이 됩니다. -
클라이언트에 저장된 토큰
localStorage에 저장된 토큰은 자동 전송되지 않아 CSRF 위험이 낮아지지만, 브라우저에서 악성 스크립트가 실행될 경우 XSS에 노출됩니다.
각 접근 방식은 편의성, 확장성, 보안 사이의 균형을 필요로 합니다.
Conclusion
만능 해결책은 없습니다.
- Session 기반 인증은 전통적인 웹 애플리케이션에 견고한 선택입니다.
- Token 기반 인증은 현대적이고 확장 가능한 API‑중심 시스템에 더 적합합니다.
올바른 방식을 선택하고 이를 적절히 보호하는 것이 가장 중요합니다.