Sự khác biệt chính giữa xác thực JWT và OAuth là gì?

Tôi có một SPA mới với mô hình xác thực không trạng thái bằng JWT. Tôi thường được yêu cầu giới thiệu OAuth cho các luồng xác thực như yêu cầu tôi gửi 'Mã thông báo mang' cho mọi yêu cầu thay vì tiêu đề mã thông báo đơn giản nhưng tôi nghĩ rằng OAuth phức tạp hơn nhiều so với xác thực dựa trên JWT đơn giản. Sự khác biệt chính là gì, tôi có nên làm cho xác thực JWT hoạt động như OAuth không?

Tôi cũng đang sử dụng JWT làm XSRF-TOKEN của mình để ngăn XSRF nhưng tôi có được yêu cầu tách chúng ra không? Tôi có nên giữ chúng riêng biệt? Bất kỳ trợ giúp ở đây sẽ được đánh giá cao và có thể dẫn đến một bộ hướng dẫn cho cộng đồng.

TL; DR Nếu bạn có các kịch bản rất đơn giản, như một ứng dụng khách, một API thì có thể không trả được OAuth 2.0, mặt khác, rất nhiều ứng dụng khách khác nhau (dựa trên trình duyệt, di động gốc, phía máy chủ , v.v.) sau đó tuân thủ các quy tắc OAuth 2.0 có thể giúp quản lý dễ dàng hơn là cố gắng tạo ra hệ thống của riêng bạn.

Như đã nêu trong một câu trả lời khác, JWT ( Tìm hiểu Token Web JSON ) chỉ là một định dạng mã thông báo, nó xác định một cơ chế nhỏ gọn và khép kín để truyền dữ liệu giữa các bên theo cách có thể được xác minh và tin cậy vì được ký điện tử. Ngoài ra, các quy tắc mã hóa của JWT cũng giúp các mã thông báo này rất dễ sử dụng trong bối cảnh HTTP.

Được khép kín (mã thông báo thực tế chứa thông tin về một chủ đề nhất định), chúng cũng là một lựa chọn tốt để thực hiện các cơ chế xác thực không trạng thái (còn gọi là Mẹ, không có phiên! ). Khi đi theo tuyến đường này và điều duy nhất mà một bên phải trình bày để được cấp quyền truy cập vào tài nguyên được bảo vệ là chính mã thông báo, mã thông báo được đề cập có thể được gọi là mã thông báo mang.

Trong thực tế, những gì bạn đang làm có thể được phân loại là dựa trên mã thông báo mang. Tuy nhiên, hãy cân nhắc rằng bạn không sử dụng mã thông báo mang theo như được chỉ định bởi thông số kỹ thuật liên quan đến OAuth 2.0 (xem RFC 6750 ). Điều đó có nghĩa là, dựa vào Authorizationtiêu đề HTTP và sử dụng Bearersơ đồ xác thực.

Về việc sử dụng JWT để ngăn chặn CSRF mà không biết chi tiết chính xác, thật khó để xác định tính hợp lệ của thực tiễn đó, nhưng thành thật mà nói, nó có vẻ không đúng và / hoặc đáng giá. Bài viết sau ( Cookies vs Tokens: The Definitive Guide ) có thể là một bài đọc hữu ích về chủ đề này, đặc biệt là phần Bảo vệ XSS và XSRF .

Một lời khuyên cuối cùng, ngay cả khi bạn không cần sử dụng OAuth 2.0 đầy đủ, tôi thực sự khuyên bạn nên chuyển mã thông báo truy cập của mình trong Authorizationtiêu đề thay vì đi với tiêu đề tùy chỉnh . Nếu chúng thực sự là mã thông báo mang theo các quy tắc của RFC 6750, nếu không, bạn luôn có thể tạo sơ đồ xác thực tùy chỉnh và vẫn sử dụng tiêu đề đó.

Các tiêu đề ủy quyền được công nhận và xử lý đặc biệt bởi các proxy và máy chủ HTTP. Do đó, việc sử dụng các tiêu đề như vậy để gửi mã thông báo truy cập đến các máy chủ tài nguyên giúp giảm khả năng rò rỉ hoặc lưu trữ ngoài ý muốn của các yêu cầu được xác thực nói chung và đặc biệt là các tiêu đề Ủy quyền.

(nguồn: RFC 6819, mục 5.4.1 )

