쿠키와 세션의 차이점
| 쿠키(Cookie) | 세션(Session) | |
|---|---|---|
| 저장 위치 | 클라이언트(=접속자 PC) | 웹 서버 |
| 저장 형식 | text (key-value) | Object |
| 만료 시점 | 쿠키 저장시 설정(만료 시간 기준) | 브라우저 종료시 삭제(기간 지정 가능) |
| 사용하는 자원(리소스) | 클라이언트 리소스 | 웹 서버 리소스 |
| 용량 제한 | 총 300개하나의 도메인 당 20개하나의 쿠키 당 4KB(=4096byte) | 서버가 허용하는 한 용량제한 없음. |
| 속도 | 세션보다 빠름 | 쿠키보다 느림 |
| 보안 | 세션보다 안좋음 | 쿠키보다 좋음 |
Cookie
(”클라이언트”에 저장)
스프링부트 게시판을 만들며 로그인 기능을 제일 먼저 구현하게 되었는데 여기서 로그인을 구현하는데에는 여러 가지 방법이 있다는 것을 알게됨
그 중에 하나가 cookie로 데이터를 받아 저장해두었다가 전송하는 방식
- Cookie는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각으로, key=value 형식의 문자열 데이터 묶음
- 브라우저는 이 데이터 조각을 저장해두었다가 동일한 서버에 재요청 시 쿠키 데이터를 전송할 수 있음
- HTTP 프로토콜은 기본적으로 무상태성을 지니기에 서버와 클라이언트 간의 연결 유지를 구현하고자 할 때 서로를 인식할 수 있는 식별데이터가 필요함 → 쿠키 데이터 조각
쿠키 활용 ⇒ 세션관리, 개인화, 트래킹
- 세션관리 → 서버에 저장할 정보 관리
- 개인화 → 사용자의 개인세팅을 저장 및 관리
- 트래킹 → 웹사이트 내 사용자 행동 기록 및 관리
쿠키 인증방식
- 클라이언트 → 서버 요청
- 서버는 클라이언트측에 저장할 정보를 응답 헤더의 Set-Cookie에 담음
- 이후 클라이언트는 요청을 보낼 때마다, 매번 저장된 쿠키를 요청 헤더의 Cookie에 담아 보냄
쿠키 인증방식의 단점은?
- 보안 취약 → 요청시 쿠키의 값을 그대로 보내기 때문에 조작 당할 수 있음
- 용량 제한이 있어 많은 정보를 담을 수 없음
- 웹브라우저마다 쿠키 지원 형태가 다르므로 브라우저 간 공유 불가능
- 쿠키 사이즈가 커지면 네트워크 과부하
Session
(”서버”에 저장)
보안에 취약한 쿠키의 단점을 보완
비밀번호, 카드번호 등 중요한 정보는 서버측에서 관리함
로그인 요청 성공시 서버는 세션ID를 서버에 저장해두고 클라이언트는 브라우저의 세션ID를 저장
서버는 다음 요청이 들어오면 쿠키의 세션ID의 유효성 검사를 하는 방식
즉, 세션도 쿠키가 필요함
세션 인증방식
- 사용자가 로그인 요청
- 서버에서 계정 정보를 읽어 사용자를 확인(인증), 사용자의 고유한 id를 부여하여 세션 저장소에 저장한 후, 이와 연결된 세션id를 발급(인가)
- 사용자는 서버에서 해당 세션id를 받아 쿠키에 저장한 뒤, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냄
- 서버는 쿠키를 받아 세션 저장소에서 대응되는 정보를 가져옴
- 인증이 완료되면, 서버는 사용자에 맞는 데이터를 보내줌
세션 인증방식의 단점은?
- 쿠키를 포함한 요청이 외부에 노출되더라도 세션id자체에는 유의미한 개인정보를 담고있지 않으나, 탈취자가 세션 id 자체를 탈취하여 클라이언트인 척 위장할 가능성 있음
- 서버에서 세션 저장소를 사용하므로, 요청이 많아지면 서버 과부하
Token
클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 ‘토큰’부여
- 기존 세션인증은 파일이나 db에 세션 정보를 가지고 있어야 해서 많은 오버헤드가 발생했지만, 토큰은 그와 달리 클라이언트에 저장되므로 서버의 부담을 줄일 수 있음
- 토큰 자체에 데이터가 들어있으므로 클라이언트에서 받아 위조되었는지 판별만 하면 되기 때문
토큰 인증방식
- 로그인
- 서버측에서 사용자에게 유일한 토큰 발급해줌
- 클라이언트는 토큰을 쿠키나 스토리지에 저장해두고, 서버에 요청을 할때마다 해당 토큰을 HTTP요청 헤더에 포함시켜 전달
- 서버는 전달받은 토큰을 검증하고 요청에 응답 (서버는 db를 조회하지 않고 누가 요청했는지 알 수 있게 됨)
토큰 인증방식의 단점은?
- 쿠키 / 세션과 달리 토큰 자체 데이터 길이가 길어서 인증요청이 많아지면 네트워크 과부하
- Payload 자체는 조회가 가능하기에 유저의 중요한 정보를 담을 수 없게 됨
- 토큰은 발급 시 만료될 때까지 사용할 수 있기 때문에 토큰을 뺏기면 대처가 어려움
JWT (JSON Web Token)
인증에 필요한 정보들을 암호화시킨 JSON토큰
- 세션 / 쿠키와 함께 가장 대표적인 인증수단으로,
- JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식
- JSON 데이터를 Base64 URL -safe Encode를 통해 인코딩을 직렬화한 것이며, 토큰 내부에는 위조 방지를 위해 개인키를 통한 전자서명도 있음
- 따라서 사용자가 JWT로 서버를 전송하면 서버는 서명을 검증하는 과정을 거친 뒤 요청한 응답을 돌려줌
JWT 구조
. 을 기준으로 Header, Payload, Signature를 의미함
- Header : JWT에서 사용할 타입, 해시 알고리즘 종류
- Paylaod : 서버에서 첨부한 사용자 권한 정보와 데이터
- Signature : Header, Payload를 Base64 URL -safe Encode를 한 이후 Header에 명시된 해시함수를 적용하고, 개인키로 서명한 전자서명이 담겨있음
JWT 인증방식
- 로그인
- 서버에서 사용자 확인후 고유 id부여, 기타 정보와 함께 Payload에 넣음
- JWT 유효기간 설정
- 비밀키를 이용해 Access Token 발급
- 사용자는 Access Token을 받아 로컬 스토리지(쿠키)에 저장하고 인증이 필요한 요청마다 토큰을 헤더에 실어서 보냄
- 서버에서 해당 토큰의 서명을 복호화한 후 조작여부 및 유효기간 확인함
- 검증 완료되면, Payload를 디코디앟여 사용자 ID에 맞는 데이터를 가져옴
JWT 인증방식의 장점은?
- 데이터 위/변조 막을 수 있음
- 인증정보에 대한 별도 저장소 필요없음
- 다른 로그인 시스템에 접근 가능(Facebook, Google로그인 등)
- 발급 후 검증만 하면 되기에 Stateless한 서버를 만들기에 적합함
JWT 인증방식의 단점은?
- 이미 발급된 JWT는 돌이킬 수 없으므로 악의적으로 이용될 시 유효기간이 지나기 전까지 정보를 털어갈 수 있음 → 기존의 Access Token의 유효기간을 짧게 하고 “Refresh Token”이라는 새로운 토큰 발급
- Payload의 정보가 제한적이고 디코딩하면 누구나 정보를 확인할 수 있음
- 인증이 필요한 요청이 많을수록 자원낭비 발생
Refresh Token
→ Spring Security
참고자료
https://jhbljs92.tistory.com/entry/1-JWT-토큰-인증과-쿠키-세션-토큰
https://velog.io/@rlafbf222/인증-인가-쿠키-세션-Spring-Security-항해일지-17일차
https://jangjjolkit.tistory.com/26
백엔드 개발하는 사람