"JWT vs Cookie" 에 대한 게시물을 읽었 지만 더 혼란스러워했습니다.

1. 좀 원하는 해명 , "쿠키 대 토큰 기반 인증"에 대해 이야기 사람들이 쿠키는 여기에 단지를 참조 세션 쿠키를 ? 내 이해는 쿠키는 매체와 같으며 토큰 기반 인증 ( 클라이언트 측 에서 로그인 한 사용자를 식별 할 수있는 것을 저장 ) 또는 세션 기반 인증 (클라이언트 측에 상수 저장) 을 구현하는 데 사용할 수 있습니다. 서버 측의 세션 정보와 일치 )

2. JSON 웹 토큰이 필요한 이유는 무엇 입니까? 나는 (토큰 기반 인증을 구현하는 표준 쿠키를 사용하고 , 세션 ID를 사용하지 않는 서버 메모리 또는 파일 저장 사용하지 :) Set-Cookie: user=innocent; preferred-color=azure, 나는 JWT가 모두 포함되어 있다는 것입니다 관찰하는 유일한 차이 페이로드 및 서명을 선택할 수있는 반면를 ... http 헤더에 대한 서명 된 쿠키 또는 일반 텍스트 쿠키 사이 . 제 생각에는 서명 된 쿠키 ( cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM')가 더 공간 효율적이며 유일한 단점은 클라이언트가 토큰을 읽을 수없고 서버 만 할 수 있다는 것입니다 ...하지만 JWT의 클레임 이 선택 사항이므로 토큰이 다음을 수행 할 필요가 없기 때문에 괜찮 습니다. 의미가있다

베어러 토큰과 쿠키의 가장 큰 차이점은 브라우저가 쿠키 를 자동으로 전송 한다는 것입니다 . 여기서 베어러 토큰을 HTTP 요청에 명시 적으로 추가해야합니다.

이 기능은 사용자가 로그인하고 링크를 사용하여 페이지 사이를 탐색하는 웹 사이트를 보호하는 좋은 방법입니다.

쿠키를 자동으로 보내는 브라우저는 CSRF 공격 이라는 큰 단점도 있습니다 . CSRF 공격에서 악의적 인 웹 사이트는 브라우저가 해당 도메인에 대한 요청에 인증 쿠키를 자동으로 첨부하고 브라우저를 속여 요청을 실행한다는 사실을 이용합니다.

https://www.example.com 의 웹 사이트에서 사용자 이름이나 이전 암호를 게시하지 않고도 POST새 암호를 https://www.example.com/changepassword 로 -ing하여 인증 된 사용자가 암호를 변경할 수 있다고 가정합니다 .

해당 주소로 POST를 트리거하는 브라우저에 페이지를로드하는 악성 웹 사이트를 방문 할 때 해당 웹 사이트에 여전히 로그인되어 있으면 브라우저가 인증 쿠키를 충실하게 첨부하여 공격자가 암호를 변경할 수 있도록합니다.

쿠키를 사용하여 웹 서비스를 보호 할 수도 있지만 요즘에는 베어러 토큰이 가장 많이 사용됩니다. 쿠키를 사용하여 웹 서비스를 보호하는 경우 동일 출처 정책 이 쿠키를 다른 도메인으로 보내지 않으므로 해당 서비스는 인증 쿠키가 설정된 도메인에 있어야합니다.

또한 쿠키는 비 브라우저 기반 애플리케이션 (예 : 모바일에서 태블릿 앱)이 API를 사용하는 것을 더 어렵게 만듭니다.

개요

당신이 요구하는 것은 클라이언트에서 서버로 JSON 웹 토큰 (JWT)을 보내기위한 쿠키와 전달자 토큰의 차이입니다.

쿠키와 전달자 토큰 모두 데이터를 보냅니다.

한 가지 차이점은 쿠키는 임의의 데이터를 전송 및 저장하는 반면 베어러 토큰은 인증 데이터를 전송하기위한 것입니다.

해당 데이터는 종종 JWT로 인코딩됩니다.

쿠키

쿠키는 웹 브라우저에 저장되고 만료 날짜와 관련 도메인이있는 이름-값 쌍입니다.

당사는 JavaScript 또는 HTTP 응답 헤더를 사용하여 웹 브라우저에 쿠키를 저장합니다.

document.cookie = 'my_cookie_name=my_cookie_value'   // JavaScript
Set-Cookie: my_cookie_name=my_cookie_value           // HTTP Response Header

웹 브라우저는 모든 요청과 함께 쿠키를 쿠키의 도메인에 자동으로 보냅니다.

GET http://www.bigfont.ca
Cookie: my_cookie_name=my_cookie_value               // HTTP Request Header

무기명 토큰

전달자 토큰은 AuthorizationHTTP 요청 의 헤더에 들어가는 값입니다 . 어디에도 자동으로 저장되지 않으며 만료 날짜도없고 연결된 도메인도 없습니다. 그것은 단지 가치 일뿐입니다. 해당 값을 클라이언트에 수동으로 저장하고 해당 값을 HTTP Authorization 헤더에 수동으로 추가합니다.

GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value          // HTTP Request Header

JWT 및 토큰 기반 인증

OpenID, OAuth 또는 OpenID Connect와 같은 토큰 기반 인증을 수행 할 때 신뢰할 수있는 기관으로부터 access_token (때로는 id_token)을받습니다. 일반적으로 우리는 그것을 저장하고 보호 된 리소스에 대한 HTTP 요청과 함께 보내려고합니다. 어떻게하나요?

옵션 1은 쿠키에 토큰을 저장하는 것입니다. 이것은 스토리지를 처리하고 또한 Cookie각 요청 의 헤더 에서 서버에 토큰을 자동으로 보냅니다 . 그런 다음 서버는 쿠키를 구문 분석하고 토큰을 확인하고 그에 따라 응답합니다.

또 다른 옵션은 로컬 / 세션 저장소에 토큰을 저장 한 다음 Authorization각 요청 의 헤더 를 수동으로 설정하는 것 입니다. 이 경우 서버는 헤더를 읽고 쿠키처럼 진행합니다.

자세한 내용은 링크 된 RFC를 읽어 볼 가치가 있습니다.

MvdD가 쿠키 자동 전송에 대해 말한 것 외에도 :

1. 쿠키는 매체가 될 수 있지만 가장 중요한 기능은 브라우저와 상호 작용하는 방식입니다. 쿠키는 서버에 의해 설정되고 매우 특정한 방식으로 요청으로 전송됩니다. 반면에 JWT는 배타적으로 매체이며 특정 구조의 일부 사실에 대한 주장입니다. 그렇게하려는 경우 인증 쿠키로 JWT를 넣을 수 있습니다. 비교 기사를 읽을 때 일반적으로 프런트 엔드 코드에서 전달자 토큰으로 전송 된 JWT와 백엔드의 일부 캐시 된 세션 또는 사용자 데이터에 해당하는 인증 쿠키를 사용하는 것에 대해 이야기합니다.
2. JWT는 많은 기능을 제공하며 당사자간에 사용할 수 있도록 표준에 포함합니다. JWT는 여러 장소에서 일부 사실의 서명 된 주장 역할을 할 수 있습니다. 쿠키는 어떤 데이터를 넣든 서명하든 브라우저와 특정 백엔드 사이에서만 사용하는 것이 합리적입니다. JWT는 브라우저에서 백엔드로, 다른 당사자 (OpenId Connect가 예)가 제어하는 ​​백엔드간에 또는 한 당사자의 백엔드 서비스 내에서 사용할 수 있습니다. 서명 된 쿠키의 특정 예와 관련하여 해당 사용 사례에서 JWT와 동일한 기능 ( "세션 ID를 사용하지 않고 서버 메모리 또는 파일 저장소를 사용하지 않음")을 수행 할 수 있지만 라이브러리 및 피어 리뷰에서 손실됩니다. 표준, CSRF 문제 외에도 다른 답변에서 논의되었습니다.

요약하면, 여러분이 읽고있는 게시물은 아마도 JWT를 베어러 토큰으로 브라우저 대 서버 인증 목적의 인증 쿠키와 비교하고있을 것입니다. 그러나 JWT는 훨씬 더 많은 일을 할 수 있으며, 여러분이 생각하고있는 사용 사례 외부에서 사용할 수 있도록 표준화와 기능을 제공합니다.

쿠키는 요청과 함께 자동으로 전송되기 때문에 CSRF 공격의 위험을 증가시킬 수 있지만 , HttpOnly페이지에 삽입 된 스크립트는 읽을 수 없기 때문에 플래그가 설정 되면 XSS 공격의 위험을 줄일 수 있습니다. 쿠키.

CSRF : 사용자가 공격자의 사이트에서 링크를 클릭 (또는 이미지보기)하여 브라우저가 피해자의 사이트에 요청을 보냅니다. 피해자가 쿠키를 사용하는 경우 브라우저는 요청에 쿠키를 자동으로 포함하고 GET 요청이 읽기 전용이 아닌 작업을 유발할 수있는 경우 피해자 사이트는 공격에 취약합니다.

XSS : 공격자가 피해자 사이트에 스크립트를 삽입하고 (피해자 사이트는 입력이 올바르게 삭제되지 않은 경우에만 취약 함) 공격자의 스크립트는 페이지에서 자바 스크립트가 허용하는 모든 작업을 수행 할 수 있습니다. JWT 토큰을 로컬 저장소에 저장하면 공격자의 스크립트가 해당 토큰을 읽고 해당 토큰을 제어하는 ​​서버로 보낼 수도 있습니다. HttpOnly플래그 와 함께 쿠키를 사용하는 경우 공격자의 스크립트는 처음부터 쿠키를 읽을 수 없습니다. 즉, 성공적으로 삽입 된 스크립트는 자바 스크립트가 할 수있는 모든 작업을 수행 할 수 있으므로 여전히 IMO에 속합니다 (예 : 쿠키를 읽고 나중에 사용하기 위해 쿠키를 읽지 못할 수도 있음) , 쿠키를 포함하는 XHR을 사용하여 vicitim 사이트에 요청을 보낼 수 있습니다 .)