OAuth 2.0 định nghĩa một giao thức, tức là chỉ định cách chuyển mã thông báo, JWT xác định định dạng mã thông báo.

OAuth 2.0 và "Xác thực JWT" có giao diện tương tự nhau khi đến giai đoạn (thứ 2) trong đó Máy khách trình bày mã thông báo cho Máy chủ tài nguyên: mã thông báo được chuyển trong tiêu đề.

Nhưng "xác thực JWT" không phải là một tiêu chuẩn và không chỉ định cách Khách hàng nhận được mã thông báo ở vị trí đầu tiên (giai đoạn đầu tiên). Đó là nơi mà sự phức tạp nhận thức của OAuth đến từ: nó cũng xác định nhiều cách khác nhau để Khách hàng có thể nhận được mã thông báo truy cập từ một thứ được gọi là Máy chủ ủy quyền.

Vì vậy, sự khác biệt thực sự là JWT chỉ là định dạng mã thông báo, OAuth 2.0 là một giao thức ( có thể sử dụng JWT làm định dạng mã thông báo).

Đầu tiên, chúng ta phải phân biệt JWT và OAuth. Về cơ bản, JWT là một định dạng mã thông báo. OAuth là một giao thức ủy quyền có thể sử dụng JWT làm mã thông báo. OAuth sử dụng lưu trữ phía máy chủ và phía máy khách. Nếu bạn muốn đăng xuất thực sự, bạn phải đi với OAuth2. Xác thực với mã thông báo JWT không thể đăng xuất thực sự. Bởi vì bạn không có Máy chủ xác thực theo dõi mã thông báo. Nếu bạn muốn cung cấp API cho khách hàng bên thứ 3, bạn cũng phải sử dụng OAuth2. OAuth2 rất linh hoạt. Việc thực hiện JWT rất dễ dàng và không mất nhiều thời gian để thực hiện. Nếu ứng dụng của bạn cần loại linh hoạt này, bạn nên dùng OAuth2. Nhưng nếu bạn không cần kịch bản ca sử dụng này, việc triển khai OAuth2 là một sự lãng phí thời gian.

Mã thông báo XSRF luôn được gửi đến máy khách trong mọi tiêu đề phản hồi. Không có vấn đề gì nếu mã thông báo CSRF được gửi trong mã thông báo JWT hay không, vì mã thông báo CSRF được bảo mật với chính nó. Do đó, việc gửi mã thông báo CSRF trong JWT là không cần thiết.

JWT (JSON Web Tokens) - Nó chỉ là một định dạng mã thông báo. Mã thông báo JWT là các cấu trúc dữ liệu được mã hóa JSON chứa thông tin về nhà phát hành, chủ đề (khiếu nại), thời gian hết hạn, v.v. Nó được ký để chứng minh và xác thực giả mạo và nó có thể được mã hóa để bảo vệ thông tin mã thông báo bằng cách sử dụng phương pháp đối xứng hoặc bất đối xứng. JWT đơn giản hơn SAML 1.1 / 2.0 và được tất cả các thiết bị hỗ trợ và nó mạnh hơn SWT (Mã thông báo web đơn giản).

OAuth2 - OAuth2 giải quyết vấn đề người dùng muốn truy cập dữ liệu bằng phần mềm máy khách như duyệt ứng dụng web dựa trên ứng dụng, ứng dụng di động gốc hoặc ứng dụng máy tính để bàn. OAuth2 chỉ dành cho ủy quyền, phần mềm máy khách có thể được ủy quyền để truy cập tài nguyên thay mặt cho người dùng cuối bằng cách sử dụng mã thông báo truy cập.

OpenID Connect - OpenID Connect xây dựng trên OAuth2 và thêm xác thực. OpenID Connect thêm một số ràng buộc cho OAuth2 như Điểm cuối UserInfo, Mã thông báo ID, khám phá và đăng ký động của nhà cung cấp OpenID Connect và quản lý phiên. JWT là định dạng bắt buộc cho mã thông báo.

Bảo vệ CSRF - Bạn không cần triển khai bảo vệ CSRF nếu bạn không lưu trữ mã thông báo trong cookie của trình duyệt.

Bạn có thể đọc thêm chi tiết tại đây http://proficientblog.com/microservice-security/

Có vẻ như tất cả những người trả lời ở đây đã bỏ lỡ điểm quan trọng của OAUTH

Từ Wikipedia

