쿠키(Cookie), 세션(Session), 토큰(Token)의 차이점

쿠키, 세션 토큰의 필요성

: HTTP 통신은 요청과 응답이 종료되면 상태가 유지되지 않기 때문에 상태를 기억하기 위해 사용

: 클라이언트의 구분과 상태 확인을 위해 필요

 

 

 

쿠키 (Cookie)

: 서버가 클라이언트 측에 저장하고 싶은 정보로, 서버가 응답 헤더에 담아 보내면 클라이언트 (브라우저)는 이를 스토리지에 저장

: 클라이언트는 서버에 요청할 때마다 쿠키를 함께 서버에 전송

: 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트를 식별

 

 

 

세션 (Session)

: 비밀번호와 같은 인증 정보를 세션 저장소에 저장하고 이 데이터를 식별하기 위해 session id를 부여

: 이 세션 정보는 서버에 저장됨

 

 

 

 

쿠키와 세션

: 사용자 정보를 서버의 세션 저장소에 저장하고, 세션 ID를 생성

: 세션 ID를 HTTP 헤더에 담아 클라이언트에 전송

: 클라이언트 (브라우저)는 세션 ID를 포함한 쿠키를 저장

: 인증이 필요한 요청에 쿠키를 HTTP 패킷에 담아 서버에 요청

 

- 쿠키와 세션의 차이

: 세션은 서버에서 가지고 있는 클라이언트의 정보

: 쿠키는 서버에서 발급된 세션을 열기 위한 키를 포함한 인증에 필요한 정보

 

- 쿠키와 세션의 필요성

: 쿠키만으로 인증을 할 경우 HTTP 요청을 탈취하면 모든 정보를 가져올 수 있음

: 쿠키는 조작될 가능성이 있어 단독으로 인증에 사용할 경우 위험

: 보안과 관련없는 기능에는 유용하게 사용 가능

 

 

 

 

쿠키/세션 방식의 장단점

- 장점

: 쿠키가 담긴 HTTP 요청이 노출되더라도 쿠키에는 유의미한 값이 존재하지 않음 (중요한 정보는 서버 세션에 존재하기 때문)

: 고유의 ID 값을 발급 받기 때문에 일일이 데이터를 확인하지 않고 서버 자원에 접근 가능

 

- 단점

: 세선 하이재킹 공격 위험 (HTTPS를 사용해 패킷을 탈취해도 정보를 읽기 힘들게 하거나 세션에 유효시간을 부여하여 해결 가능)

: 서버에 추가적인 저장공간 필요 (세선 저장소 필요)

 

 

 

 

토큰 (Token)

: 보조 서비스를 통해 서버 요청을 확인하고, 확인이 완료되면 서버가 토큰을 발급하여 요청에 응답

: 액세스 계층을 하나 더 사용하는 것이기 때문에 도용과 침투가 어려움

: 서버에서 공간을 차지하지 않음

 

- 연결형 토큰

: 키, 디스크, 드라이브 및 기타 물리적 장치가 시스템에 연결되어 액세스를 허용

: USB 디바이스나 스마트카드가 이에 해당

 

- 비접촉형 토큰

: 디바이스와 서버의 연결 없이 가까운 거리에 있음으로써 인증

: MS의 매직링

 

- 분리형

: 디바이스가 다른 디바이스와 접촉하지 않고도 인증 가능

: 휴대전화를 이용한 인증

 

- 토큰의 인증절차

1. 요청: 클라이언트가 서버에 액세스 요청

2. 확인: 서버가 클라이언트의 액세스 가능 여부 확인

3. 토큰: 서버가 인증 디바이스와 통신. 확인 완료 후 토큰을 발급하여 클라이언트에 전달

4. 저장: 작업이 지속되는 동안 토큰이 클라이언트 (브라우저)에 저장됨

 

 

 

 

JWT Token (JSON Web Token)

: 인증에 필요한 정보들을 암호화 시킨 개방형 표준 토큰

: 클라이언트는 액세스 토큰을 HTTP 헤더에 실어 서버에 전송

: 토큰은 임의로 생성된 비밀번호와 같이 동작

: 제한된 수명을 가지며, 한번 만료된 토큰은 사용할 수 없음

 

- 헤더

: 데이터의 암호화 방식과 타입 등을 정의

: alg (서명에 사용하는 알고리즘)

: kid (서명에 사용하는 키를 식별하는 값)

 

- 페이로드

: 서버에서 보낼 데이터 (일반적으로 user의 id와 유효기간 등 포함)

 

- 서명 

: base64 방식으로 인코딩한 헤더, 페이로드, 비밀키의 조합

 

- 장점

: JSON으로 인코딩 하기 때문에 가볍고 접근성이 좋음

: 공개키와 개인키를 나누어 서명이 가능. HAMC 알고리즘을 사용한 암호화도 가능

: 웹 뿐만 아니라 모바일에서도 처리가 쉬우며 확장성이 뛰어남

: 세션/쿠키와 달리 발급 후 검증만 하기 때문에 추가 저장소가 필요하지 않음

 

- 단점

: 한 번 발급된 JWT에 대해서는 유효기간이 완료 될 때까지는 계속 사용이 가능

: 쿠키나 세션과 달리 토큰의 길이가 길어 인증요청이 많아 질수록 네트워크 부하 가중

: payload 자체는 암호화 되지 않기 때문에 민감정보 처리에 주의 필요

 

 

 

 

 

JWT 토큰의 보안전략

- 짧은 만료기한 설정

- Sliding Session

: 서비스를 지속적으로 이용하는 클라이언트에게 토큰 만료 기한을 늘려주는 방법

 

- Refresh Token

: 클라이언트의 로그인 요청 시 서버에서 만료기한이 더 긴 토큰을 전송하는 방법

: 새로운 토큰을 발급하고 검증하기 위해 서버에 별도로 토큰을 저장해야함

 

 

 

 

JWT 토큰의 인증절차

1. 사용자가 로그인을 요청

2. 서버에서는 계정 정보를 읽어 사용자를 확인한 후 사용자의 고유 ID 값을 부여하고 기타 정보와 함께 payload에 저장

3. JWT 토큰의 유효기간 설정

4. 암호화할 비밀키를 이용해 Access token 발급

5. 사용자는 Access token을 받아 브라우저에 저장한 후 인증이 필요할 요청마다 토큰을 헤더에 실어 서버로 전송

6. 검증이 완료되었을 때 payload를 디코딩하여 사용자 ID에 맞는 데이터를 가져옴

 

 

 

세션 / 쿠키 방식과 JWT 토큰의 차이

: 세션/쿠키 방식의 경우 세션 저장소에 사용자 정보를 저장하지만, JWT는 토큰안에 사용자의 정보를 저장

: 클라이언트 입장에서는 HTTP 헤더에 세션 ID나 토큰을 실어서 보낸다는 점에서 동일하지만 서버 입장에서는 인증을 위해 암호화를 한다와 별도의 저장소를 이용한다의 차이점이 존재

 

 

 

 

 

 

 

 

Refference

쿠키, 세션, 토큰의 차이점

Cookie, Session, Token 의 차이점

토큰 기반 인증란 무엇인가? | Okta Identity Korea

JWT(JSON Web Token)의 개념부터 구현까지 알아보기