참조 -JSON 웹 토큰 필요

쿠키

쿠키의 경우 사용자가 인증되면 Gmail 서버가 고유 한 세션 ID를 생성합니다. 이 세션 ID에 따라 Gmail 서버에서 사용자를 인식하고 작업을 수행하는 데 필요한 모든 사용자 정보를 메모리에 저장합니다.
또한 모든 후속 요청 및 응답에 대해이 세션 ID도 전달됩니다. 이제 서버가 요청을 받으면 세션 ID를 확인합니다. 이 세션 ID를 사용하면 해당 정보가 있는지 확인합니다. 그런 다음 사용자가 리소스에 액세스하고 세션 ID와 함께 응답을 반환 할 수 있습니다.

쿠키의 단점

• 쿠키 / 세션 ID는 자체 포함되지 않습니다. 참조 토큰입니다. 각 유효성 검사 중에 Gmail 서버는 이에 해당하는 정보를 가져와야합니다.
• 여러 API 및 서버와 관련된 마이크로 서비스 아키텍처에는 적합하지 않습니다.

JWT

• JWT는 자체 포함되어 있습니다. 가치 토큰입니다. 따라서 각 유효성 검사 중에 Gmail 서버는 해당 정보를 가져올 필요가 없습니다.
• 디지털 서명이되어 있으므로 누군가 수정하면 서버에서 알 수 있습니다.
• Microservices Architecture에 가장 적합합니다.
• 만료 시간 지정과 같은 다른 이점이 있습니다.