Mục đích của loại ủy quyền cấp ẩn trong OAuth 2 là gì?

Tôi không biết nếu tôi chỉ có một số điểm mù hay gì đó, nhưng tôi đã đọc thông số kỹ thuật OAuth 2 nhiều lần và đọc các tài liệu lưu trữ danh sách gửi thư, và tôi vẫn chưa tìm thấy một lời giải thích tốt về lý do tại sao Tài trợ ngầm lưu lượng để lấy mã thông báo truy cập đã được phát triển. So với Cấp phép mã ủy quyền, dường như chỉ từ bỏ xác thực ứng dụng khách mà không có lý do rất thuyết phục. Làm thế nào điều này được "tối ưu hóa cho các máy khách được triển khai trong trình duyệt sử dụng ngôn ngữ kịch bản" (để trích dẫn đặc tả)?

Cả hai luồng bắt đầu giống nhau (nguồn: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

1. Máy khách khởi tạo luồng bằng cách hướng tác nhân người dùng của tài nguyên đến điểm cuối ủy quyền.
2. Máy chủ ủy quyền xác thực chủ sở hữu tài nguyên (thông qua tác nhân người dùng) và thiết lập xem chủ sở hữu tài nguyên có cấp hoặc từ chối yêu cầu truy cập của khách hàng hay không.
3. Giả sử chủ sở hữu tài nguyên cấp quyền truy cập, máy chủ ủy quyền sẽ chuyển hướng tác nhân người dùng trở lại máy khách bằng cách sử dụng URI chuyển hướng được cung cấp trước đó (trong yêu cầu hoặc trong quá trình đăng ký máy khách).
   • URI chuyển hướng bao gồm mã ủy quyền (luồng mã ủy quyền)
   • URI chuyển hướng bao gồm mã thông báo truy cập trong đoạn URI (Luồng ngầm định)

Đây là nơi dòng chảy phân chia. Trong cả hai trường hợp, URI chuyển hướng tại thời điểm này là một số điểm cuối được lưu trữ bởi máy khách:

• Trong luồng mã ủy quyền, khi tác nhân người dùng chạm vào điểm cuối đó bằng mã ủy quyền trong URI, mã tại điểm cuối đó trao đổi mã ủy quyền cùng với thông tin xác thực ứng dụng khách của nó để lấy mã thông báo truy cập mà sau đó có thể sử dụng khi cần. Nó có thể, ví dụ, viết nó vào một trang web mà một tập lệnh trên trang có thể truy cập.
• Luồng tiềm ẩn bỏ qua bước xác thực ứng dụng khách này hoàn toàn và chỉ tải lên một trang web với tập lệnh máy khách. Có một mẹo dễ thương ở đây với đoạn URL giữ cho mã thông báo truy cập không bị chuyển qua quá nhiều, nhưng kết quả cuối cùng về cơ bản là giống nhau: trang web được lưu trữ trên máy khách phục vụ một trang có một số tập lệnh có thể lấy mã thông báo truy cập .
  

Do đó câu hỏi của tôi: những gì đã đạt được ở đây bằng cách bỏ qua bước xác thực ứng dụng khách?

Đây là suy nghĩ của tôi:

Mục đích của mã xác thực + mã thông báo trong luồng mã ủy quyền là mã thông báo và bí mật máy khách sẽ không bao giờ được hiển thị cho chủ sở hữu tài nguyên vì chúng di chuyển từ máy chủ đến máy chủ.

Mặt khác, luồng cấp quyền ngầm dành cho các máy khách được triển khai hoàn toàn bằng javascript và đang chạy trong trình duyệt của chủ sở hữu tài nguyên. Bạn không cần bất kỳ mã phía máy chủ để sử dụng luồng này. Sau đó, nếu mọi thứ xảy ra trong trình duyệt của chủ sở hữu tài nguyên, sẽ không có ý nghĩa gì khi phát hành mã xác thực & bí mật máy khách nữa, vì mã thông báo & bí mật máy khách vẫn sẽ được chia sẻ với chủ sở hữu tài nguyên. Bao gồm mã xác thực & bí mật máy khách chỉ làm cho luồng phức tạp hơn mà không cần thêm bất kỳ bảo mật thực sự nào.

Vì vậy, câu trả lời về "những gì đã đạt được?" là "sự đơn giản".

Đó là vì lý do bảo mật, không phải vì đơn giản.

Bạn nên xem xét sự khác biệt giữa tác nhân người dùng và ứng dụng khách :

Tác nhân người dùng là phần mềm theo đó người dùng ("chủ sở hữu tài nguyên") giao tiếp với các bộ phận khác của hệ thống (máy chủ xác thực và máy chủ tài nguyên).

Máy khách là phần mềm muốn truy cập tài nguyên của người dùng trên máy chủ tài nguyên.

Trong trường hợp phân tách tác nhân người dùng và ứng dụng khách, Cấp phép mã ủy quyền có ý nghĩa. Ví dụ: người dùng sử dụng trình duyệt web (tác nhân người dùng) để đăng nhập bằng tài khoản Facebook của mình trên Kickstarter. Trong trường hợp này, máy khách là một trong những máy chủ của Kickstarter, xử lý thông tin đăng nhập của người dùng. Máy chủ này nhận được mã thông báo truy cập và mã thông báo làm mới từ Facebook. Do đó, loại ứng dụng khách này được coi là "an toàn", do quyền truy cập bị hạn chế, mã thông báo có thể được lưu và Kickstarter có thể truy cập tài nguyên của người dùng và thậm chí làm mới mã thông báo truy cập mà không cần tương tác của người dùng.

Nếu tác nhân người dùng và máy khách được ghép nối (ví dụ: ứng dụng di động gốc, ứng dụng javascript), quy trình ủy quyền ngầm có thể được áp dụng. Nó phụ thuộc vào sự hiện diện của chủ sở hữu tài nguyên (để nhập thông tin đăng nhập) và không hỗ trợ mã thông báo làm mới. Nếu khách hàng này lưu trữ mã thông báo truy cập để sử dụng sau này, đó sẽ là một vấn đề bảo mật, bởi vì mã thông báo có thể dễ dàng được trích xuất bởi các ứng dụng hoặc người dùng khác của khách hàng. Sự vắng mặt của mã thông báo làm mới là một gợi ý bổ sung, rằng phương pháp này không được thiết kế để truy cập tài nguyên người dùng trong trường hợp không có người dùng.

Giải thích thông thường là trợ cấp ngầm sẽ dễ thực hiện hơn khi bạn đang sử dụng máy khách JavaScript. Nhưng tôi nghĩ rằng đây là cách sai để xem xét nó. Nếu bạn đang sử dụng ứng dụng khách JavaScript yêu cầu tài nguyên được bảo vệ trực tiếp thông qua XMLHttpRequest, thì Cấp quyền ngầm là tùy chọn duy nhất của bạn, mặc dù nó kém an toàn hơn. *

Cấp mã ủy quyền cung cấp bảo mật bổ sung, nhưng nó chỉ hoạt động khi bạn có máy chủ web yêu cầu tài nguyên được bảo vệ. Vì máy chủ web có thể lưu trữ mã thông báo truy cập, bạn sẽ ít gặp rủi ro hơn khi mã thông báo truy cập được tiếp xúc với Internet và bạn có thể phát hành mã thông báo tồn tại trong một thời gian dài. Và vì máy chủ web được tin cậy, nó có thể được cấp "mã thông báo làm mới", do đó, nó có thể nhận được mã thông báo truy cập mới khi cái cũ hết hạn.

Nhưng - và đây là một điểm rất dễ bỏ lỡ - bảo mật của luồng mã ủy quyền chỉ hoạt động nếu máy chủ web được bảo vệ bằng một phiên, được thiết lập với xác thực người dùng (đăng nhập). Nếu không có phiên, người dùng không tin cậy có thể chỉ yêu cầu máy chủ web, sử dụng client_id và nó sẽ giống như khi người dùng có mã thông báo truy cập. Thêm một phiên có nghĩa là chỉ người dùng được xác thực mới có thể truy cập các tài nguyên được bảo vệ. Client_id chỉ là "danh tính" của ứng dụng web JS, không phải là xác thực của ứng dụng web đã nói.

Điều đó cũng có nghĩa là bạn có thể kết thúc phiên trước khi mã thông báo OAuth hết hạn. Không có cách tiêu chuẩn nào để vô hiệu hóa mã thông báo truy cập. Nhưng nếu phiên của bạn hết hạn, mã thông báo truy cập là vô ích, vì không ai biết điều đó ngoài máy chủ web. Nếu người dùng không tin cậy có được quyền truy cập vào khóa phiên của bạn, họ sẽ chỉ có thể truy cập các tài nguyên được bảo vệ miễn là phiên hợp lệ.

Nếu không có máy chủ web, bạn phải sử dụng khoản trợ cấp tiềm ẩn. Nhưng điều này có nghĩa là mã thông báo truy cập được tiếp xúc với Internet. Nếu người dùng không tin cậy có quyền truy cập vào nó, họ có thể sử dụng nó cho đến khi hết hạn. Điều này có nghĩa là họ sẽ có quyền truy cập lâu hơn so với cấp Mã ủy quyền. Vì vậy, bạn có thể muốn xem xét việc làm cho mã thông báo hết hạn sớm hơn và tránh cấp quyền truy cập vào các tài nguyên nhạy cảm hơn.

* CHỈNH SỬA: Gần đây, mọi người khuyên bạn nên tránh sử dụng khoản Trợ cấp ngầm, ngay cả trên các ứng dụng web không có máy chủ. Thay vào đó, bạn có thể sử dụng cấp phép Mã ủy quyền được định cấu hình với một bí mật trống, cùng với PKCE. Cấp mã xác thực sẽ tránh lưu trữ mã thông báo truy cập trong lịch sử trình duyệt của bạn và PKCE tránh phơi bày nếu ai đó chiếm quyền điều khiển URL chuyển hướng để đánh cắp mã xác thực. Trong trường hợp này, bạn sẽ cần máy chủ để tránh trả lại mã thông báo, vì khách hàng của bạn có thể không lưu trữ an toàn. Và nó sẽ phát hành một mã thông báo truy cập với cùng các giới hạn được đề cập ở trên.

Nó hiểu rõ: Nếu người dùng đang chạy ứng dụng web dựa trên trình duyệt hoặc "công khai", (JavaScript) không có thành phần phía máy chủ, thì người dùng sẽ hoàn toàn tin tưởng vào ứng dụng (và trình duyệt nơi nó chạy, có khả năng với trình duyệt khác các ứng dụng dựa trên ...).

Không có máy chủ từ xa của bên thứ 3, chỉ có máy chủ tài nguyên. Không có lợi cho mã ủy quyền, vì không có tác nhân nào khác ngoài trình duyệt hoạt động thay mặt cho người dùng. Không có lợi ích cho thông tin khách hàng cho cùng một lý do. ( Bất kỳ khách hàng nào cũng có thể cố gắng sử dụng luồng này.)

Ý nghĩa bảo mật, tuy nhiên, là đáng kể. Từ http://tools.ietf.org/html/rfc6749#section-10.3 :

Khi sử dụng loại cấp quyền ngầm, mã thông báo truy cập được truyền trong đoạn URI, có thể hiển thị nó cho các bên trái phép.

Từ http://tools.ietf.org/html/rfc6749#section-10.16 :

Chủ sở hữu tài nguyên có thể sẵn sàng ủy quyền truy cập vào tài nguyên bằng cách cấp mã thông báo truy cập cho khách hàng độc hại của kẻ tấn công. Điều này có thể là do lừa đảo hoặc một số lý do khác ...

Tôi không chắc rằng tôi hiểu chính xác câu trả lời và nhận xét của Dan. Dường như với tôi rằng câu trả lời đã nêu một số sự thật chính xác nhưng nó chỉ ra chính xác những gì OP yêu cầu. Nếu tôi hiểu chính xác, lợi thế chính của luồng cấp quyền ngầm là một ứng dụng khách như ứng dụng JS (ví dụ: tiện ích mở rộng Chrome) không phải tiết lộ bí mật của máy khách.

Dan Taflin nói:

... trong luồng mã ủy quyền, chủ sở hữu tài nguyên không bao giờ cần phải xem mã thông báo truy cập, trong khi đó trong các máy khách javascript là điều không thể tránh khỏi. Tuy nhiên, bí mật của khách hàng vẫn có thể được giữ từ các máy khách javascript bằng cách sử dụng luồng mã ủy quyền ..

Có lẽ tôi đã hiểu nhầm bạn, nhưng ứng dụng khách (ứng dụng JS trong trường hợp này) phải chuyển thông tin xác thực ứng dụng khách (khóa khách và bí mật) cho máy chủ tài nguyên trong luồng mã ủy quyền, phải không? Bí mật của máy khách không thể được "giữ từ JS".

Mặc dù Grant tiềm ẩn được thiết kế để hỗ trợ các ứng dụng không thể bảo vệ bí mật của khách hàng bao gồm các ứng dụng JavaScript phía máy khách, một số nhà cung cấp đang triển khai thay thế bằng Mã ủy quyền mà không có Bí mật khách hàng thay thế. OAuth 2.0 IETF RFC-6749 đã được xuất bản vào năm 2012 và các khuyến nghị hiện tại một số cuộc thảo luận gần đây là từ năm 2017.

Thảo luận năm 2017 về danh sách gửi thư của IETF OAuth có sẵn từ những người triển khai này:

• Redhat: https://www.ietf.org/.../oauth/c Hiện / msg16966.html
• Deutsche Telekom: https://www.ietf.org/.../oauth/c Hiện / msg16968.html
• CNTT về sức khỏe thông minh: https://www.ietf.org/.../oauth/c Hiện / msg16967.html

Đọc thêm tại đây:

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Ngẫu nhiên trước đây được khuyến nghị cho khách hàng mà không có bí mật, nhưng đã được thay thế bằng cách sử dụng cấp Mã ủy quyền mà không có bí mật.

...

Trước đây, các ứng dụng dựa trên trình duyệt được khuyến nghị sử dụng luồng "Ngẫu nhiên", trả về mã thông báo truy cập ngay lập tức và không có bước trao đổi mã thông báo. Trong thời gian kể từ khi thông số ban đầu được viết, thực tiễn tốt nhất trong ngành đã thay đổi để khuyến nghị sử dụng luồng mã ủy quyền mà không cần bí mật của máy khách. Điều này cung cấp nhiều cơ hội hơn để tạo ra một luồng an toàn, chẳng hạn như sử dụng tham số trạng thái. Tài liệu tham khảo: Redhat , Deutsche Telekom , Smart Health IT .

Chuyển sang Mã xác thực mà không có Bí mật khách hàng từ Cấp ẩn cũng được đề cập cho các ứng dụng di động tại đây:

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

ngoài các câu trả lời khác, điều quan trọng là phải nhận ra rằng cấu hình Ngầm cho phép luồng chỉ ở phía trước trái ngược với luồng Mã ủy quyền yêu cầu gọi lại Máy chủ ủy quyền; điều này trở nên rõ ràng trong OpenID Connect, một giao thức SSO được xây dựng trên Auth 2.0, trong đó luồng Implicit giống với ràng buộc SAML POST khá phổ biến và luồng Mã ủy quyền giống như liên kết SAML Artifact ít được triển khai rộng rãi

Trong luồng ngầm nếu trình duyệt của người dùng bị hỏng (phần mở rộng / vi rút xấu) thì tham nhũng được quyền truy cập vào tài nguyên của người dùng và có thể thực hiện các nội dung xấu.

Trong luồng xác thực, tham nhũng không thể vì nó không biết bí mật của khách hàng.

https://tools.ietf.org/html/rfc6749#page-8

Tiềm ẩn

Cấp quyền ngầm là luồng mã ủy quyền được đơn giản hóa được tối ưu hóa cho các máy khách được triển khai trong trình duyệt sử dụng ngôn ngữ tập lệnh như JavaScript. Trong luồng ngầm định, thay vì cấp cho khách hàng mã ủy quyền, khách hàng được cấp mã thông báo truy cập trực tiếp (do kết quả của ủy quyền chủ sở hữu tài nguyên). Loại cấp là ẩn, vì không có thông tin xác thực trung gian (như mã ủy quyền) được cấp (và sau này được sử dụng để có được mã thông báo truy cập).

Khi phát hành mã thông báo truy cập trong luồng cấp
quyền ngầm, máy chủ ủy quyền không xác thực ứng dụng khách. Trong một số
trường hợp, danh tính khách hàng có thể được xác minh thông qua URI chuyển hướng
được sử dụng để phân phối mã thông báo truy cập đến máy khách. Mã thông báo truy cập có thể được hiển thị cho chủ sở hữu tài nguyên hoặc các ứng dụng khác có quyền truy cập vào tác nhân người dùng của chủ tài nguyên.

Các khoản trợ cấp ngầm cải thiện khả năng đáp ứng và hiệu quả của một số
khách hàng (chẳng hạn như ứng dụng khách được triển khai dưới dạng ứng dụng trên trình duyệt),
vì nó làm giảm số lượng các chuyến đi khứ hồi cần thiết để có được
mã thông báo truy cập.

Tôi nghĩ Will Cain đã trả lời điều này khi anh ta nói "Không có lợi cho thông tin khách hàng vì lý do tương tự. (Bất kỳ khách hàng nào cũng có thể cố gắng sử dụng luồng này.)" được tạo từ Máy chủ ủy quyền cho luồng ngầm. Vì không có cách nào để tin tưởng trước khách hàng, người dùng sẽ phải chấp thuận việc đưa ra yêu cầu của người dùng.

Cấp ẩn tiềm ẩn cho phép nhận mã thông báo từ Điểm cuối ủy quyền với a GET. Điều này có nghĩa là máy chủ ủy quyền không phải hỗ trợ CORS.

Nếu đó không phải là vấn đề đáng lo ngại và không có vấn đề nào khác liên quan đến máy chủ ủy quyền là không linh hoạt (ví dụ: mã thông báo làm mới không phải là tùy chọn) thì luồng mã ủy quyền là ưu tiên, ngay cả đối với khách hàng công cộng, theo xu hướng công nghiệp gần đây và ít nhất là trường hợp này (hiện tại) của một dự thảo chính thức .

Trong lịch sử có những lý do khác để thực hiện luồng ngầm nhưng có vẻ như chúng hiện đang vượt trội hơn bởi các lợi thế bảo mật mà việc cấp mã ủy quyền cung cấp, bao gồm:

• tùy chọn phân phối và sử dụng mã thông báo qua kênh ngược cho khách hàng bí mật
• không để lộ mã thông báo trong lịch sử trình duyệt cho khách hàng công cộng
• làm gián đoạn một luồng trái phép trước khi mã thông báo được phát hành - với PKCE , cho "tất cả các loại máy khách OAuth"

Tôi vừa đối mặt với một số bài viết về OAuth 2.0. Tác giả nói rằng lý do đằng sau luồng tiềm ẩn là các ứng dụng JS bị hạn chế rất nhiều trong các yêu cầu:

nếu bạn thắc mắc tại sao loại ẩn được đưa vào OAuth 2.0, thì lời giải thích rất đơn giản: Chính sách xuất xứ tương tự. Trước đó, các ứng dụng lối vào không được phép gửi yêu cầu đến các máy chủ khác nhau để nhận mã thông báo truy cập bằng mã. Hôm nay chúng tôi có CORS (Chia sẻ tài nguyên chéo).

https://medium.com/securing/what-is- màng-on-with-lauth-2-