👻Background
- HTTP 통신 == Stateless Protocol (무상태 프로토콜)
- 서버로 가는 모든 요청이 이전 요청과 독립적으로 다뤄짐
- 각 HTTP 통신에 본인을 알릴 수 있는 정보를 제공해야함
자신을 알릴 수 있는 정보의 역할 => Session, Cookie, Token
👻Cookie🍪
🎃1. 동작방식
1) 사용자가 웹 사이트 접속 시, browser가 server로 요청 보냄
2) server는 모든 데이터, 페이지에 관한 정보 등을 담은 cookie🍪를 browser에 전달
3) browser는 이 cookie🍪를 저장
=> client 쪽에 정보를 저장
4) 이후 해당 웹사이트에 방문할 때마다 browser는 해당 cookie🍪를 포함한 요청을 server에 전송
=> server는 이 cookie🍪로 우리가 누군지 알아낼 수 있음!
🎃2. 동작방식 - 세부설명
1) client가 HTTP Request를 server에게 보냄
2) server에서 유효성(회원인지) 확인 후, cookie🍪를 생성하여 HTTP Response header에 넣어서 client에게 응답
3) client는 HTTP Response의 header에서 cookie🍪를 추출하여 저장
4) client가 Request하고 싶을 때, HTTP가 해당 cookie🍪를 찾아 header에 넣어서 server에게 전달
🎃3. 생명주기
1) Session Cookie🍪 (세션쿠키)
- 만료기간 없음
- 브라우저를 닫는 순간 삭제됨
2) Persistent Cookie🍪 (지속쿠키)
- 더 길게 유지 가능
- 디스크에 저장됨
- 브라우저를 종료 / 컴퓨터 재시작해도 남아있음
👻Session
- client와 server 간 연결이 활성화된 상태
- cookie🍪로만 인증수단을 가지면 보안상 문제 발생
=> session은 직접적인 정보 암호화
중요 정보는 server에, 그 정보에 접근할 수 있는 session ID만 client에 저장
🎃1. 동작방식
1) client가 HTTP Request를 server에게 보냄
2) server에서 유효성(회원인지) 확인 후, 고유 session ID를 cookie🍪에 저장하고 HTTP Response header에 넣어 client에게 응답
3) client는 HTTP Response header에서 이 cookie🍪를 추출하여 저장
4) client가 HTTP Request를 보낼 때, HTTP가 해당 cookie🍪를 찾아 header에 자동으로 넣어서 server에게 전송
5) server는 HTTP Request header에서 cookie🍪에 들어있는 session ID를 확인하고 통신
🎃2. Cookie와 비교
| 기준 | Cookie | Session |
|---|---|---|
| 저장위치 | client (브라우저, 디바이스) | server |
| 보안 | 취약 | 직접적인 정보 노출 X (비교적 보안성 높음) |
| 생명주기 | 브라우저 종료 시 유지 | 브라우저 종료 시 삭제 |
| 상대적 속도 | 빠름 | 느림 |
🎃3. 단점
- 유저가 늘어남에 따라 DB 저장 공간 확보 필요
- 서버 과부하
👻JWT (JSON Web Token)
- JSON 포맷으로 저장하는 web token
- 사용자 인증에 필요한 정보를 token에 담아, 암호화를 시켜 사용하는 인터넷 표준 인증 방식
- 자가수용적 방식 (self-contained) : 필요한 모든 정보를 자체적으로 가지고 있음 (별도로 세션 DB 필요 X)
- HTTP header에 포함을 시키거나 URL의 파라미터로 전달이 가능
🎃1. 구성요소
. 으로 구분되는 인코딩된 Header, Payload, Signature
1) Header
- 토큰의 타입(typ) 과 Signature에서 사용할 알고리즘(alg) 포함
2) Payload
- 인증을 위해 사용할 실제 정보 (claim) 포함
- BaseURL64로 인코딩됨
- 탈취 위험성 존재
key-value형식
| 요소 key 값 | 설명 |
|---|---|
| iss | 토큰 발급자 정보 (issuer claim) |
| sub | 토큰 제목 정보 (subject claim) |
| aud | 토큰 대상자 정보 (audience claim) |
| exp | 토큰 만료시간 정보 (expiration time claim) |
| nbf | 토큰 활성 날짜 정보 (not before claim) |
| iat | 토큰 발급 시간 정보(issued at claim) |
| jti | 토큰 식별자 정보 (JWT ID claim) |
3) Signature
- token을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드
- 위에서 인코딩된 header와 payload, secret key로 구성 (header의 알고리즘 기반)
생성된 토큰은 아래 형식을 따름:
{ "Authorization": "Bearer {생성된 토큰 값}", }
🎃2. 동작방식
1) 사용자가 ID와 Password를 입력하여 로그인
2) server에서 DB를 조회하여 유효성 (해당 회원의 존재여부) 검사
3) 존재할 경우, server에서 JWT의 secret key 사용하여 access token 발급하여 client에게 전달
4) 후 client가 인증이 필요한 요청마다 header에 access token 담아서 sever에게 요청
5) server는 client로부터 받은 token의 signature를 복호화해서 조작여부, 유효기간 등 확인
출처: https://velog.io/@fe_jungseok/Session-Cookie-vs-Token
https://dsc-sookmyung.tistory.com/313
