❓왜 등장했을까?
HTTP(Hyper Text Transfer Protocol)은 하이퍼텍스트를 전송하는 규약이다.
HTTP의 특징은 비연결성과 무상태성이다.
client가 server에 request를 보내고 서버가 해당 요청에 맞는 response를 보내면 바로 연결을 끊는다.
연결을 끊는 순간 client와 server의 통신은 끝나며 상태 정보를 유지하지 않는다.
이러한 특징 때문에 서버는 클라이언트가 누구인지 매번 확인이 필요하다
이를 해결하기 위해 쿠키와 세션이 등장했다.
🍪 Cookie
사용자의 컴퓨터에 저장하는 작은 기록 정보 파일
HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요 시 정보를 참조하거나 재사용 가능
흐름
- 서버는 클라이언트의 로그인 요청에 대한 응답 작성 시, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 Set-Cookie에 담아 전달
- 쿠키는 Key-Value 형식으로 저장
- 이후 클라이언트는 요청을 보낼 때마다 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 전송
- 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별
단점
보안에 취약
- 요청 시 쿠키의 값을 그대로 전송
- 유출 및 조작 당할 위험이 존재
용량 제한
- 쿠키에는 용량 제한이 있어서 많은 정보를 담을 수 X
웹 브라우저마다 쿠키에 대한 지원 형태 다름
- 브라우저 간 공유가 불가능
쿠키의 사이즈가 커질수록 네트워크 부하 심해짐
🔗 Session
쿠키의 단점인 유출 및 조작 위험을 해결하기 위해 세션이 등장
일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 유지시키는 기술
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라 함
기존에 쿠키에 저장된 사용자의 정보를 서버에 저장하고 관리
그 때 생성되는 id를 쿠키에 담아서 전달
흐름
HTTP/1.1 200
Set-Cookie: JSESSIONID=FDB5E30BF20045E8A9AAFC788383680C;
- 사용자 정보를 서버의 메모리에 저장하고 그 때 생성되는 id를 쿠키에 담아 전달
- 클라이언트가 요청을 보낼 때 쿠키에 있는 id를 전달
- 서버는 id의 유효성을 판별해 클라이언트를 식별
- Session의 정보는 사용자가 브라우저를 종료하면 삭제
장점
쿠키를 포함한 요청이 외부에 노출되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 X
각 사용자마다 고유한 세션 ID가 발급 → 요청이 들어올 때마다 회원정보 확인할 필요 X
단점
서버에 저장되므로 서버의 자원을 사용하기 때문에 요청이 많아지면 서버에 부하가 심해짐
해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없음(세션 하이재킹 공격)
🚩 Cookie vs Session
| 쿠키 | 세션 | |
| 저장 위치 | 클라이언트 (=접속자 PC) | 웹 서버 |
| 저장 형식 | text | Object |
| 만료 시점 | 쿠키 저장시 설정 (브라우저가 종료되도, 만료시점이 지나지 않으면 삭제되지 않음) |
브라우저 종료시 삭제(기간 지정 가능) |
| 사용하는 자원 | 클라이언트 리소스 | 웹 서버 리소스 |
| 용량 제한 | 총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB (=4096byte) |
서버가 허용하는 한 용량 제한 없음 |
| 속도 | 세션보다 빠름 | 쿠키보다 느림 |
| 보안 | 세션보다 안좋음 | 쿠키보다 좋음 |
💳Token 인증
인증 받은 사용자에게 토큰을 발습하고 로그인이 필요한 작업일 경우 헤더에 토큰을 함께 보내 인증받은 사용자인지 확인
상태 정보를 서버에 저장하지 않아 Stateless한 구조
세션기반 인증은 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 Stateful한 구조이다.
이는 사용자가 증가함에 따라 성능의 문제를 일으킬 수 있으며 확장성이 어렵다는 단점을 가졌다.
그래서 이러한 단점을 극복하기 위해 토큰 기반 인증이 등장했다.
Token 인증 방식
- 사용자가 로그인하면 서버는 사용자 정보를 기반으로 토큰 생성
- 생성된 토큰은 client에게 전달되고, client는 이후 요청 시 토큰을 서버에 함께 전송
- 서버는 토큰을 검증하여 사용자의 인증 및 권한을 확인
특징
- 무상태성(Stateless) : 토큰 자체에 필요한 정보를 담고 있어 저장하지 않고 처리 가능
- 확장성 : 서버는 토큰 검증만 수행하면 되므로 여러 서버에서 동일한 토큰을 처리 가능
- 보안성 : 토큰은 암호화되어 있어 안전하게 정보 전달
종류
- JWT (JSON Web Token) : JSON 형식으로 정보를 담고 있는 토큰, 가장 많이 사용됨
- OAuth 토큰 : 다른 서비스의 API에 접근할 수 있는 권한을 부여하는 토큰
장점
- 서버의 부담을 줄여줌
- 다양한 환경에서 사용하기 적합
- 보안성이 높음
단점
- 토큰을 탈취당하면 대처하기 어렵다
- 토큰 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있다
- Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다
🔑JWT (JSON Web Token)
인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.
쿠키/세션 방식과 유사하게 JWT 토큰 (Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별한다.
JWT 구조
JWT는 . 을 구분자로 나누어지는 3가지 문자열의 조합이다.
Header
- JWT에서 사용할 타입과 해시 알고리즘의 종류가 담겨있다.
Payload
- 서버에서 첨부한 사용자 권한 정보과 데이터가 담겨있다. (Claim)
- 실제로 사용될 정보에 대한 내용을 담고 있다.
- Claim 이란, key-value 형식으로 이루어진 한 쌍의 정보를 말한다.
Signature
- 인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성
- Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화 할 수 X
- Signature은 토큰의 위변조 여부를 확인하는데 사용
❓쿠키가 불가능한 상황에서 세션을 사용하는 방법
일반적으로 세션은 쿠키를 사용하여 세션 ID를 클라이언트에게 전달하고 클라이언트는 이 ID를 통해 서버에 저장된 세션 정보를 요청합니다. 따라서 쿠키가 없으면 세션 ID를 전달할 방법이 없어 세션을 사용할 수 없는 것처럼 보여집니다.
B.U.T URL의 파라미터로 값을 전달하여 세션을 유지할 수 있습니다.
- 세션 ID를 URL의 파라미터로 포함시켜 서버에 전달하는 방식
- ex) www.example.com/page?sessionid=12345와 같이 URL 뒤에 세션 ID를 추가
- 이 방법은 간단하지만 URL이 노출될 경우 보안에 취약
❓ 요청이 많이 몰렸을 때, 어떻게 처리하는 것이 좋을까요? (쿠키vs 세션)
세션으로 처리하는 것이 좋습니다.
쿠키는 클라이언트 측에 데이터를 저장하므로 요청이 많아지면 클라이언트의 부하가 증가할 수 있다.
세션은 서버 측에 대이터를 저장하므로 요청이 많아져도 서버에서 효율적으로 데이터를 관리하고 분산 처리할 수 있다.
❓ 세션 기반 인증과 토큰 기반 인증의 차이
세션 기반 인증 : client로부터 요청을 받으면 client의 상태 정보를 저장하므로 stateful한 구조를 가짐
토큰 기반 인증 : 상태 정보를 서버에 저장하지 않으므로 stateless한 구조를 가짐
❓ 세션 기반 인증과 토큰 기반 인증은 각각 어느 경우에 적합한가?
세션 기반 인증: 단일 도메인 또는 서브 도메인 환경에서 적합
토큰 기반 인증 : 다중 도메인, 모바일 앱, API 서버 등 다양한 환경에서 적합
세션 기반 인증에서 쿠키를 사용하여 다른 도메인 간에 세션을 공유하려고 하면 CORS 문제 발생 가
참고
https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/
'CS > 네트워크' 카테고리의 다른 글
| Proxy Server (프록시 서버) (0) | 2025.02.28 |
|---|---|
| SOAP(Simple Object Access Protocol) (0) | 2025.02.27 |
| REST (2) | 2025.02.25 |
| HTTPS (0) | 2025.02.24 |
| HTTP 진화과정 (0) | 2025.02.21 |