토큰 기반 인증을위한 JWT 대 쿠키

토큰 기반 인증을위한 JWT 대 쿠키

---

"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 문제 외에도 다른 답변에서 논의했습니다.

In summary: the posts you're reading are probably comparing JWT as a bearer token to authentication cookie for browser to server authentication purposes. But JWT can do much more, it brings in standardization and features for use outside the use case you're probably thinking of.

참고URL : https://stackoverflow.com/questions/37582444/jwt-vs-cookies-for-token-based-authentication