HTTP 프로토콜 (Hypertext Transfer Protocol)
- 웹에서 데이터를 주고받기 위한 프로토콜
- 주로 웹 브라우저와 웹 서버 간의 통신을 담당
- 클라이언트-서버 모델을 기반
- 특징
- 비상태성(stateless) : 통신이 끝나면 상태를 유지하지 않는 특징
- 비연결성(connectionless) : 클라이언트가 요청 후 응답을 받으면 그 연결을 끊어버리는 특징
이를 보완하기 위해 세션, 쿠키 사용
세션(Session)
- 사용자 정보 파일을 서버 측에서 관리
- 서버는 세션 ID를 생성하여 클라이언트에게 전송하고, 클라이언트는 이를 쿠키에 저장하여 서버에 요청할 때마다 함께 전송
- 세션은 일정 시간 동안 유지되며, 사용자가 일정 시간 동안 활동하지 않으면 만료
동작방식
- 클라이언트 요청: 사용자가 웹 애플리케이션에 접속하여 로그인 등을 시도합니다.
- 세션 생성: 서버는 고유한 세션 ID를 생성하고, 해당 세션 ID를 클라이언트에게 쿠키를 통해 전송합니다.
- 세션 저장: 서버는 세션 ID와 관련된 데이터를 서버 메모리나 데이터베이스에 저장합니다.
- 세션 유지: 이후 클라이언트의 모든 요청에는 세션 ID가 포함되어 서버로 전송되고, 서버는 이 세션 ID를 통해 사용자의 상태와 데이터를 확인합니다.
- 세션 종료: 클라이언트가 로그아웃하거나 세션이 만료되면 서버는 해당 세션 데이터를 삭제합니다.
장점
- 보안성
- 서버에 저장되므로 클라이언트에서 직접 접근하거나 수정할 수 없어서 보안성↑
- 세션 타임아웃 기능을 통해 일정 기간 동안 사용자가 활동하지 않으면 자동으로 세션을 만료
- 데이터 용량 : 서버에 데이터를 저장하므로 상대적으로 더 큰 데이터 저장 가능
- 편리성 : 서버가 세션 ID를 관리하므로 클라이언트는 세션 ID를 요청에 포함시키는 것 외에 특별한 작업이 필요 없음
단점
- 서버 부하
- 세션 데이터는 서버의 메모리를 사용하기 때문에, 많은 사용자가 접속할 경우 서버의 메모리 사용량이 증가하여 성능 저하를 초래
- 서버가 세션을 관리하기 때문에 서버를 확장(예: 로드 밸런싱)할 때 세션 동기화 문제를 해결해야 함
- 의존성
- 세션 데이터가 서버에 저장되므로, 서버가 다운되거나 리부팅되면 세션 데이터가 손실될 수 있음
쿠키(Cookie)
- 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
- 서버가 클라이언트에게 전송하며, 클라이언트는 이후의 요청에 이 쿠키를 포함시켜 서버에 전송
- 클라이언트의 상태 정보를 로컬에 저장했다가 참조
- 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지
동작방식
- 클라이언트 요청: 사용자가 웹 애플리케이션에 접속합니다.
- 쿠키 설정: 서버는 클라이언트에게 쿠키를 설정하여 클라이언트 브라우저에 저장합니다.
- 쿠키 저장: 클라이언트 브라우저는 쿠키를 저장하고, 설정된 유효 기간 동안 이를 유지합니다.
- 쿠키 전송: 이후 클라이언트의 모든 요청에는 저장된 쿠키가 자동으로 포함되어 서버로 전송됩니다.
- 쿠키 읽기: 서버는 전송된 쿠키를 읽어 사용자 상태나 데이터를 확인합니다.
- 쿠키 만료: 쿠키의 유효 기간이 지나거나 클라이언트가 명시적으로 삭제하면 쿠키는 더 이상 전송되지 않습니다.
장점
- 확장성
- 쿠키는 클라이언트 측에 저장되므로 서버 부하가 적음
- 확장성이 필요한 대규모 애플리케이션에서 유리
- 로드 밸런싱 용이
- 서버 간 세션 동기화 문제가 없음
- 쿠키는 클라이언트 측에 저장되므로 서버 부하가 적음
- 영속성 : 유효 기간을 설정하여 브라우저가 종료된 후에도 데이터를 유지 가능
- 단순성 : HTTP 헤더를 통해 자동으로 서버와 주고받기 때문에 구현이 비교적 간단함
단점
- 보안 문제
- 쿠키는 클라이언트에 저장되므로, 클라이언트 측에서 접근 가능하고 수정될 수 있어 보안에 취약
- 데이터 제한
- 각 쿠키의 크기는 일반적으로 4KB로 제한
- 브라우저마다 저장할 수 있는 쿠키의 총 개수에도 제한이 있음
- 브라우저 의존성
- 일부 브라우저나 브라우저 설정에 따라 쿠키가 비활성화될 수 있으며, 이는 애플리케이션 기능에 영향을 줌
JWT(JSON Web Token)
- JSON 객체를 사용하여 정보를 안전하게 전송하기 위한 토큰 기반 인증 메커니즘
- 사용자의 인증 정보와 서버의 SecretKey로 서버가 생성한 Token
동작방식
- 클라이언트 인증: 사용자가 로그인하면, 서버는 사용자의 인증 정보를 확인합니다.
- JWT 생성: 인증이 성공하면, 서버는 사용자의 정보를 기반으로 JWT를 생성합니다. JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세 부분으로 구성됩니다.
- 헤더: 토큰 유형과 해싱 알고리즘을 명시합니다.
- 페이로드: 토큰에 담길 정보(클레임)를 포함합니다. 예: 사용자 ID, 권한 등.
- 서명: 헤더와 페이로드를 인코딩하고, 비밀 키를 사용해 서명합니다.
- 토큰 전송: 생성된 JWT를 클라이언트에게 전송합니다. 클라이언트는 이 토큰을 로컬 스토리지나 쿠키에 저장합니다.
- 요청 시 토큰 포함: 클라이언트는 이후 요청 시 JWT를 HTTP 헤더(일반적으로 Authorization 헤더)에 포함하여 서버에 전송합니다.
- 서버에서 검증: 서버는 받은 JWT의 서명을 검증하고, 페이로드의 정보를 바탕으로 사용자의 인증 및 권한을 확인합니다.
- 응답 전송: 검증이 성공하면 서버는 요청에 대한 응답을 클라이언트에게 전송합니다. 검증에 실패하면 오류 응답을 보냅니다.
장점
- 무상태성
- 서버에 세션 정보를 저장하지 않으므로, 서버가 무상태(Stateful)로 동작할 수 있음
- 확장성
- 서버 간의 세션 동기화가 필요 없기 때문에 서버 확장이 용이함.
- 보안성
- 토큰은 서명되어 있어 변조가 어렵고, 필요한 경우 암호화를 통해 추가적인 보안도 제공할 수 있음
- 유연성
- 다양한 클레임을 포함할 수 있어 사용자 정보와 권한 등을 자유롭게 담을 수 있음.
단점
- 만료 및 폐기 문제
- 한 번 발급된 토큰은 만료 전까지 유효하므로, 서버에서 임의로 폐기하기 어렵다.
- 토큰 크기
- JWT는 세션 ID보다 크기가 크기 때문에, 네트워크 대역폭과 클라이언트 저장 공간을 더 많이 차지할 수 있음.
- 보안 취약점
- 토큰이 클라이언트에 저장되기 때문에, 클라이언트 측의 보안이 취약할 경우 토큰이 유출될 위험이 있음.
세션 vs 쿠키 vs JWT 비교
| 구분 | 세션 | 쿠키 | JWT |
|---|---|---|---|
| 저장 위치 | 서버 | 클라이언트(브라우저) | 클라이언트(브라우저) |
| 보안 | 상대적으로 안전 (서버에 저장) | 비교적 취약 (클라이언트에 저장) | 중간 (클라이언트에 저장, 서명으로 변조 방지) |
| 데이터 용량 | 서버 메모리/디스크 용량에 따라 결정 | 브라우저마다 약 4KB로 제한 | 토큰 크기 고정, 정보가 많아지면 커질 수 있음 |
| 유지 기간 | 서버 설정에 따름 (사용자 활동 없으면 만료 가능) | 쿠키 설정 시 지정된 유효 기간 동안 유지 | 토큰의 유효 기간 동안 유지 |
| 성능 | 많은 사용자가 접속할 경우 서버 부하 증가 가능 | 클라이언트에 저장되어 서버 부하 적음 | 서버에 저장하지 않아 무상태성 유지, 성능 유리 |
| 확장성 | 서버 확장 시 세션 동기화 필요 | 클라이언트에 저장되어 서버 확장에 유리 | 무상태성으로 서버 확장에 매우 유리 |
| 설정 방법 | 서버 측 코드로 설정 및 관리 | 서버가 클라이언트에게 설정 명령, 클라이언트가 저장 | 서버에서 생성 후 클라이언트에 전달, 클라이언트가 저장 |
| 사용 예시 | 로그인 상태 유지, 쇼핑몰 장바구니 | 자동 로그인, 사용자 선호도 저장 | API 인증, 분산 시스템 인증 |
동작방식 요약
아뇨 소혠데요-