세션 기반 인증 vs 토큰 기반 인증
| 항목 | 세션 기반 인증 | 토큰 기반 인증 |
|---|---|---|
| 기본 개념 | 서버가 세션 ID를 생성하고 클라이언트는 쿠키로 보관 | 서버가 토큰(JWT 등)을 발급하고 클라이언트가 저장 |
| 상태 관리 | 상태 유지 (Stateful) | 무상태 (Stateless) |
| 저장 위치 | 세션은 서버, 세션 ID는 클라이언트의 쿠키 | 토큰은 클라이언트 (로컬 스토리지, 세션 스토리지, HttpOnly 쿠키 등) |
| 사용 환경 | 전통적인 웹 애플리케이션 | 모바일, SPA 등 다양한 환경 |
| 확장성 | 서버 세션 저장소 관리 필요 | 서버 부하 적음, 확장성 높음 |
| 보안 이슈 | 세션 탈취(Cookie Hijacking), CSRF | 토큰 탈취(XSS), 재발급 관리 필요 |
🛡️ 세션 기반 인증 보안 고려사항
- HTTPS 필수: 세션 ID가 노출되면 탈취 가능
- CSRF 방지: CSRF 토큰 적용 필요
- 서버 부하 증가: 세션 저장소 관리 필요
🛡️ 토큰 기반 인증 보안 고려사항
- HTTPS 필수: 토큰 탈취 방지
- XSS 방지: 로컬스토리지 대신 HttpOnly 쿠키 고려
- Access/Refresh 분리: 짧은 Access Token + 긴 Refresh Token 조합 권장
- 토큰 무효화: 클라이언트 위주 제어로 실시간 무효화 어려움
OAuth 2.0 구성요소 및 Authorization Code Grant 흐름
OAuth 2.0 : 사용자 비밀번호를 직접 공유하지 않고도 제3자 애플리케이션이 사용자의 리소스(데이터 등)에 안전하게 접근할 수 있도록 허용하는 권한 위임(Authorization Delegation) 프레임워크
🔑 핵심 목적
제3자 앱이 사용자의 자원에 접근할 수 있게 하되
사용자의 아이디/비밀번호를 직접 넘기지 않도록 하는 안전한 인증 구조
💬 예시 (Google OAuth2)
-
사용자가 "구글 계정으로 로그인" 버튼 클릭
-
Google 로그인 창으로 리다이렉트
-
로그인 및 권한 동의
-
앱은 Access Token을 받아 사용자 Gmail, 프로필, 드라이브 등에 접근 가능
OAuth 2.0 주요 컴포넌트
Resource Owner (리소스 소유자)
OAuth 인증 구조에서 리소스 소유자는 전체 플로우의 출발점이자 가장 중요한 주체
엔티티는 **자신이 소유하고 있는 보호된 리소스(예: 내 구글 드라이브 파일, 내 사진 등)에 대한 접근 권한 소유
일반적으로는 “최종 사용자(End User)”를 의미
자신이 보유한 데이터나 기능을 외부 서비스가 잠시 사용할 수 있도록 허용 여부 결정
Client (클라이언트)
사용자 대신 보호된 리소스에 접근하려는 제3자 애플리케이션
- Confidential Client: 서버에서 실행되며 클라이언트 시크릿을 안전하게 보관 가능 (예: 백엔드 앱)
- Public Client: 클라이언트 시크릿 보관이 어려운 구조 (예: SPA, 모바일 앱)
Authorization Server (인가 서버)
인증과 인가의 중심 역할을 수행
- 사용자 인증 (로그인)
- 권한 동의 수집
- 액세스 토큰 및 리프레시 토큰 발급
- 클라이언트 등록, 토큰 유효성 검증 등 처리
Resource Server (리소스 서버)
실제 보호된 데이터를 제공하는 주체
- 예: Google Drive API, Facebook Graph API 등
- 유효한 액세스 토큰 없이는 데이터 접근 불가
- 토큰 유효성 확인 후 데이터 반환
Authorization Code Grant 흐름
백 채널(Back Channel) vs 프론트 채널(Front Channel)
| 구분 | 설명 |
|---|---|
| Back Channel | 서버 간 직접 통신 예: 인가 코드 → 액세스 토큰 교환 사용자에게 보이지 않음, 보안성 높음 |
| Front Channel | 사용자의 브라우저를 통해 전송되는 통신 경로 예: 로그인/동의 리다이렉션, 인가 코드 전달 URL에 값이 노출될 수 있어 보안에 주의 필요 |
Authorization Code Grant (인가 코드 플로우)
가장 안전하고 널리 사용되는 OAuth 플로우
서버 사이드 애플리케이션에서 주로 사용됨
민감한 정보를 사용자 브라우저에 직접 노출하지 않고 백 채널(서버 간 통신)을 통해 토큰을 주고받기 때문에 보안에 유리
- 사용자가 로그인 버튼 클릭
- 클라이언트는 인가 서버로 리디렉션
- 사용자 로그인 및 권한 동의
- 인가 서버가 클라이언트에 인가 코드 전달
- 클라이언트는 인가 코드로 토큰 요청
- 인가 서버는 액세스 토큰 발급
- 클라이언트는 토큰으로 API 요청
- 리소스 서버가 사용자 데이터 응답
- 사용자 로그인 완료
