1. 개요
웹 애플리케이션에서 인증(Authentication)은 사용자의 신원을 검증하고, 이후 요청에서 인증 상태를 유지하는 핵심 기능이다.
인증 방식에는 크게 세션 기반(Session-based) 인증과 토큰 기반(Token-based) 인증이 있으며,
각 방식은 인증 정보를 저장하고 검증하는 구조가 다르기 때문에 서비스 규모, 확장성, 보안 요구사항에 따라 선택이 달라진다.
2. 세션 기반 인증
2.1 동작 원리
-
사용자가 ID/PW를 서버로 전송
-
서버가 인증 성공 시 세션 저장소(메모리/DB)에 사용자 정보를 저장
-
세션 ID를 발급하고 쿠키로 브라우저에 저장
-
이후 요청마다 쿠키에 담긴 세션 ID로 서버에서 상태를 조회
2.2 특징
-
Stateful: 서버가 인증 상태를 저장
-
즉시 무효화 가능: 세션 삭제 시 바로 로그아웃
-
스케일 아웃 문제: 서버를 여러 대 운영하면 세션 공유(Sticky Session, Redis) 필요
2.3 보안 고려사항
-
HTTPS + Secure, HttpOnly 쿠키
-
세션 ID 재발급(로그인/중요 권한 변경 시)
-
CSRF 토큰 적용
-
세션 만료 시간 설정(짧게 유지)
2.4 사용 사례
-
기업 내부 관리자 페이지
-
인원 제한적, 서버 수가 적고, 세션 공유가 쉬움
-
전통적인 웹 서비스
-
JSP, PHP, Rails 기반 사이트
-
즉시 로그아웃이 중요한 서비스
예: 인터넷 뱅킹, 보안이 중요한 정부 사이트
3. 토큰 기반 인증
3.1 동작 원리 (JWT 예시)
-
사용자가 ID/PW를 서버로 전송
-
서버가 인증 후 JWT(사용자 정보 + 서명)를 생성
-
클라이언트(브라우저, 앱)에 토큰 저장(LocalStorage, Cookie 등)
-
이후 요청 시 HTTP 헤더(
Authorization: Bearer <token>)로 전송 -
서버가 토큰 서명 검증 후 요청 처리
3.2 특징
-
Stateless: 서버가 인증 상태 저장하지 않음
-
확장성 우수: 서버 간 세션 공유 불필요
-
토큰 길이 부담: 매 요청마다 토큰 전송
-
즉시 무효화 어려움: 블랙리스트나 짧은 만료 시간 필요
3.3 보안 고려사항
-
HTTPS 필수
-
Access Token 짧게(분 단위), Refresh Token 길게(일~주 단위)
-
HttpOnly 쿠키 사용(XSS 방지)
-
토큰 재사용 방지(jti 클레임, Redis 저장소)
-
로그아웃 시 Refresh Token 삭제
3.4 사용 사례
-
마이크로서비스 아키텍처(MSA)
-
서비스 간 인증 공유가 필요
-
모바일 + 웹 통합 서비스
예: 카카오톡, 유튜브 (모바일 앱과 웹 모두 같은 계정 사용) -
외부 API 제공 서비스
예: GitHub API, Google OAuth -
SPA(단일 페이지 애플리케이션)
-
React, Vue, Angular 기반 프론트엔드와 REST API 서버 분리 구조
4. 세션 vs 토큰 비교
| 구분 | 세션 기반 인증 | 토큰 기반 인증 |
|---|---|---|
| 상태 저장 | 서버 저장(Stateful) | 클라이언트 저장(Stateless) |
| 확장성 | 낮음 (세션 공유 필요) | 높음 |
| 로그아웃 | 즉시 가능 | 블랙리스트 필요 |
| 저장 위치 | 서버(메모리/DB) | 클라이언트(LocalStorage, Cookie 등) |
| 적합한 서비스 | 내부 서비스, 전통 웹 | MSA, SPA, API 서비스 |
| 보안 위협 | 세션 하이재킹, CSRF | 토큰 탈취, Replay Attack |
5. 선택 가이드
-
세션 기반 인증 추천
-
서버 수가 적고, 세션 공유가 쉬운 환경
-
보안상 즉시 로그아웃이 필수
-
예: 금융 서비스, 사내 관리 시스템
-
-
토큰 기반 인증 추천
-
서버 확장성, 글로벌 분산 서버 환경
-
모바일·웹 통합 인증 필요
-
예: SNS, 대규모 API 서비스, MSA 환경
-
6. 결론
인증 방식 선택은 단순히 기술 유행이 아니라 서비스 구조와 보안 요구사항에 맞춰야 한다.
많은 현대 서비스는 하이브리드 방식을 채택한다.
예를 들어:
Access Token(JWT): 짧은 만료 시간, API 호출 시 사용
Refresh Token(서버 저장): 재발급 요청 시 검증 및 즉시 무효화 가능
💡 토큰의 확장성과 세션의 보안성을 절충하는 방식이 많이 쓰인다.
OAtuh 2.0
1. OAuth 2.0이란?
OAuth 2.0은 인증(Authentication)이 아니라 인가(Authorization)를 위한 프레임워크로서, 사용자가 자신의 계정 자격 증명을 직접 노출하지 않고,
제3자 애플리케이션이 제한된 범위 내에서 리소스에 접근할 수 있도록 권한을 위임하는 표준 방식이다.
2. OAuth 2.0의 주요 컴포넌트
| 컴포넌트 | 설명 | 예시 |
|---|---|---|
| Resource Owner | 리소스의 소유자(대개 사용자) | 구글 계정의 주인 |
| Client | 리소스에 접근하려는 애플리케이션(서드파티 앱) | 내 앱, 웹 서비스 |
| Resource Server | 보호된 리소스를 보관하는 서버 | Google API 서버 |
| Authorization Server | 권한 부여 및 Access Token 발급 담당 서버 | Google OAuth 서버 |
주의: Authorization Server와 Resource Server는 같은 서버일 수도, 분리될 수도 있다.
예를 들어, Google은 accounts.google.com(인가 서버)과 www.googleapis.com(리소스 서버)을 분리해서 운영한다.
3. Authorization Code Grant란?
OAuth 2.0의 4가지 Grant Type 중 가장 널리 쓰이며 보안성이 높은 방식이다.
특히 서버 사이드 애플리케이션에 적합하다.
사용 이유
- 보안 강화: Access Token이 브라우저나 URL에 직접 노출되지 않음
- Refresh Token 발급 가능: 장기 세션 유지 가능
- 백엔드 서버를 통한 토큰 관리 가능
4. Authorization Code Grant 흐름 (단계별)
-
사용자가 Client 앱에서 로그인 요청
사용자가 “Google 계정으로 로그인” 버튼을 클릭하면
Client는 Authorization Server로 리다이렉트한다. -
사용자 인증 및 동의
Authorization Server는 로그인 화면과 권한 동의 화면을 표시한다. -
Authorization Code로 Access Token 교환
Client 앱은 받은 AUTH_CODE를 Authorization Server에 POST 요청하여 Access Token을 요청한다 -
Access Token으로 리소스 요청
Client는 Access Token을 Authorization 헤더에 넣어 Resource Server에 요청한다. -
(선택) Refresh Token으로 Access Token 갱신
Access Token이 만료되면 Refresh Token을 사용해 새 Access Token을 발급받는다.
OAuth 보안 고려사항
HTTPS 필수: 토큰과 코드 전송 시 중간자 공격 방지
State 값 검증: CSRF 방지
Access Token 저장 위치: 브라우저 로컬스토리지 대신 서버 세션에 저장 권장
Refresh Token 관리: 탈취되면 장기 접근 가능하므로 반드시 안전한 스토리지에 보관
