토큰 기반 인증을 위한 JWT vs 쿠키
'JWT vs 쿠키'에 대한 글을 읽었는데 더 혼란스러워서...
설명을 듣고 싶은데, "토큰 기반 인증 vs 쿠키"에 대해 이야기할 때 여기서 말하는 쿠키는 단순히 세션 쿠키를 가리킵니다.cookie는 미디어와 같은 것으로 토큰 기반 인증(클라이언트 측에서 로그인 사용자를 식별할 수 있는 것을 저장) 또는 세션 기반 인증(서버 측에서 세션 정보와 일치하는 상수를 저장) 구현에 사용할 수 있습니다.
JSON Web 토큰이 필요한 이유는 무엇입니까?토큰 기반 인증을 구현하기 위해 표준 쿠키를 사용하고 있었습니다(세션 ID를 사용하지 않거나 서버 메모리 또는 파일 저장소를 사용하지 않음).
Set-Cookie: user=innocent; preferred-color=azureJWT에 payload와 시그니처가 모두 포함되어 있는 것이 유일한 차이점입니다.http 헤더의 경우 서명된 cookie 또는 일반 텍스트 cookie 중 하나를 선택할 수 있습니다.제 의견으로는 서명된 쿠키입니다.cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM')는 공간 효율이 향상됩니다.단, 클라이언트는 토큰을 읽을 수 없고 서버만 읽을 수 있습니다.JWT의 클레임이 옵션인 것처럼 토큰이 의미가 있는 것은 아니기 때문에 괜찮다고 생각합니다.
베어러 토큰과 쿠키의 가장 큰 차이점은 브라우저가 자동으로 쿠키를 전송한다는 것입니다.여기서 베어러 토큰을 HTTP 요구에 명시적으로 추가해야 합니다.
이 기능을 사용하면 사용자가 로그인하여 링크를 사용하여 페이지 사이를 이동하는 웹 사이트를 보호할 수 있습니다.
cookie를 자동적으로 송신하는 브라우저에는 CSRF 공격이라는 큰 단점도 있습니다.CSRF 공격에서는 브라우저가 인증 쿠키를 해당 도메인에 자동으로 부가하고 브라우저가 요청을 실행하도록 속이는 점을 악용합니다.
https://www.example.com의 웹사이트에서 인증된 사용자가 다음 방법으로 비밀번호를 변경할 수 있다고 가정합니다.POST- 사용자 이름 또는 이전 비밀번호를 게시하지 않고 https://www.example.com/changepassword에 새 비밀번호를 입력합니다.
POST를 트리거하는 페이지를 브라우저에 로드하는 악의적인 웹 사이트를 방문했을 때 해당 웹 사이트에 로그인한 경우 브라우저는 인증 쿠키를 올바르게 첨부하여 공격자가 암호를 변경할 수 있도록 합니다.
쿠키는 웹 서비스를 보호하는 데도 사용할 수 있지만, 최근에는 베어러 토큰이 가장 많이 사용됩니다.웹 서비스를 보호하기 위해 쿠키를 사용하는 경우 동일한 원본 정책이 다른 도메인으로 쿠키를 보내지 않으므로 해당 서비스는 인증 쿠키가 설정된 도메인에 있어야 합니다.
또한 쿠키는 브라우저가 아닌 애플리케이션(예: 모바일에서 태블릿으로)이 API를 소비하는 것을 더 어렵게 만듭니다.
개요
필요한 것은 클라이언트에서 서버로 JSON Web 토큰(JWT)을 송신하기 위한 쿠키와 베어러 토큰의 차이입니다.
쿠키 토큰과 베어러 토큰 모두 데이터를 전송합니다.
한 가지 차이점은 cookie는 임의의 데이터를 전송 및 저장하기 위한 것이지만 bearer 토큰은 인가 데이터를 전송하기 위한 것입니다.
이 데이터는 종종 JWT로 인코딩됩니다.
쿠키
cookie는 이름과 값의 쌍으로 웹 브라우저에 저장되며 유효기간과 연관된 도메인이 있습니다.
웹 브라우저에 JavaScript 또는 HTTP Response 헤더를 사용하여 쿠키를 저장합니다.
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
베어러 토큰
은 ''에입니다.Authorization「HTTP」입니다.이 파일은 자동으로 저장되지 않으며 만료 날짜 및 관련 도메인도 없습니다.그냥 가치일 뿐이야.이 값은 클라이언트에 수동으로 저장하고 HTTP Authorization 헤더에 수동으로 추가합니다.
GET http://www.bigfont.ca
Authorization: Bearer my_bearer_token_value // HTTP Request Header
JWT 및 토큰 기반 인증
OpenID, OAuth, Open 등의 토큰 기반 인증을 실행하는 경우ID Connect는 신뢰할 수 있는 기관으로부터access_token(경우에 따라서는 id_token)을 수신합니다.일반적으로 보호된 리소스에 대한 HTTP 요청과 함께 저장하여 보냅니다.우리가 저걸 어떻게 해요?
옵션 1은 토큰을 쿠키에 저장하는 것입니다.으로 「」의 됩니다.Cookie각 요청의 헤더.그런 다음 서버는 쿠키를 해석하고 토큰을 체크하고 그에 따라 응답합니다.
을 로컬 스토리지에 한 후 으로 "2" "/" "/" "D" 를 입니다.Authorization각 요청의 헤더.이 경우 서버는 헤더를 읽고 쿠키와 동일하게 진행합니다.
자세한 내용은 링크된 RFC를 읽어보시기 바랍니다.
MvdD가 쿠키가 자동으로 전송되는 것에 대해 언급한 내용 외에 다음과 같은 내용이 있습니다.
- 쿠키는 매개체가 될 수 있지만 가장 중요한 기능은 브라우저와 상호 작용하는 방법입니다.쿠키는 서버에 의해 설정되며 매우 구체적인 방법으로 요청으로 전송됩니다.반면 JWT는 배타적인 매체이며, 특정 구조에서 일부 사실을 주장하는 것이다.그렇게 하고 싶다면 JWT를 인증 쿠키로 넣을 수 있습니다.비교 기사를 읽으면 일반적으로 프런트엔드 코드에 의해 베어러 토큰으로 전송된 JWT와 백엔드의 캐시된 세션 또는 사용자 데이터에 대응하는 인증 쿠키가 사용됩니다.
- JWT는 많은 기능을 제공하며, 이를 표준으로 하여 당사자 간에 사용할 수 있습니다.JWT는 많은 다른 장소에서 일부 사실에 대한 서명된 주장 역할을 할 수 있습니다.쿠키는 어떤 데이터를 넣든 서명하든 브라우저와 특정 백엔드 사이에서만 사용할 수 있습니다.JWT는 브라우저에서 백엔드, 다른 당사자에 의해 제어되는 백엔드(OpenId Connect가 예) 또는 한쪽 당사자의 백엔드 서비스 내에서 사용할 수 있습니다.서명된 쿠키의 구체적인 예에 대해서는 JWT와 같은 기능("세션 ID를 사용하지 않거나 서버 메모리 또는 파일 스토리지를 사용하지 않음")을 실현할 수 있지만, 다른 답변에서 설명한 CSRF 문제와 더불어 표준 라이브러리 및 피어 리뷰에서는 손해를 볼 수 있습니다.
요약하면, 당신이 읽고 있는 투고는 아마도 JWT를 브라우저 대 서버 인증용 인증 쿠키와 베어러 토큰으로 비교하고 있을 것입니다.하지만 JWT는 훨씬 더 많은 것을 할 수 있습니다. JWT는 표준화와 여러분이 생각하는 사용 사례 이외의 용도로 사용할 수 있는 기능을 제공합니다.
Cookie는 요청과 함께 자동으로 전송되므로 CSRF 공격의 위험을 높일 수 있지만, Cookie는 Cookie가 Cookie를 통해 XSS 공격의 위험을 줄일 수 있습니다.HttpOnly페이지에 삽입된 스크립트는 쿠키를 읽을 수 없기 때문에 플래그가 설정됩니다.
CSRF: 사용자가 공격자 사이트의 링크를 클릭하면 브라우저가 공격자 사이트로 요청을 보냅니다.공격 대상자가 쿠키를 사용하는 경우 브라우저는 자동으로 cookie를 요청에 포함시키고 GET 요청에 의해 읽기 전용이 아닌 액션이 발생할 수 있는 경우 공격 대상 사이트는 공격에 취약합니다.
XSS: 공격자는 공격 대상 사이트에 스크립트를 내장하고 있습니다(피해 대상 사이트는 입력이 올바르게 삭제되지 않은 경우에만 취약합니다). 공격 대상자의 스크립트는 JavaScript가 페이지에서 허용하는 모든 작업을 수행할 수 있습니다.로컬 저장소에 JWT 토큰을 저장하는 경우 공격자가 해당 토큰을 읽을 수 있으며 해당 토큰을 제어하는 서버로 보낼 수도 있습니다.cookie와 하는 HttpOnlyflag, 공격자의 스크립트는 처음부터 쿠키를 읽을 수 없습니다.즉, 그들이 성공적으로 삽입한 스크립트는 여전히 JavaScript가 할 수 있는 모든 것을 할 수 있기 때문에 당신은 여전히 IMO를 하고 있다(즉, 그들은 나중에 사용하기 위해 쿠키를 읽기 위해 자신의 서버로 보낼 수 없는 반면, 그들은 XHR을 사용하여 피해자 사이트에 요청을 보낼 수 있다).
쿠키
In case of cookies, once the user has been authenticated then the Gmail Server will create a unique session Id. Corresponding to this session id it will store in memory all the user information that is needed by the Gmail server for recognizing the user and allowing it perform operations.Also then for all subsequent requests and response, this session id will also be passed. So now when the server receives a request it will check the session id. Using this session id will check if there is any corresponding information. It will then allow the user to access the resource and return back the response along with the session id.
쿠키의 결점
- 쿠키/세션 ID는 자체 포함되어 있지 않습니다.참조 토큰입니다.각 검증 중에 Gmail 서버는 그에 해당하는 정보를 가져와야 합니다.
- 여러 API 및 서버를 포함하는 마이크로 서비스 아키텍처에는 적합하지 않습니다.
JWT
- JWT는 자체 억제되어 있습니다.값 토큰입니다.따라서 각 검증 중에 Gmail 서버는 그에 해당하는 정보를 가져올 필요가 없습니다.
- 디지털 서명이 되어 있기 때문에, 그것을 수정하는 사람이 있으면, 서버는 그것을 알 수 있습니다.
- 마이크로 서비스 아키텍처에 가장 적합합니다.
- 유효기간을 지정하는 등의 장점이 있습니다.
- 네, 쿠키는 어떤 용도로도 사용할 수 있습니다.
- 왜 JWT가 필요하죠?
JSON은 원하는 데이터를 저장할 수 있는 최적의 IMHO 데이터 형식입니다.
JWT의 경우 데이터 크기에 따라 제한되지 않으며, 쿠키의 경우 도메인이 아닌 모든 쿠키에 대해 도메인당 4093바이트만 사용할 수 있습니다.
언급URL : https://stackoverflow.com/questions/37582444/jwt-vs-cookies-for-token-based-authentication
'programing' 카테고리의 다른 글
| 오류가 발생하지 않고 모듈의 존재를 확인하는 방법은 무엇입니까? (0) | 2023.02.28 |
|---|---|
| Wordpress 폼에서 SOAP 웹 서비스를 호출하려면 어떻게 해야 합니까? (0) | 2023.02.28 |
| ORA-12519가 간헐적으로 발생하는 원인(TNS: 적절한 핸들러를 찾을 수 없음) (0) | 2023.02.28 |
| Oracle에서 시퀀스를 리셋하려면 어떻게 해야 합니까? (0) | 2023.02.23 |
| 찾을 수 없는 아이콘 리액션-대박 (0) | 2023.02.23 |