세션 기반 인증 vs 토큰 기반 인증

세션 기반 인증 (Session-based Authentication)

개념:

• 서버 측에서 사용자의 인증 정보를 저장하고 관리하는 방식입니다.
• 사용자가 로그인하면 서버는 세션(Session)이라는 고유한 정보를 생성하여 저장합니다.
• 이 세션 ID를 클라이언트(웹 브라우저 등)에 쿠키 형태로 전달합니다.
• 클라이언트는 이후 요청 시마다 이 쿠키를 서버에 함께 전송하여, 서버는 쿠키에 담긴 세션 ID를 통해 사용자를 식별하고 인증 상태를 유지합니다.

작동 방식:

1. 로그인 요청: 사용자가 아이디와 비밀번호 등 인증 정보를 서버에 전송합니다.
2. 인증 및 세션 생성: 서버는 받은 정보를 검증하고, 유효한 경우 세션을 생성하여 서버의 저장소 (메모리, 데이터베이스 등)에 저장합니다. 이 세션에는 사용자 정보, 로그인 시간, 만료 시간 등이 포함될 수 있습니다.
3. 세션 ID 전달: 서버는 생성된 세션의 고유한 ID를 쿠키에 담아 클라이언트에게 응답으로 보냅니다.
4. 쿠키 저장 및 전송: 클라이언트는 받은 쿠키를 저장하고, 이후 서버에 요청을 보낼 때마다 해당 쿠키를 HTTP 헤더에 담아 함께 전송합니다.
5. 세션 ID 확인 및 인증 유지: 서버는 요청에 포함된 쿠키에서 세션 ID를 추출하여 서버에 저장된 세션 정보와 비교합니다. 일치하는 세션이 있다면 해당 사용자를 인증된 것으로 간주하고 요청을 처리합니다.
6. 로그아웃: 사용자가 로그아웃하면 서버는 해당 세션을 무효화하거나 삭제하고, 클라이언트 측의 쿠키를 삭제하거나 만료시킵니다.

장점:

• 간단한 구현: 비교적 구현이 간단하고 직관적입니다.
• 중앙 집중식 관리: 서버에서 사용자 세션을 중앙에서 관리하므로 보안 정책 적용 및 사용자 정보 관리가 용이합니다.
• 세션 제어 용이: 서버에서 세션의 만료 시간을 설정하거나 강제로 로그아웃시키는 등 세션 관리가 용이합니다.
• 상태 유지 (Stateful): 서버가 세션 정보를 기억하므로 각 요청마다 사용자 정보를 다시 확인할 필요가 없습니다.

단점:

• 서버 자원 사용 증가: 많은 사용자의 세션 정보를 서버가 저장하고 관리해야 하므로 서버 부하가 증가할 수 있습니다.
• 확장성 문제: 여러 대의 서버를 사용하는 환경 (로드 밸런싱)에서 세션 동기화 문제가 발생할 수 있습니다. 이를 해결하기 위해 세션 공유 메커니즘 (예: Redis, Memcached)이 필요합니다.
• CORS (Cross-Origin Resource Sharing) 문제: 쿠키 기반 인증은 다른 도메인 간 요청에서 제약이 있을 수 있습니다.
• CSRF (Cross-Site Request Forgery) 공격에 취약: 쿠키를 이용하므로 CSRF 공격에 취약할 수 있으며, 이를 방지하기 위한 추가적인 보안 대책 (예: CSRF 토큰)이 필요합니다.

토큰 기반 인증 (Token-based Authentication)

개념:

• 클라이언트 측에서 토큰을 저장하고 사용하여 사용자를 인증하는 방식입니다.
• 사용자가 로그인하면 서버는 인증 성공 시 클라이언트에게 토큰 (일반적으로 JWT - JSON Web Token)을 발급합니다.
• 이 토큰은 클라이언트 측 (로컬 스토리지, 쿠키 등)에 저장됩니다.
• 클라이언트는 이후 요청 시마다 이 토큰을 HTTP 헤더 (Authorization 헤더에 Bearer 스키마를 사용하여 포함)에 담아 서버에 전송합니다.
• 서버는 토큰의 유효성을 검증하여 사용자를 인증합니다. 서버는 토큰 정보를 저장하지 않는 Stateless 방식입니다.

작동 방식:

1. 로그인 요청: 사용자가 아이디와 비밀번호 등 인증 정보를 서버에 전송합니다.
2. 인증 및 토큰 생성: 서버는 받은 정보를 검증하고, 유효한 경우 접근 토큰 (Access Token)을 생성하여 클라이언트에게 응답으로 보냅니다. 필요에 따라 갱신 토큰 (Refresh Token)도 함께 발급될 수 있습니다.
3. 토큰 저장: 클라이언트는 받은 토큰을 안전한 저장소 (예: Local Storage, HttpOnly 쿠키)에 저장합니다.
4. 요청 시 토큰 전송: 클라이언트는 보호된 리소스에 접근할 때마다 HTTP 요청 헤더의 Authorization 필드에 Bearer 스키마와 함께 토큰을 담아 전송합니다 (예: Authorization: Bearer <token>).
5. 토큰 검증: 서버는 요청 헤더에서 토큰을 추출하여 서명 (Signature)을 검증하고, 만료 여부 등을 확인하여 토큰의 유효성을 검증합니다.
6. 인증 및 권한 부여: 토큰이 유효하면 토큰에 포함된 정보 (Payload)를 기반으로 사용자를 식별하고 권한을 확인하여 요청을 처리합니다.
7. 로그아웃 (선택적): 토큰 기반 인증은 Stateless하므로 명시적인 로그아웃 과정이 필수는 아닙니다. 클라이언트 측에서 토큰을 삭제하면 더 이상 인증된 요청을 보낼 수 없습니다. 서버 측에서 토큰을 무효화하는 메커니즘 (예: 블랙리스트 관리)을 구현할 수도 있습니다.
8. 토큰 갱신 (Refresh Token 사용 시): 접근 토큰이 만료되면 클라이언트는 갱신 토큰을 서버에 보내 새로운 접근 토큰을 발급받을 수 있습니다.

장점:

• 확장성: 서버가 토큰 정보를 저장하지 않으므로 여러 대의 서버를 사용하는 환경에서 확장성이 뛰어납니다 (Stateless).
• 다양한 플랫폼 지원: 토큰은 쿠키에 의존하지 않으므로 웹 브라우저뿐만 아니라 모바일 앱, 데스크톱 앱 등 다양한 플랫폼에서 사용 가능합니다.
• CORS 문제 해결 용이: HTTP 헤더를 통해 토큰을 전달하므로 CORS 제약에서 비교적 자유롭습니다.
• 보안성: JWT는 서명을 통해 위변조를 방지할 수 있으며, 필요한 정보만 토큰에 담아 전송하여 보안성을 높일 수 있습니다.
• API 서버에 적합: RESTful API와 같은 Stateless 환경에 적합합니다.

단점:

• 구현 복잡성: 세션 기반 인증에 비해 구현이 다소 복잡할 수 있습니다.
• 토큰 탈취 위험: 토큰이 클라이언트 측에 저장되므로 토큰이 탈취될 경우 보안에 취약해질 수 있습니다. 토큰의 유효 기간을 짧게 설정하고 안전한 저장 방식을 사용하는 것이 중요합니다.
• 토큰 무효화의 어려움: 일단 발급된 토큰은 만료될 때까지 유효하므로, 서버 측에서 강제로 특정 토큰을 무효화하기 어려울 수 있습니다. 이를 해결하기 위해 추가적인 메커니즘 (예: 블랙리스트 관리)이 필요합니다.
• 토큰 크기: 토큰에 많은 정보를 담을 경우 크기가 커져 네트워크 트래픽을 증가시킬 수 있습니다.

요약 비교

특징	세션 기반 인증 (Session-based Authentication)	토큰 기반 인증 (Token-based Authentication)
상태 유지	Stateful (서버가 세션 정보 저장)	Stateless (서버는 토큰 정보 저장 안 함)
저장 위치	세션 정보: 서버, 세션 ID: 쿠키	토큰: 클라이언트 (로컬 스토리지, 쿠키 등)
확장성	제한적 (세션 동기화 필요)	우수
플랫폼 지원	웹 브라우저에 최적화	다양한 플랫폼 지원
CORS	문제 발생 가능성 있음	비교적 자유로움
보안	CSRF 공격에 취약, 세션 관리 중요	토큰 탈취 위험 존재, 토큰 관리 및 유효 기간 중요
구현 난이도	비교적 간단	다소 복잡
API 적합성	전통적인 웹 애플리케이션에 주로 사용	RESTful API 등 Stateless 환경에 적합