OAuth là một tiêu chuẩn mở cho ủy quyền truy cập, thường được sử dụng như một cách để người dùng Internet cấp cho các trang web hoặc ứng dụng truy cập thông tin của họ trên các trang web khác nhưng không cung cấp cho họ mật khẩu. [1] Cơ chế này được sử dụng bởi các công ty như Google, Facebook, Microsoft và Twitter để cho phép người dùng chia sẻ thông tin về tài khoản của họ với các ứng dụng hoặc trang web của bên thứ ba.

Điểm mấu chốt ở đây là access delegation. Tại sao mọi người sẽ tạo OAUTH khi có xác thực dựa trên id / pwd, được hỗ trợ bởi các xác thực đa yếu tố như OTP và hơn nữa có thể được bảo mật bởi JWTs được sử dụng để bảo đảm quyền truy cập vào các đường dẫn (như phạm vi trong OAUTH) và đặt hết hạn truy cập

Không có điểm nào sử dụng OAUTH nếu người tiêu dùng truy cập tài nguyên của họ (điểm cuối của bạn) chỉ thông qua các trang web (hoặc ứng dụng) đáng tin cậy của họ được lưu trữ lại trên điểm cuối của bạn

Bạn chỉ có thể xác thực OAUTH nếu bạn là người OAUTH providertrong trường hợp chủ sở hữu tài nguyên (người dùng) muốn truy cập tài nguyên (điểm cuối) của họ thông qua ứng dụng khách bên thứ ba (ứng dụng bên ngoài). Và nó được tạo ra chính xác cho cùng một mục đích mặc dù bạn có thể lạm dụng nó nói chung

Một lưu ý quan trọng khác:
Bạn tự do sử dụng từ authenticationcho JWT và OAUTH nhưng không cung cấp cơ chế xác thực. Có một là một cơ chế mã thông báo và cái còn lại là giao thức nhưng một khi được xác thực, chúng chỉ được sử dụng để ủy quyền (quản lý truy cập). Bạn đã sao lưu OAUTH bằng xác thực loại OPENID hoặc thông tin xác thực ứng dụng khách của riêng bạn

tìm sự khác biệt chính giữa JWT & OAuth

1. OAuth 2.0 định nghĩa một giao thức & JWT định nghĩa định dạng mã thông báo.

2. OAuth có thể sử dụng JWT làm định dạng mã thông báo hoặc mã thông báo truy cập là mã thông báo mang.

3. Kết nối OpenID chủ yếu sử dụng JWT làm định dạng mã thông báo.

JWT là một tiêu chuẩn mở xác định một cách nhỏ gọn và khép kín để truyền thông tin an toàn giữa các bên. Đó là một giao thức xác thực nơi chúng tôi cho phép các khiếu nại được mã hóa (mã thông báo) được chuyển giữa hai bên (máy khách và máy chủ) và mã thông báo được phát hành khi nhận dạng máy khách. Với mỗi yêu cầu tiếp theo, chúng tôi sẽ gửi mã thông báo.

Trong đó OAuth2 là một khung ủy quyền, nơi nó có các quy trình và thiết lập chung được xác định bởi khung. JWT có thể được sử dụng như một cơ chế bên trong OAuth2.

Bạn có thể đọc thêm về điều này ở đây

OAuth hay JWT? Nên dùng cái nào và tại sao?

Câu hỏi là một câu hỏi phổ biến, nhưng nó không hoàn toàn hợp lý. JWT là một loại Mã thông báo và OAuth là Khung mô tả cách phân phối mã thông báo.

"Khung" nghĩa là gì? Chỉ là chuỗi các yêu cầu và phản hồi, và các định dạng của những yêu cầu đó, có thể và nên được sử dụng để yêu cầu mã thông báo. OAuthv2 mô tả các "luồng" riêng biệt hoặc các loại cấp cho các kịch bản khác nhau và có các phần mở rộng khác nhau (như PKCE) để mở rộng bảo mật của các luồng cụ thể.

Kết quả của yêu cầu mã thông báo thông qua trợ cấp OAuthV2 là ... mã thông báo. Điều đó sau đó được sử dụng như một "mã thông báo mang", có nghĩa là, bất kỳ bên nào nắm giữ mã thông báo, có thể xuất trình nó khi thực hiện yêu cầu dịch vụ api (ví dụ: "số dư trên thẻ giá trị được lưu trữ của tôi là gì?"). Là một mã thông báo Bearer, nó hoạt động như tiền mặt. Nếu bạn đang giữ nó, bạn có thể sử dụng nó. (Mặc dù không giống như tiền mặt, mã thông báo không sử dụng và mất nó. Có lẽ một sự tương tự tốt hơn là vé đi cả ngày trên hệ thống giao thông công cộng hoặc vé cả ngày tại Disneyworld.)

