Session, Cookie, JWT

웹 인증(Web Authentication)이란 무엇인가?

웹 인증은 말 그대로 웹 서비스에서 요청을 보낸 사용자가 누구인지 확인하는 과정이다.
웹은 기본적으로 HTTP 위에서 동작하는데, 이 HTTP라는 구조가 무상태(Stateless) 라서 서버가 사용자를 기억하지 못한다.

즉, 한 번 요청을 보냈다고 해서 다음 요청에서도 같은 사람인지 알 수 없다. 그래서 인증이라는 절차가 꼭 필요해진다.

1. 왜 인증이 필요할까

서버는 기본적으로 “누가 요청을 보냈는지” 알 수 없다.
로그인한 사용자라 해도, 새 요청이 들어오면 그게 아까 그 사람인지 전혀 모른다. 그래서 매 요청마다 “이 사람이 정말 그 사용자 맞다”라는 증명이 필요하다.

만약 인증이 없다면 개인정보 조회, 글 수정, 결제 같은 기능은 안전하게 처리할 수 없다.
결국 웹 인증은 사용자를 식별하고, 그 상태를 유지하기 위해 사용되는 기술이다.

2. 인증(Authentication) vs 인가(Authorization)

두 용어는 비슷하게 들리지만 역할이 다르다.

인증(Authentication): 사용자가 누구인지 확인하는 과정
예) 아이디와 비밀번호로 본인임을 증명
인가(Authorization): 인증된 사용자가 어떤 기능을 사용할 수 있는지 결정
예) 관리자는 관리자 페이지 접근 가능, 일반 사용자는 불가능

누구인지를 확인(인증) → 그 사람의 권한 확인(인가)

3. 웹 인증이 해결하려는 문제

HTTP는 상태를 기억하지 않기 때문에 로그인 상태가 유지되지 않는다.
로그인을 했더라도 다음 요청에서 다시 사용자 여부를 확인해야 한다는 뜻이다.

그래서 서버와 클라이언트는 인증 정보를 계속 유지할 방법이 필요하다.
이때 사용되는 도구가 세션(Session), 쿠키(Cookie), JWT(Json Web Token) 같은 것들이다.

이 기술들은 모두 '인증 정보를 어떤 방식으로 유지하고 전달할 것인가'를 해결하기 위한 서로 다른 방법들이다.

HTTP 세션(Session)이란 무엇인가?

HTTP 세션은 서버가 사용자의 상태를 기억하기 위해 쓰는 저장 공간이다.
HTTP는 요청 간 상태를 기억하지 않기 때문에, 로그인처럼 “이 사용자는 인증된 사용자다”라는 정보를 유지하기 위해 세션이 필요하다.

1. 세션의 개념

세션은 서버가 만든 사용자 전용 저장 영역이며, 이를 식별하기 위해 세션 ID가 사용된다.
사용자가 로그인하면 서버는 세션을 만들고, 세션 ID를 클라이언트에 전달한다. 이후 요청마다 이 값을 보내면 서버는 같은 사용자임을 알 수 있다.

2. 동작 방식 요약

사용자가 로그인 시
서버는 인증 정보를 검증하고 세션 생성 → 세션 ID 발급
클라이언트는 쿠키에 세션 ID 보관
요청마다 세션 ID 자동 전송
서버는 ID를 기반으로 사용자 상태 확인

바로 이 세션ID를 Cookie 헤더로 보낸다.

Cookie: JSESSIONID=ABC123

3. 세션의 특징

중요한 정보는 서버에 저장되기 때문에 비교적 안전하다
구조가 단순해 대부분의 서버 프레임워크가 기본 제공한다
사용자 수가 많아지면 서버 메모리 부담이 커질 수 있다
HTTP Session은 Cookie를 사용하여 구현한다
사용자가 다시 접속하여도 유지된다

4. 현대 서비스에서 세션을 사용하지 않는 이유

서버가 세션 ID를 발행하고 해당 상태를 직접 저장해야 하는 구조(Stateful)라서 확장성이 낮다.
- 서버 A에 저장된 세션을 서버 B에서는 알 수 없음
- 세션을 중앙 저장소(Redis 등)에 공유해야 함 → 추가 인프라 필요
멀티 서버 환경에서는 세션 저장소를 공유하지 않으면 인증이 깨지기 때문에 별도 설정이 필수이다.
- 사용자 첫 요청은 1번 서버에서 로그인 → 세션 저장
- 다음 요청이 3번 서버로 가면 세션 정보가 없어 인증 실패
  → 그래서 세션 스티키(sticky session) 또는 Redis 세션 공유가 필요함
세션 방식은 서버가 사용자 상태를 기억하므로 서버가 늘어날수록 관리 비용이 증가한다.
- 서버 확장(Scale-out)이 복잡
- 서버 재기동 시 세션 유실 위험
- 세션 저장소가 병목(Bottleneck) 가능성
세션은 기본적으로 쿠키 기반이기 때문에 Cross-Domain 상황에서 제약이 많다.
- 쿠키는 기본적으로 동일 도메인에서만 전송됨
- 예:
  - 백엔드 → api.example.com
  - 프런트 → www.example.com
