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 내부의 메커니즘으로 사용될 수 있습니다.
자세한 내용은 여기를 참조하십시오
이 질문은 일반적인 것이지만 그다지 현명하지는 않습니다. JWT는 토큰 유형이며 OAuth는 토큰 분배 방법을 설명하는 프레임 워크입니다.
"프레임 워크"는 무엇을 의미합니까? 토큰을 요청하는 데 사용할 수 있어야하는 요청 및 응답 순서와 형식 만 있습니다. OAuthv2는 각기 다른 시나리오에 대해 별도의 "흐름"또는 권한 부여 유형을 설명하고 특정 흐름의 보안을 확장하기 위해 PKCE와 같은 다른 확장명을 갖습니다.
OAuthV2 보조금을 통한 토큰 요청의 결과는 ... 토큰입니다. 그런 다음 토큰을 보유한 모든 당사자가 API 요청 서비스를 작성할 때 토큰을 제시 할 수 있음을 의미하는 "베어러 토큰"으로 사용됩니다 (예 : "내 저장 가치 카드의 잔액은 얼마입니까?"). 무기명 토큰으로서 현금처럼 작동합니다. 잡고 있으면 사용할 수 있습니다. (현금과는 달리, 토큰은 사용하지 않고 잃어 버리지 않습니다. 아마도 대중 교통 시스템의 종일 승차권 또는 Disneyworld의 종일 승차권이 더 나은 유추입니다.)
JWT는 특정 유형의 토큰이며, JWT는 OAuth 베어러 토큰으로 절대적으로 사용될 수 있습니다. 실제로 이것은 가장 일반적인 관행입니다. "JWT vs OAuth"는이를 고려하여 사과와 사과 카트를 비교 한 것입니다.
사람들은 종종 "OAuth 토큰"은 항상 고유 한 의미를 포함하지 않는 임의의 영숫자 문자 인 불투명 토큰을 의미하며 OAuth 토큰 약국에서 부여한 다음 동일한 OAuth 약국 시스템에서만 확인할 수 있습니다. 그러나 이것이 유일한 OAuth 토큰은 아닙니다. 불투명 토큰은 한 종류의 토큰입니다. JWT는 다른 종류의 OAuth 토큰으로 사용될 수 있습니다.
반대로 JWT는 불투명하지 않습니다. JWT는 "포인터"또는 정보 참조가 아닙니다. 실제로 토큰을 가진 모든 당사자가 추출하고 해석 할 수있는 많은 특정 정보가 포함되어 있습니다. JWT에는 실제 정보가 포함되므로 JWT는 클 수 있습니다. 포함 된 클레임 및 서명에 사용 된 알고리즘에 따라 300 바이트, 500 바이트 이상. 사람들이 "JWT가 자체 검증 중"이라고 말하면 JWT 소유자는 JWT를 열고 유효성을 검사 한 후 제시된 청구에 따라 권한 결정을 내릴 수 있습니다. JWT 검증은 구조 검증, base64 인코딩 디코딩, 키가 올바른 검증, 서명 검증, 토큰에 필수 클레임이 있는지 확인, 만료 확인을 의미합니다. 단순한 것이 아닙니다. 오히려 다단계 프로세스이지만 다양한 프로그래밍 언어로 된 많은 라이브러리가 있으며 이것으로 Apigee Edge API 프록시 내에서이를 수행하는 데 도움이되는 VerifyJWT 정책이 있습니다. 요점은 모든 보유자 또는 수신자가 토큰을 확인할 수 있다는 것입니다. 이 때문에 JWT는 "페더레이션"을 지원한다고 말합니다. 누구나 토큰을 생성 할 수 있으며 누구나 토큰을 읽고 확인할 수 있습니다.
맞춤 클레임. JWT 및 불투명 한 OAuth 토큰 모두 주제에 대한 사용자 지정 클레임을 전달할 수 있습니다. 보안. 둘 다 무기명 토큰입니다. 둘 다 비밀로 보호해야합니다. 만료. 둘 다 만료로 표시 될 수 있습니다. 둘 다 새로 고칠 수 있습니다. 인증 메커니즘 또는 경험. 둘 다 동일한 사용자 경험을 제공 할 수 있습니다.
Jwt는 서명 된 액세스 토큰의 발급 및 유효성 검사를위한 엄격한 지침입니다. 토큰에는 앱이 사용자에 대한 액세스를 제한하기 위해 사용하는 클레임이 포함되어 있습니다.
반면 OAuth2는 위임 된 인증 프레임 워크 인 프로토콜이 아닙니다. 사용자 및 응용 프로그램이 개인 및 공개 설정 모두에서 다른 응용 프로그램에 대한 특정 권한을 부여 할 수 있도록하는 매우 자세한 지침을 생각하십시오. OAUTH2의 최상위에있는 OpenID Connect는 인증 및 권한 부여를 제공합니다. 여러 역할, 시스템 사용자, API와 같은 서버 측 앱 및 웹 사이트 또는 기본 모바일 앱과 같은 클라이언트가 각기 다른 방법으로 인증 할 수있는 방법을 자세히 설명합니다.
참고 OAuth2를 다른 응용 프로그램에 JWT, 유연한 구현, extandable 작업 할 수 있습니다