쿠키 대 세션 대 jwt


12

웹 응용 프로그램의 인증 / 권한 부여에 대해 읽고 있습니다. 아무도 내 현재 지식을 확인 / 수정할 수 있습니까?

  • 쿠키 : 초기 버전에서 고유 한 클라이언트 ID가있는 텍스트 파일 및 클라이언트에 필요한 기타 모든 정보 (예 : 역할)

  • 세션 : 고유 한 클라이언트 ID 만 파일 (쿠키라고도 함)로 전송되며 다른 모든 것은 서버에 저장됩니다.

  • JWT : 모든 것이 토큰에 저장됩니다 (쿠키라고도하는 텍스트 파일에 저장 될 수도 있음).

의견을 보내 주셔서 감사합니다!

답변:


12

쿠키 : 초기 버전에서는 고유 한 클라이언트 ID가 포함 된 텍스트 파일 및 클라이언트에 필요한 기타 모든 정보 (예 : 역할)

쿠키는 key-value원래 클라이언트 활동과 관련된 데이터 를 유지 하기 위해 해결 된 튜플 입니다. 이 보존세션 또는 응용 프로그램 상태라고 합니다. 기본적으로 웹 응용 프로그램의 상태를 유지하기 위해 만들어졌습니다. 보다 구체적으로, 클라이언트 측의 상태. (1)

쿠키는 일반적으로 서버에서 응답 헤더 ( Set-Cookie key=value) 를 통해 설정합니다 . 그러나 클라이언트에서도 설정할 수 있습니다. 예를 들어 DOM ( document.cookie)을 기준으로합니다.

쿠키에 대해 알아야 할 중요한 것은 쿠키가 사용자를 식별하지 않는다는 것입니다. 그들은 오히려 terna data-client-server / path를 연관시킵니다 . (삼)

우리는 일반적으로 웹 브라우저의 초기에는 쿠키를 유지해야했기 때문에 쿠키를 파일과 연결합니다. 오늘날의 브라우저는 쿠키를 로컬 스토리지 (내장 DB)에 저장합니다.

세션 : 고유 한 클라이언트 ID 만 파일 (쿠키라고도 함)로 전송되며 다른 모든 것은 서버에 저장됩니다.

세션별로 서버 세션 을 의미한다고 생각 합니다 . 내가 언급했듯이 세션은 클라이언트 측에서도 구현 될 수 있습니다. 클라이언트 측 세션과의 차이점은 데이터가 서버 측 어딘가에 저장된다는 것입니다. (2) 그러한 시나리오에서 우리가 얻는 것은 세션 ID입니다. 쿠키 형태로 얻습니다. 세션 ID가 없으면 서버는 들어오는 요청을 클라이언트의 이전 활동과 연관시킬 수 없습니다. (3) 예를 들어, 인증 된 사용자, 쇼핑 카트 등

어쨌든 세션 ID가 반드시 사용자를 식별하지는 않습니다. 특정 응용 프로그램 상태를 웹 클라이언트와 연결합니다. 세션은 사용자 데이터를 포함하거나 포함하지 않을 수 있습니다.

분산 응용 프로그램에서는 명백한 이유로 세션을 직렬화 할 수 있어야합니다. 메모리에 저장되어 있으면 메모리 내 저장 장치 (구성 요소)를 직렬화 할 수 있어야합니다. 일반적인 해결책은 세션을 파일에 저장하는 것입니다. 또는 Redis와 같은 NoSQL DB에서.

보안 관련. 서버 측 세션은 클라이언트 측보다 안전합니다. 일반적으로 사용자는 자신이 노출 된 위협을 알지 못하기 때문에 위협에 더 취약합니다. 최소한 일반 사용자는 아닙니다.

반면에 서버 측 인프라를 공격하는 것은 쉽지 않습니다.

JWT : 모든 것이 토큰에 저장됩니다 (쿠키라고도하는 텍스트 파일에 저장 될 수도 있음).

실제로는 아닙니다. JWT는 주로 토큰의 인증 및 발행자와 관련된 데이터를 저장합니다.

사용자 ID (하위)를 포함하기 위해 사용하지만 인증 된 사용자를 식별하지 않는 JWT를 찾습니다. 예를 들어 게스트 세션에 대한 토큰입니다. JWT의 주요 내용은 클레임입니다 . 인증 과정에서 확인할 항목

JWT는 글로벌 스토리지가 아니라는 점을 명심해야합니다 . 세션 또는 응용 프로그램 상태는 아직도 어딘가에 저장하고 독립적으로 관리되어야한다.