JWT là một loại mã thông báo cụ thể và JWT hoàn toàn có thể được sử dụng làm mã thông báo OAuth Bearer. Trong thực tế, đây là thực tế phổ biến nhất. Xét về điều đó, "JWT vs OAuth" là sự so sánh giữa táo và xe táo.

Thông thường mọi người nghĩ rằng "mã thông báo OAuth" luôn ngụ ý mã thông báo mờ - một chuỗi ký tự chữ và số không có ý nghĩa vốn có - được cấp bởi một bộ phân phát mã thông báo OAuth, sau đó chỉ có thể được xác nhận bởi hệ thống phân phối OAuth đó. Nhưng đây không phải là loại mã thông báo OAuth duy nhất. Mã thông báo mờ là một loại mã thông báo; JWT có thể được sử dụng như một loại mã thông báo OAuth khác.

Ngược lại, JWT không mờ đục. JWT không phải là "con trỏ" hoặc tham chiếu thông tin. Nó thực sự chứa nhiều thông tin cụ thể, có thể được trích xuất và giải thích bởi bất kỳ bên nào có mã thông báo. Vì JWT chứa thông tin thực, JWT có thể lớn; 300 byte, 500 byte hoặc nhiều hơn, tùy thuộc vào các khiếu nại có trong nó và thuật toán được sử dụng để ký tên. Khi mọi người nói "JWT đang tự xác thực" ý nghĩa của chúng là gì, bất kỳ chủ sở hữu nào của JWT đều có thể mở nó, xác thực nó và sau đó đưa ra quyết định ủy quyền dựa trên các khiếu nại được trình bày trong đó. Xác thực JWT có nghĩa là: xác minh cấu trúc của nó, giải mã mã hóa base64, xác minh khóa là chính xác, xác minh chữ ký, sau đó xác minh các yêu cầu bắt buộc có trong mã thông báo, kiểm tra hết hạn. Đó không phải là một điều đơn giản, thay vì một quá trình gồm nhiều bước, nhưng tất nhiên có rất nhiều thư viện bằng nhiều ngôn ngữ lập trình khác nhau, và tất nhiên có chính sách ConfirmJWT giúp bạn thực hiện điều này trong proxy API Apigee Edge. Vấn đề là, bất kỳ chủ sở hữu hoặc người nhận có thể xác minh mã thông báo. Vì điều này, chúng tôi nói rằng JWT hỗ trợ "Liên kết" - bất kỳ ai cũng có thể tạo mã thông báo và bất kỳ ai cũng có thể đọc và xác thực mã thông báo.

yêu cầu tùy chỉnh. Cả JWT và mã thông báo OAuth mờ đục đều có thể mang các khiếu nại tùy chỉnh về chủ đề này. Bảo vệ. Cả hai đều là mã thông báo mang. Cả hai cần được bảo vệ như bí mật. hết hạn Cả hai có thể được đánh dấu với một hết hạn. Cả hai có thể được làm mới. Các cơ chế xác thực hoặc kinh nghiệm. Cả hai có thể trình bày cùng một trải nghiệm người dùng.

Jwt là một bộ hướng dẫn nghiêm ngặt để phát hành và xác thực các mã thông báo truy cập đã ký. Các mã thông báo chứa các khiếu nại được sử dụng bởi một ứng dụng để giới hạn quyền truy cập đối với người dùng

Mặt khác, OAuth2 không phải là một giao thức, là khung ủy quyền được ủy quyền. nghĩ hướng dẫn rất chi tiết, để cho phép người dùng và ứng dụng ủy quyền các quyền cụ thể cho các ứng dụng khác trong cả cài đặt riêng tư và công khai. OpenID Connect nằm trên OAUTH2 cung cấp cho bạn Xác thực và Ủy quyền. Chi tiết có bao nhiêu vai trò khác nhau, người dùng trong hệ thống của bạn, ứng dụng phía máy chủ như API và ứng dụng khách như trang web hoặc ứng dụng di động gốc có thể xác thực với từng othe

Lưu ý oauth2 có thể hoạt động với jwt, triển khai linh hoạt, có thể mở rộng cho các ứng dụng khác nhau