위클리 페이퍼 - 13주차

Q. 세션 기반 인증과 토큰 기반 인증의 차이점과 각각의 보안 고려사항에 대해 설명하세요.

 

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

 

• 서버가 사용자 로그인 정보를 서버 메모리 또는 DB에 저장하여 상태를 유지
• 사용자는 로그인 시 Set-Cookie로 전달된 세션 ID를 브라우저 쿠키에 보관

흐름

 

1. 사용자 로그인
2. 서버가 세션 ID 생성 + 저장
3. 세션 ID가 쿠키에 저장되어 이후 요청마다 전송
4. 서버는 세션 ID로 사용자 식별

장점

• 브라우저 친화적, 구현이 단순
• 서버가 직접 상태를 관리하므로 보안 제어가 쉬움

보안 고려사항

• 세션 탈취(세션 하이재킹) 위험 존재 → HTTPS 필수
• 세션 고정 공격 대비 위해 매 로그인 시 새로운 세션 ID 발급 필요
• 서버 확장 시 세션 클러스터링 필요 (Sticky Session, Redis 등)

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

개념

• 로그인 성공 시 서버가 토큰(JWT 등)을 발급
• 토큰에는 인증된 사용자 정보가 인코딩되어 있으며, 서버는 이를 저장하지 않음 (Stateless)

흐름

1. 사용자 로그인
2. 서버가 JWT 발급 (Access Token)
3. 클라이언트는 헤더에 토큰을 담아 API 요청
4. 서버는 토큰 검증 후 요청 처리

장점

• 서버 상태 비저장(Stateless) → 확장성 우수
• 모바일/SPA 등 다양한 클라이언트와 잘 어울림

보안 고려사항

• 토큰 탈취 시 위험이 큼 → HTTPS는 기본
• 토큰 만료 관리 필요 (Access / Refresh Token 분리 전략 활용)
• 토큰 저장 위치 고려
  • 브라우저: LocalStorage는 XSS 위험 / Cookie는 CSRF 고려 필요
• 토큰 무효화가 어려움 → 블랙리스트 DB 또는 만료시간 전략

Q. OAuth 2.0의 주요 컴포넌트와 Authorization Code Grant 흐름을 설명하세요.

OAuth 2.0 주요 컴포넌트

컴포넌트	설명
Resource Owner	리소스를 소유한 사용자
Client	인증 요청을 수행하는 앱 (ex. 내 앱)
Resource Server	보호된 리소스를 보관한 서버 (ex. 구글 API)
Authorization Server	권한을 부여하는 서버 (ex. 구글 로그인 서버)

Authorization Code Grant Flow

1. 사용자 → Client 로그인 요청
2. Client → Authorization Server 인증 요청
   (response_type=code, client_id, redirect_uri 포함)
3. 사용자 → 로그인 및 권한 승인
4. Authorization Server → Client에 Authorization Code 전달
   (리다이렉트 URL로)
5. Client → Authorization Server에 Access Token 요청
   (Authorization Code + Client Secret 함께 전달)
6. Authorization Server → Access Token 발급
7. Client → Resource Server에 API 호출 (with Access Token)

OAuth 2.0 보안 고려사항

• Authorization Code는 노출되면 안됨 → HTTPS 필수
• Implicit Flow는 사용 자제 (보안상 취약)
• PKCE(Proof Key for Code Exchange) 적용 권장 (특히 모바일/SPA)
• Refresh Token은 안전하게 보관 → DB 암호화 또는 Secure Cookie 활용