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 Web Tokens) -단지 토큰 형식입니다. 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와 OAuth의 주요 차이점 찾기
-
OAuth 2.0은 프로토콜을 정의하고 JWT는 토큰 형식을 정의합니다.
-
OAuth는 JWT를 토큰 형식으로 사용하거나 베어러 토큰 인 액세스 토큰을 사용할 수 있습니다.
-
OpenID Connect는 주로 JWT를 토큰 형식으로 사용합니다.
답변
JWT는 당사자간에 정보를 안전하게 전송하기위한 작고 독립적 인 방법을 정의하는 개방형 표준입니다. 암호화 된 클레임 (토큰)이 두 당사자 (클라이언트와 서버)간에 전송되고 클라이언트 식별시 토큰이 발행되는 인증 프로토콜입니다. 각 후속 요청과 함께 토큰을 보냅니다.
OAuth2는 인증 프레임 워크 인 반면, 프레임 워크에 의해 정의 된 일반 절차 및 설정이 있습니다. JAuth는 OAuth2 내부의 메커니즘으로 사용될 수 있습니다.
자세한 내용은 여기를 참조하십시오
