JWT와 OAuth 인증의 주요 차이점은 무엇입니까?
JWT를 사용하는 상태 비 저장 인증 모델을 사용하는 새로운 SPA가 있습니다. 간단한 토큰 헤더 대신 모든 요청에 대해 '베어러 토큰'을 보내도록 요청하는 것과 같은 인증 흐름에 대해 OAuth를 참조하라는 요청이 종종 있지만 OAuth는 간단한 JWT 기반 인증보다 훨씬 복잡하다고 생각합니다. JWT 인증이 OAuth처럼 작동하도록해야하는 주요 차이점은 무엇입니까?
XSWT를 방지하기 위해 JWT를 XSRF-TOKEN으로 사용하고 있지만 별도로 분리해야합니까? 따로 보관해야합니까? 여기에 도움을 주시면 커뮤니티를위한 일련의 지침으로 이어질 수 있습니다.
TL; DR 단일 클라이언트 응용 프로그램, 단일 API와 같은 매우 간단한 시나리오가있는 경우 OAuth 2.0으로 이동하는 데 돈을 지불하지 않을 수 있습니다. 반면에 다른 많은 클라이언트 (브라우저 기반, 기본 모바일, 서버 측) ) 등의 OAuth 2.0 규칙을 고수하면 시스템을 롤링하는 것보다 관리하기가 더 쉬울 수 있습니다.
다른 답변에서 언급했듯이 JWT ( Learn JSON Web Tokens )는 토큰 형식 일뿐 아니라 디지털 서명을 통해 검증되고 신뢰할 수있는 방식으로 당사자간에 데이터를 전송하기위한 컴팩트하고 독립적 인 메커니즘을 정의합니다. 또한 JWT의 인코딩 규칙은 이러한 토큰을 HTTP 컨텍스트 내에서 사용하기 매우 쉽게 만듭니다.
자체적으로 포함되어 있기 때문에 (실제 토큰에는 주어진 주제에 대한 정보가 포함되어 있음) 상태 비 저장 인증 메커니즘 (일명 Look mum, 세션 없음! ) 을 구현하는 데에도 적합합니다 . 이 경로를 진행할 때 보호 된 리소스에 대한 액세스 권한을 부여하기 위해 당사자가 제시해야하는 유일한 것은 토큰 자체이며, 해당 토큰을 베어러 토큰이라고 할 수 있습니다.
실제로, 수행중인 작업은 이미 베어러 토큰을 기반으로 분류 될 수 있습니다. 그러나 OAuth 2.0 관련 스펙에 지정된 베어러 토큰을 사용하지 않는 것을 고려하십시오 ( RFC 6750 참조 ). 이는 AuthorizationHTTP 헤더 에 의존 하고 Bearer인증 체계를 사용 한다는 것을 의미 합니다.
정확한 세부 사항을 알지 못하고 CSRF를 방지하기 위해 JWT를 사용하는 것과 관련하여 해당 관행의 유효성을 확인하기는 어렵지만 솔직히 말하면 정확하고 가치가있는 것처럼 보이지 않습니다. 다음 기사 ( 쿠키 및 토큰 : 최종 안내서 )는이 주제, 특히 XSS 및 XSRF 보호 섹션 에서 유용한 정보를 제공 합니다.
마지막 OAuth 2.0을 사용할 필요가 없더라도 최종 조언 은 사용자 지정 헤더 대신 헤더 내에서 액세스 토큰을 전달하는 것이 좋습니다Authorization . 이들이 실제로 베어러 토큰 인 경우 RFC 6750의 규칙을 따르십시오. 그렇지 않은 경우 항상 사용자 정의 인증 체계를 작성하고 해당 헤더를 계속 사용할 수 있습니다.
권한 부여 헤더는 HTTP 프록시 및 서버에서 인식되고 특별히 처리됩니다. 따라서, 액세스 토큰을 리소스 서버로 전송하기위한 이러한 헤더의 사용은 일반적으로 인증 요청의 누출 또는 의도하지 않은 저장, 특히 인증 헤더의 가능성을 감소시킨다.
(출처 : RFC 6819, section 5.4.1 )
OAuth 2.0은 프로토콜을 정의합니다. 즉 토큰 전송 방법을 지정하고 JWT는 토큰 형식을 정의합니다.
OAuth 2.0과 "JWT 인증"은 클라이언트가 리소스 서버에 토큰을 제공하는 2 단계 (단계)에서 비슷한 모양을 갖습니다. 토큰은 헤더로 전달됩니다.
그러나 "JWT 인증"은 표준이 아니며 클라이언트가 첫 번째 단계 (1 단계)에서 토큰을 얻는 방법을 지정하지 않습니다 . 그것이 OAuth의 복잡성을 인식하는 곳입니다. 또한 클라이언트 가 Authorization Server라는 액세스 토큰을 얻을 수있는 다양한 방법을 정의합니다 .
실제 차이점은 JWT는 단지 토큰 형식이고 OAuth 2.0은 프로토콜입니다 ( JWT를 토큰 형식으로 사용할 수 있음 ).
먼저 JWT와 OAuth를 차별화해야합니다. 기본적으로 JWT는 토큰 형식입니다. OAuth는 JWT를 토큰으로 사용할 수있는 권한 부여 프로토콜입니다. OAuth는 서버 측 및 클라이언트 측 스토리지를 사용합니다. 실제 로그 아웃을하려면 OAuth2를 사용해야합니다. JWT 토큰을 사용한 인증은 실제로 로그 아웃 할 수 없습니다. 토큰을 추적하는 인증 서버가 없기 때문입니다. 타사 클라이언트에 API를 제공하려면 OAuth2도 사용해야합니다. OAuth2는 매우 유연합니다. JWT 구현은 매우 쉽고 구현하는 데 시간이 오래 걸리지 않습니다. 응용 프로그램에 이러한 종류의 유연성이 필요한 경우 OAuth2를 사용해야합니다. 그러나이 사용 사례 시나리오가 필요하지 않은 경우 OAuth2 구현은 시간 낭비입니다.
XSRF 토큰은 항상 모든 응답 헤더에서 클라이언트로 전송됩니다. CSRF 토큰 자체로 보안되므로 CSRF 토큰이 JWT 토큰으로 전송되는지 여부는 중요하지 않습니다. 따라서 JWT에서 CSRF 토큰을 보낼 필요가 없습니다.
JWT (JSON 웹 토큰) -단지 토큰 형식입니다. JWT 토큰은 JSON으로 인코딩 된 데이터 구조이며 발급자, 주제 (청구), 만료 시간 등에 대한 정보를 포함합니다. 변조 방지 및 인증을 위해 서명되었으며 대칭 또는 비대칭 방식을 사용하여 토큰 정보를 보호하기 위해 암호화 할 수 있습니다. JWT는 SAML 1.1 / 2.0보다 단순하고 모든 장치에서 지원되며 SWT (Simple Web Token)보다 강력합니다.
OAuth2 -OAuth2는 탐색 기반 웹 앱, 기본 모바일 앱 또는 데스크톱 앱과 같은 클라이언트 소프트웨어를 사용하여 사용자가 데이터에 액세스하려는 문제를 해결합니다. OAuth2는 인증 용이며, 액세스 토큰을 사용하여 최종 사용자 대신 리소스에 액세스하도록 클라이언트 소프트웨어를 인증 할 수 있습니다.
OpenID Connect -OpenID Connect는 OAuth2 위에 구축되고 인증을 추가합니다. OpenID Connect는 UserInfo Endpoint, ID 토큰, OpenID Connect 제공자의 검색 및 동적 등록 및 세션 관리와 같은 OAuth2에 제약을 추가합니다. JWT는 토큰의 필수 형식입니다.
CSRF 보호 -브라우저의 쿠키에 토큰을 저장하지 않으면 CSRF 보호를 구현할 필요가 없습니다.
자세한 내용은 http://proficientblog.com/microservices-security/를 참조하십시오 .
여기에 응답 한 모든 사람이 OAUTH의 약점을 놓친 것 같습니다.
위키 백과에서
OAuth는 액세스 위임을위한 공개 표준으로, 일반적으로 인터넷 사용자가 웹 사이트 나 응용 프로그램이 다른 웹 사이트의 정보에 대한 액세스 권한을 부여하지만 암호는 제공하지 않는 방법으로 사용됩니다. [1] 이 메커니즘은 Google, Facebook, Microsoft 및 Twitter와 같은 회사에서 사용자가 자신의 계정 정보를 타사 응용 프로그램 또는 웹 사이트와 공유 할 수 있도록 사용합니다.
여기서 핵심은 access delegation입니다. OTP와 같은 다단계 인증으로 뒷받침되는 id / pwd 기반 인증이있을 때 누구나 OAUTH를 생성하고 경로에 대한 액세스를 보호하는 데 사용되는 JWT (OAUTH의 범위와 같은)에 의해 OAUTH를 작성하는 이유는 무엇입니까? 접속하다
소비자가 엔드 포인트에서 다시 호스팅되는 신뢰할 수있는 웹 사이트 (또는 앱)를 통해서만 리소스 (엔드 포인트)에 액세스하는 경우 OAUTH를 사용할 필요가 없습니다.
단지 당신의 OAuth 인증을 갈 수있는 당신이 경우 OAUTH provider리소스 소유자 (사용자) 타사 클라이언트 (외부 응용 프로그램)을 통해 자신의 (당신의) 자원 (엔드 포인트)에 액세스 할 경우이다. 일반적인 목적으로 남용 할 수 있지만 동일한 목적으로 정확하게 생성됩니다.
또 다른 중요한 참고 사항 : JWT 및 OAUTH
라는 단어 authentication를 자유롭게 사용하고 있지만 인증 메커니즘을 제공하지는 않습니다. 그렇습니다. 하나는 토큰 메커니즘이고 다른 하나는 프로토콜이지만 일단 인증되면 인증 (액세스 관리)에만 사용됩니다. OPENID 유형 인증 또는 자체 클라이언트 자격 증명으로 OAUTH를 백업했습니다.
JWT는 당사자간에 정보를 안전하게 전송하기위한 작고 독립적 인 방법을 정의하는 개방형 표준입니다. 암호화 된 클레임 (토큰)이 두 당사자 (클라이언트와 서버)간에 전송되고 클라이언트 식별시 토큰이 발행되는 인증 프로토콜입니다. 각 후속 요청과 함께 토큰을 보냅니다.
OAuth2는 인증 프레임 워크 인 반면, 프레임 워크에 의해 정의 된 일반 절차 및 설정이 있습니다. JAuth는 OAuth2 내부의 메커니즘으로 사용될 수 있습니다.
자세한 내용은 여기를 참조하십시오
JWT와 OAuth의 주요 차이점 찾기
OAuth 2.0은 프로토콜을 정의하고 JWT는 토큰 형식을 정의합니다.
OAuth는 JWT를 토큰 형식으로 사용하거나 베어러 토큰 인 액세스 토큰을 사용할 수 있습니다.
OpenID Connect는 주로 JWT를 토큰 형식으로 사용합니다.
Jwt는 서명 된 액세스 토큰의 발급 및 유효성 검사를위한 엄격한 지침입니다. 토큰에는 앱이 사용자에 대한 액세스를 제한하기 위해 사용하는 클레임이 포함되어 있습니다.
반면 OAuth2는 위임 된 인증 프레임 워크 인 프로토콜이 아닙니다. 사용자 및 응용 프로그램이 개인 및 공개 설정 모두에서 다른 응용 프로그램에 대한 특정 권한을 부여 할 수 있도록하는 매우 자세한 지침을 생각하십시오. OAUTH2의 최상위에있는 OpenID Connect는 인증 및 권한 부여를 제공합니다. 여러 역할, 시스템 사용자, API와 같은 서버 측 앱 및 웹 사이트 또는 기본 모바일 앱과 같은 클라이언트가 각기 다른 방법으로 인증 할 수있는 방법에 대해 자세히 설명합니다.
참고 OAuth2를 다른 응용 프로그램에 JWT, 유연한 구현, extandable 작업 할 수 있습니다
'Programing' 카테고리의 다른 글
| ArrayList를 복제하고 내용을 복제하는 방법은 무엇입니까? (0) | 2020.04.02 |
|---|---|
| Windows 용 Vim-파일을 저장하고 종료하려면 무엇을 입력해야합니까? (0) | 2020.04.02 |
| git 내에서 파일과 디렉토리의 권한을 수정 한 경우 어떻게 복원합니까? (0) | 2020.04.02 |
| 폴더의 Subversion 컨트롤을 어떻게 제거합니까? (0) | 2020.04.02 |
| Express에서 URL 매개 변수를 얻는 방법은 무엇입니까? (0) | 2020.04.02 |