- 이런 구조에서는 SameSite, CORS, Secure, Domain 세팅 등 추가 설정이 많아 개발 복잡도가 올라감
현대 서비스 아키텍처는 Stateless(상태 없는 서버)를 선호한다.
- 서버가 인증 상태를 저장하지 않음
- 서버 증설/축소가 매우 쉬워짐
- 마이크로서비스, 모바일 앱, SPA(React/Vue) 환경에 잘 맞음
- JWT 같은 토큰 기반 인증이 이런 구조에 적합함

HTTP 쿠키(Cookie)란 무엇인가?

HTTP 쿠키는 서버가 클라이언트(브라우저)에 저장시키는 작은 데이터이며,
HTTP의 무상태(Stateless) 특성을 보완하여 사용자의 상태나 설정을 유지하기 위해 사용된다.

쿠키는 로그인 유지, 자동 로그인, 장바구니, UI 설정 저장 등
사용자 경험을 지속하기 위해 널리 사용된다.

1. 쿠키의 개념

쿠키는 서버가 클라이언트에 전달하여 저장시키는 데이터로,
브라우저는 이후 요청마다 이 쿠키 값을 자동으로 서버에 포함해 전송한다.

쿠키는 아래와 같은 용도로 활용된다.

로그인 상태 유지(세션 ID 저장)
자동 로그인 토큰 저장
언어/테마 같은 설정값 저장
광고/트래킹 정보 저장

중요한 점은 쿠키는 클라이언트 측에 저장되므로 수정 가능성이 있다는 것이다.
따라서 민감한 정보를 직접 저장해서는 안 된다.

2. 동작 방식 요약

서버가 사용자 검증 후 Set-Cookie 헤더로 쿠키를 클라이언트에게 전달한다
브라우저는 이 쿠키를 저장한다
이후 모든 요청에 쿠키를 자동으로 포함한다
서버는 쿠키 값을 기반으로 사용자를 식별하거나 설정을 적용한다

3. 쿠키의 특징

쿠키는 클라이언트(브라우저)에 저장되며 서버 메모리를 사용하지 않는다
만료 시간 설정이 없으면 브라우저 종료 시 삭제된다
Domain, Path, Secure, HttpOnly, SameSite 등 다양한 보안 옵션 설정이 필요하다
브라우저는 쿠키를 자동 전송하므로 편리하지만, 그만큼 보안상 주의가 필요하다
HTTP Session은 쿠키를 통해 동작한다 (세션 ID를 쿠키에 저장하는 방식)

4. 현대 서비스에서 쿠키 기반 인증을 사용하지 않는 이유

Cross-Domain 제약이 크다
쿠키는 기본적으로 동일 도메인에서만 자동 전송된다.
예시:
- 백엔드 → api.example.com
- 프런트 → www.example.com 이 경우 쿠키를 전송하려면 추가 설정이 필요
쿠키 기반 인증은 Stateful 구조와 결합되기 쉽다
쿠키는 세션 ID 저장 방식과 함께 사용되는 경우가 많아 서버가 인증 상태를 직접 관리하게 된다.
이는 서버 확장성에 불리하고, 멀티 서버 환경에서는 세션 저장소 공유가 필요해 구조가 복잡해진다.
SPA(React/Vue)·모바일 앱·마이크로서비스 환경에 적합하지 않다
쿠키 자동 전송 방식은 도메인·프로토콜 구성이 복잡한 최신 웹 구조에서는 비효율적이다.
Authorization 헤더 기반 인증(JWT 등)이 더 유연하게 동작한다.
보안 설정을 잘못하면 공격 위험이 커진다CSRF 등 쿠키 기반 공격에 대비하기 위한 설정이 필요하며, 옵션 조합을 실수하면 취약해질 수 있다.

HTTP JWT(Json Web Token)란 무엇인가?

JWT(Json Web Token)는 서버가 사용자를 인증하기 위해 발급하는 서명된 토큰이며,
HTTP의 무상태(Stateless) 특성을 유지하면서 로그인 상태를 확인하거나 권한을 증명하기 위해 사용된다.

JWT는 모바일 앱, SPA(React/Vue), 마이크로서비스, 서버 간 통신 등
현대 웹 구조에서 인증·인가를 처리하는 방식으로 널리 사용된다.

1. JWT의 개념

JWT는 사용자의 인증 정보와 메타데이터를 포함하는 문자열 토큰이며,
클라이언트가 이 토큰을 저장해두었다가 HTTP 요청 시 Authorization 헤더에 포함해 서버로 전송한다.

JWT는 아래와 같은 목적으로 활용된다.

로그인 상태 유지 (Access Token)
자동 로그인(Refresh Token)
API 요청 시 사용자 인증
권한(ROLE) 정보 전달
서버 간 통신 인증