JWT와 관련하여 쿠키는 로컬 스토리지에도 저장 될 수 있지만 종종 쿠키로 저장됩니다. 또한 OWASP 커뮤니티는 sessionStorage 웹 브라우저에 더 안전한 것으로 간주 합니다. 그러나 브라우저 버전에 따라 다릅니다 .


1 : 월드 와이드 웹은 무국적자입니다. 상태 비 저장 서버 측 애플리케이션을 구축하려면 세션을 클라이언트 측 어딘가에 저장해야합니다.

2 : 서버 측 응용 프로그램을 상태 저장 응용 프로그램으로 전환

3 : 사용자가 아닌 응용 프로그램으로 클라이언트.


기본 Ruby on Rails 설정과 같은 일부는 전체 "세션"객체를 쿠키에 저장합니다 (일반적으로 암호화 된 날) user_id. 로그인 한 사용자 와 같은 것을 포함 할 수 있습니다 .
Fire Lancer

7

쿠키 : 초기 버전에서는 고유 한 클라이언트 ID가 포함 된 텍스트 파일 및 클라이언트에 필요한 기타 모든 정보 (예 : 역할)

쿠키에 대한 정의는 실제로 그들이하는 일을 설명하지 않습니다. 쿠키는 Set-Cookie서버가 HTTP 응답 헤더 ( ) 를 통해 설정 하고이를 지원하는 클라이언트가 저장 하는 키-값 쌍입니다 . 쿠키가 Cookie만료되지 않은 동안 쿠키, 스키마, 호스트, 경로, https와 일치하는 요청에 대한 쿠키는 후속 요청과 함께 헤더 로 다시 전송됩니다 . 쿠키에 원하는 것을 저장할 수 있으며 HTTP의 상태 비 저장 프로토콜에서 상태를 지원할 수 있습니다.

쿠키 교환의 예는 다음과 같습니다.

여기에 이미지 설명을 입력하십시오

세션 : 고유 한 클라이언트 ID 만 파일 (쿠키라고도 함)로 전송되며 다른 모든 것은 서버에 저장됩니다.

맞습니다. 세션은 서버 측에 사용자의 현재 세션에 대해 저장되는 데이터입니다. HTTP와 같은 상태 비 저장 프로토콜에서이 작업을 수행하려면 사용자가 각 요청과 함께 세션 ID를 보내야 서버가 사용자에 대한 올바른 세션을 가져올 수 있습니다. 세션 ID는 일반적으로 쿠키에 저장됩니다 (위 참조). 이것은 다른 쿠키와 다른 쿠키가 아니며 데이터는 사용자 세션의 서버 ID입니다.

JWT : 모든 것이 토큰에 저장됩니다 (쿠키라고도하는 텍스트 파일에 저장 될 수도 있음).

그것은 사실입니다. 모든 것이 토큰에 저장됩니다. 토큰은 쿠키에 저장 될 수 있습니다 (위 참조). 이는 서버 세션의 대안이며 토큰이 서버에 의해 서명되고 확인되므로 변경 또는 위조 할 수 없으며 클라이언트 측에 안전하게 보관할 수 있기 때문에 작동합니다.


JWT는 일반적으로 내 경험상 쿠키에 저장되지 않습니다. 그들은 종종 서버로가는 길에 자신의 헤더 (또는 종종 Authorization 헤더)에서 그들을보고 메모리 또는 클라이언트의 로컬 또는 세션 저장소에 저장했습니다.
Paul

1
로컬 스토리지에 관한 @Paul. 클라이언트에 따라 다릅니다. 모든 클라이언트가 아니라 가장 많이 사용되는 클라이언트의 모든 버전이 웹 스토리지를 지원하는 것은 아닙니다. 봐 여기 . 그렇다면 토큰을 계절별로 만드는 것이 좋습니다 . 그러나 고객이 로컬 스토리지를 지원하지 않는 경우 Httponly 쿠키 + SSL + 클라이언트 지문은 상당히 안전한 구현을 제공합니다.
Laiv

@Laiv 나는 당신에게 동의하지 않습니다; 사무엘이 "토큰은 쿠키에 저장되어있다"고 말했고, 나는 이것이 항상 그런 것은 아니라는 것을 관찰하려고 노력했습니다.
Paul

@Paul 나는 "... 쿠키에 저장 될 수있다"로 바뀌었다
Samuel
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.