1. 세션 기반 인증(Session-based Authentication)
✔ 작동 방식
- 사용자가 로그인하면 서버가 세션 ID를 생성
- 서버는 세션 정보를 메모리/Redis/DB(Session Store)에 저장
- 클라이언트는 세션 ID가 담긴 쿠키를 보관
- 요청마다 쿠키에 담긴 세션 ID를 전송
- 서버는 “세션 ID가 유효한가?”를 검사해 사용자를 식별
✔ 세션 탈취 감지 가능 여부
- 서버는 세션 ID가 탈취되었는지 자체적으로 판단할 수 없다
- 세션 ID만 유효하면 정상 사용자라고 판단
- 탈취 감지는 아래와 같은 외부적인 정보로만 가능
- 로그인 위치(IP, 국가)
- User-Agent 변화
- 여러 IP에서 동시 요청
- 비정상 접속 패턴
✔ 세션 기반 인증이 확장성이 낮은 이유
- 사용자 수와 함께 서버가 저장해야 하는 세션 정보가 증가
- 서버가 여러 대일 경우 세션 공유 문제가 발생
- 특정 서버에만 세션이 저장되어 있으면 다른 서버로 요청이 갈 때 인증 실패
- 해결을 위해 Session Store(Redis 등) 필요
- 이는 구조 복잡성과 비용 증가로 이어짐
✔ 보안 고려사항
- 왜 필요한가에 대한 이유 포함
1) HttpOnly 쿠키
JavaScript로 쿠키를 읽지 못하게 해 XSS로 인한 쿠키 탈취를 방지
document.cookie로 접근 불가
2) Secure 옵션
HTTPS 연결에서만 쿠키 전송
중간자 공격(네트워크 스니핑) 방지
3) SameSite 옵션
외부 사이트에서 쿠키 자동 전송을 막아 CSRF 공격 방지
4) CSRF Token
쿠키는 자동 전송되므로, 요청이 진짜 사용자가 보낸 것인지 확인하기 위한 토큰
5) Session Rotation
로그인 직후 세션을 재발급하여 기존 세션 탈취 위험 감소
2. 토큰 기반 인증(Token-based Authentication, JWT)
✔ 작동 방식
- 로그인 시 서버는 토큰(JWT 등)을 발급
- 클라이언트는 이 토큰을 저장(localStorage, cookie 등)
- 요청마다 Authorization 헤더 등에 토큰을 실어 전송
- 서버는 토큰의 서명(Signature)을 검증해 유효성을 판단
- 서버는 인증 상태를 저장하지 않음 → Stateless
✔ 세션과 토큰의 차이
- 둘 다 클라이언트가 인증 정보를 “보관”하는 것처럼 보인다.
하지만 본질은 다름.
| 항목 | 세션 기반 | 토큰 기반 |
|---|---|---|
| 인증 상태 저장 | 서버 | 클라이언트 |
| 구조 | Stateful | Stateless |
| 인증 확인 | 서버 세션 조회 | 토큰 자체의 서명 검증 |
| 무효화 | 즉시 가능(서버 세션 삭제) | 어려움(토큰이 클라이언트에 존재) |
3. 토큰이 유효한지 서버는 어떻게 확인하는가?
토큰(JWT)은 아래 구조로 되어 있다.
Header.Payload.Signature서버는 Signature가 올바른지 검증하여
- 변조 여부
- 발급자
- 만료 시간(exp)
을 확인한다.
서버가 DB 접근 없이 검증할 수 있으므로 Stateless 인증이 가능함.
4. 토큰 무효화가 어려운 이유
- JWT는 서버가 저장하지 않는다
- 클라이언트가 토큰을 들고 있는 한 만료되기 전까지 계속 사용 가능
- 즉시 무효화하려면 강제로 막을 방법이 필요함
그래서 등장한 개념이 블랙리스트(Blacklist)
✔ 블랙리스트란?
서버가 “이 토큰은 더 이상 사용 금지”라고 기록해두는 리스트
Redis 등에 저장
요청마다 해당 토큰이 블랙리스트에 있는지 확인
구조가 무거워지고 추가 비용 발생
5. JWT(Json Web Token)란?
-
JWT는 토큰의 한 종류
-
JSON 기반으로 정보를 담고 있으며
-
다음과 같은 3부분으로 구성됨
Header.Payload.Signature
-
Access Token으로 가장 널리 사용됨
6. XSS & CSRF 취약점
✔ XSS(Cross-Site Scripting)
악성 스크립트를 브라우저에서 실행시키는 공격
예: 공격자가 게시판에 <script>document.cookie</script> 삽입
피해자가 페이지 열면 실행 → 토큰/세션 탈취 가능-> 토큰을 localStorage에 저장하면 특히 위험한 이유
✔ CSRF(Cross-Site Request Forgery)
브라우저가 쿠키를 자동 전송하는 취약점을 이용한 공격
피해자가 로그인 상태일 때 공격자가 의도한 요청이 자동으로 실행
예: img 태그로 특정 주문 요청 보내기-> 세션 기반 인증(쿠키 기반)에서 더욱 취약
7. Access Token & Refresh Token
✔ Access Token
API 요청 시 사용하는 토큰
만료 시간 짧음 (5~30분)
✔ Refresh Token
Access Token이 만료될 때 재발급하는 권한을 가진 토큰
더 긴 만료 시간
서버에서 저장하거나 HttpOnly Secure Cookie로 관리
요약
-
세션 기반
- 서버가 상태를 저장
- 쿠키 기반
- 보안 제어 쉬움
- 확장성 낮음
- CSRF 취약
-
토큰 기반
- 서버는 상태 저장 X
- 토큰 자체로 인증
- 확장성 높음
- 즉시 로그아웃 등 무효화 어려움
- XSS 취약(localStorage 저장 시)
두 방식 모두 장단점이 있으며,
현대 서비스는 Access/Refresh Token + HttpOnly Cookie 조합을 자주 사용한다.