JWT는 자체적으로 서명(Signature)이 있기 때문에 토큰이 위조되지 않았음을 서버가 검증할 수 있다는 점이 핵심이다.
단, 인코딩된 것이지 암호화된 것은 아니므로 민감한 정보를 넣어서는 안 된다.

2. JWT의 구조

// JWT는 3개의 조각을 “점(.)”으로 이어붙인 문자열(HEADER.PAYLOAD.SIGNATURE)
// Header (헤더) Base64Url 인코딩
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload (페이로드) Base64Url 인코딩
// eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

// Signature(서명) 헤더 + 페이로드를 이어붙이고(secret key로 암호학적 서명을 한 값)
// SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
HMACSHA256(
    base64UrlEncode(header) + "." + base64UrlEncode(payload),
    SECRET_KEY
)

// JWT
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

3. 동작 방식 요약

사용자가 로그인 정보를 서버에 전달한다
서버는 사용자 인증 성공 시 JWT를 생성해 클라이언트에 전달한다
클라이언트는 이 JWT를 저장한다 (브라우저, 앱, 로컬스토리지 등)
이후 요청마다 Authorization 헤더에 JWT를 포함한다
Authorization: Bearer <JWT>
서버는 서명(Signature)을 검증해 토큰이 위조되지 않았는지 확인하고,
토큰 내부 정보(사용자ID, 권한 등)를 기반으로 인증을 처리한다

4. JWT의 특징

서버가 인증 상태를 저장하지 않으므로 Stateless 구조를 유지할 수 있다
토큰 자체에 사용자 정보가 포함되므로 서버 확장(Scale-out)에 유리하다
Authorization 헤더로 전달되기 때문에 Cross-Domain 구조에서도 설정이 단순하다
기본적으로 인코딩(Base64Url)일 뿐 암호화가 아니므로 민감 정보는 넣을 수 없다
토큰이 길어질수록 네트워크 오버헤드가 증가할 수 있다
Access Token은 짧은 만료시간, Refresh Token은 긴 만료시간을 두어 함께 사용한다

5. JWT를 사용하는 이유

JWT는 토큰 자체에 필요한 정보를 담아두기 때문에 Stateless 구조를 유지할 수 있다.

이 방식은 서버 확장성, 배포 편의성, 다양한 클라이언트 환경에서 큰 장점을 제공한다.

JWT를 사용하는 주요 이유는 다음과 같다.

서버가 인증 상태를 저장하지 않으므로 확장성이 높다
(여러 서버가 동일 토큰만 검증하면 되기 때문에 멀티 서버 환경에 적합하다)
Authorization 헤더 기반이므로 Cross-Domain 환경에서 설정이 단순하다
(세션/쿠키처럼 SameSite, Secure, Domain 설정이 필요하지 않다)
모바일 앱, SPA(React/Vue), 마이크로서비스 등
쿠키 자동 전송이 어려운 환경에서도 일관된 인증 방식을 제공한다
토큰 자체에 사용자 정보와 권한이 포함되어 있어
API 서버들이 별도로 세션 저장소를 조회할 필요가 없다
Access Token과 Refresh Token 구조를 활용하여보안성과 사용자 편의성을 동시에 확보할 수 있다

6. JWT 장단점

장점

토큰 기반 인증 방식이므로 서버 측에서 별도의 세션 저장소를 유지할 필요가 없다.
(Stateless 구조)
JSON 형식으로 인코딩되므로, 다양한 플랫폼 간에 쉽게 전송되고 구현하기 쉽다.
Signature를 사용하여 무결성을 보장한다.
토큰이 변조되었는지 여부를 쉽게 검증할 수 있다.
(Header + Payload + Secret 으로 생성된 HMAC 해시를 비교하는 방식)

단점

JWT의 크기가 커질 경우 네트워크 대역폭이 증가한다.
(세션 ID보다 훨씬 길기 때문에 트래픽 부담이 증가 가능)
JWT는 한 번 발급된 후 내부 정보를 수정할 수 없다.
따라서 만료 시간을 짧게 설정해야 보안성을 유지할 수 있다.
JWT가 탈취당하면 해당 토큰을 사용해 모든 요청이 인증된다.
(Signature는 위조 방지만 가능, 탈취 방지는 못함)
따라서 HTTPS 같은 보안 프로토콜을 필수로 사용해야 한다.

관련 라이브러리 확인 https://www.jwt.io/libraries

JSON Web Token Introduction - jwt.io

Learn about JSON Web Tokens, what are they, how they work, when and why you should use them.

www.jwt.io

저작자표시 비영리 변경금지 (새창열림)

'IT > JAVA' 카테고리의 다른 글

Collection Framework - Map / JAVA (0)	2026.01.05
Collection Framework - List / JAVA (0)	2026.01.05
Collection Framework - Set / JAVA (0)	2026.01.01
Stack, Queue / JAVA (0)	2026.01.01

IT-centralpark