결국 인증은 어떻게 구현하는 것인가?
-
웹 인증에서 많이 사용되는 방식은 세션, 쿠키, JWT, 웹 스토리지 등이 있다.
-
이 포스팅에서는 각 방식의 원리, 장단점, 그리고 사용 사례를 비교해보려 한다.
1. 세션(Session)
- 사용자의 인증 상태를 서버에 저장하는 방식.
동작 원리
- 사용자가 로그인, 로그인 정보를 서버에 전달
- 로그인 정보가 유효하면, 서버는 고유한 세션 ID를 생성
- 이를 클라이언트(브라우저)로 전달
- 클라이언트는 이 세션 ID를 쿠키에 저장
- 요청마다 서버로 전달하여 인증 상태를 유지
장점
- 인증 정보를 서버에 저장하므로 클라이언트에 민감한 데이터가 노출되지 않는다.
- 서버에서 세션 데이터를 쉽게 제어(수정/삭제)할 수 있다.
단점
- 세션 정보를 서버 메모리에 저장하므로, 많은 사용자를 처리할 경우 서버에 가해지는 부담이 너무 크다.
- 로드 밸런싱이나 분산 서버 환경에서 세션을 동기화해야 하는 복잡성 문제 해결이 어렵다.
사용 사례
- 전통적인 MVC 기반 웹 애플리케이션(예: Spring, Ruby on Rails).
2) 쿠키(Cookie)
-
브라우저에 저장되는 작은 데이터 조각.
-
클라이언트-서버 간의 상태를 유지하거나 사용자 정보를 저장하는 데 사용.
동작 원리
Set-Cookie: sessionId=abc123; Path=/; HttpOnly; Secure; SameSite=Strict
- 서버는 클라이언트에게 쿠키를 설정 (HTTP 응답 헤더를 통해 쿠키를 설정)
- 클라이언트는 쿠키를 저장하고, 요청마다 해당 쿠키를 서버로 전송
- 서버는 쿠키를 읽어 인증 상태를 확인하거나 사용자 정보를 활용
장점
- 표준화된 방식: 대부분의 브라우저에서 기본적으로 지원.
- 간단한 구현: 설정과 사용이 간단.
단점
- 보안 위험: 민감한 정보를 쿠키에 저장하면 탈취될 위험이 있다. (따라서 HttpOnly, Secure, SameSite같은 보안 설정을 반드시 해주어야 한다.)
- 네트워크 오버헤드: 쿠키가 요청마다 포함되므로 대량의 데이터 전송 시 성능 저하.
HttpOnly, Secure, SameSite?
- 쿠키(Cookie)의 동작과 보안을 강화하기 위해 설정할 수 있는 중요한 속성들.
Set-Cookie: sessionId=abc123; HttpOnly
-
HttpOnly. 클라이언트의 JavaScript 코드에서 해당 쿠키에 접근할 수 없도록 설정.
- XSS(크로스 사이트 스크립팅) 공격 방지. 악성 스크립트가 브라우저에서 실행될 때 쿠키를 읽지 못하게 하여 탈취를 방지할 수 있다.
- HTTP 요청, Set-Cookie 헤더에서 설정할 수 있다. -
다만, 클라이언트 측 쿠키 접근이 필요한 경우 HttpOnly 속성이 적용되어 있으면 접근할 수 없으니 주의.
Set-Cookie: sessionId=abc123; Path=/; Secure
- Secure. 쿠키가 오직 HTTPS 연결에서만 전송되도록 설정.
- MITM(Man-In-The-Middle) 공격 방지. 공격자가 네트워크 트래픽을 감청하여 쿠키를 탈취하는 문제를 예방할 수 있다.
Set-Cookie: sessionId=abc123; Path=/; SameSite=Strict
-
SameSite. 쿠키가 어떤 URL 요청에서만 전송되는지 제어하는 속성.
-
같은 도메인에서만 전송할 수 있도록 하는 Strict.
-
같은 도메인 요청과 일부 크로스 사이트 요청(GET 요청)을 허가하는
Lax. -
모든 크로스 사이트 요청에서 쿠키가 전송할 수 있도록 하는 None 옵션이 제공된다.
사용 사례
- 세션 ID 저장.
- 사용자 설정(예: 다크 모드, 언어 설정).
- 광고 및 트래킹.
3) JWT (JSON Web Token)
- 인증 정보를 JSON 형식으로 인코딩한 토큰.
동작 원리
- 사용자가 로그인 정보를 제출
- 서버는 로그인 정보가 유효하다면 JWT를 생성하여 클라이언트로 전달
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"userId": 12345,
"role": "admin",
"exp": 1700000000
},
"signature": "HMACSHA256(header + payload)"
}- 클라이언트는 JWT를 LocalStorage, SessionStorage 또는 쿠키에 저장
- 이후 요청 시, 클라이언트는 JWT를 Authorization 헤더에 포함하여 서버로 전송
Authorization: Bearer 'JWT토큰'
- 서버는 JWT를 검증하고 요청을 처리.
장점
- 확장성: 서버에서 인증 상태를 저장하지 않아도 되므로, 분산 시스템에 적합.
- 자체 포함: JWT에 사용자 정보를 포함하므로 서버에 추가 조회 없이 처리 가능.
단점
- 보안 위험: JWT가 탈취되면 만료 전까지 악용될 수 있음.
- 해결 방법: 짧은 유효 기간 설정, HTTPS 사용, 탈취 시 즉시 무효화.
- 토큰 크기: 페이로드 데이터로 인해 크기가 커질 수 있음.
사용 사례
- SPA(Single Page Application) 인증.
- API 인증 및 권한 부여.
- OAuth 2.0에서의 액세스 토큰.
4) 웹 스토리지 (Web Storage)
-
클라이언트 측에서 데이터를 저장하기 위한 브라우저 제공 API.
-
LocalStorage와 SessionStorage 두 가지 유형이 있다.
LocalStorage:
브라우저를 닫아도 데이터 유지.
SessionStorage:
브라우저 탭을 닫으면 데이터 삭제.
동작 원리
localStorage.setItem("token", "abc123");
- 데이터를 키-값 쌍으로 저장.
const token = localStorage.getItem("token");
- 필요할 때 데이터를 가져온다.
장점
- 클라이언트 측에서 데이터를 빠르게 저장/조회 가능.
- 용량 제한(5~10MB)이 쿠키보다 큼.
단점
- 보안 위험: XSS 공격에 취약.
- 네트워크 요청과는 별개로 동작하므로 서버와 상태 동기화가 어려움.
사용 사례
- JWT 저장.
- 사용자 설정 및 임시 데이터 유지.
- SPA에서 상태 관리.
5. 나머지..
OAuth
-
소셜 로그인(예: "Google로 로그인", "Facebook으로 로그인").
-
사용자가 비밀번호를 공유하지 않고 제3자 애플리케이션에 자원 접근 권한을 위임하여 처리한다.
Multi-Factor Authentication (MFA)
-
여러 가지 인증 요소(예: 비밀번호 + OTP + 생체 정보)를 조합하여 인증하는 방식.
-
비밀번호, PIN, OTP, 인증 어플리케이션, 지문/얼굴/홍채 인식 등증.. 여러가지 방식을 조합한다.
