Sự khác biệt giữa OpenID và OAuth là gì?

Tôi thực sự đang cố gắng để hiểu sự khác biệt giữa OpenID và OAuth? Có lẽ chúng là hai thứ hoàn toàn riêng biệt?

OpenID là về xác thực (ví dụ: chứng minh bạn là ai), OAuth là về ủy quyền (nghĩa là cấp quyền truy cập vào chức năng / dữ liệu / vv .. mà không phải xử lý xác thực ban đầu).

OAuth có thể được sử dụng trong các trang đối tác bên ngoài để cho phép truy cập dữ liệu được bảo vệ mà không cần phải xác thực lại người dùng.

Bài đăng trên blog " OpenID so với OAuth từ góc nhìn của người dùng " có một so sánh đơn giản giữa hai từ góc nhìn của người dùng và " OAuth-OpenID: Bạn đang sủa lên cây sai nếu bạn nghĩ rằng họ giống nhau " có nhiều thông tin hơn về nó.

Có ba cách để so sánh OAuth và OpenID:

1. Mục đích

OpenID được tạo để xác thực liên kết, nghĩa là cho phép bên thứ ba xác thực người dùng của bạn cho bạn, bằng cách sử dụng các tài khoản họ đã có . Thuật ngữ được liên kết ở đây rất quan trọng vì toàn bộ quan điểm của OpenID là bất kỳ nhà cung cấp nào cũng có thể được sử dụng (ngoại trừ danh sách trắng). Bạn không cần phải chọn trước hoặc đàm phán thỏa thuận với các nhà cung cấp để cho phép người dùng sử dụng bất kỳ tài khoản nào khác mà họ có.

OAuth được tạo ra để loại bỏ nhu cầu người dùng chia sẻ mật khẩu của họ với các ứng dụng của bên thứ ba . Nó thực sự bắt đầu như một cách giải quyết vấn đề OpenID: nếu bạn hỗ trợ OpenID trên trang web của mình, bạn không thể sử dụng thông tin xác thực HTTP (tên người dùng và mật khẩu) để cung cấp API vì người dùng không có mật khẩu trên trang web của bạn.

Vấn đề là với sự phân tách OpenID này để xác thực và OAuth cho ủy quyền là cả hai giao thức có thể thực hiện nhiều điều giống nhau. Mỗi cái cung cấp một tập hợp các tính năng khác nhau được mong muốn bởi các triển khai khác nhau nhưng về cơ bản, chúng có thể thay thế cho nhau. Về cốt lõi, cả hai giao thức đều là phương thức xác minh xác nhận (OpenID bị giới hạn ở 'đây là tôi là ai', trong khi OAuth cung cấp 'mã thông báo truy cập' có thể được trao đổi cho bất kỳ xác nhận được hỗ trợ nào thông qua API).

2. Tính năng

Cả hai giao thức cung cấp một cách để một trang web chuyển hướng người dùng ở một nơi khác và quay lại với một xác nhận có thể kiểm chứng. OpenID cung cấp xác nhận danh tính trong khi OAuth chung chung hơn dưới dạng mã thông báo truy cập, sau đó có thể được sử dụng để "đặt câu hỏi cho nhà cung cấp OAuth" . Tuy nhiên, mỗi loại đều hỗ trợ các tính năng khác nhau:

OpenID - tính năng quan trọng nhất của OpenID là quá trình khám phá của nó. OpenID không yêu cầu mã hóa cứng mỗi nhà cung cấp bạn muốn sử dụng trước thời hạn. Sử dụng khám phá, người dùng có thể chọn bất kỳ nhà cung cấp bên thứ ba nào họ muốn xác thực. Tính năng khám phá này cũng đã gây ra hầu hết các sự cố của OpenID bởi vì cách nó được triển khai là bằng cách sử dụng HTTP URI làm định danh mà hầu hết người dùng web không nhận được. Các tính năng khác OpenID có là hỗ trợ đăng ký khách hàng đặc biệt bằng cách sử dụng trao đổi DH, chế độ ngay lập tức để tối ưu hóa trải nghiệm người dùng cuối và cách xác minh các xác nhận mà không cần thực hiện một chuyến đi khứ hồi nào cho nhà cung cấp.

OAuth - tính năng quan trọng nhất của OAuth là mã thông báo truy cập cung cấp phương thức lâu dài để thực hiện các yêu cầu bổ sung. Không giống như OpenID, OAuth không kết thúc bằng xác thực nhưng cung cấp mã thông báo truy cập để có quyền truy cập vào các tài nguyên bổ sung được cung cấp bởi cùng dịch vụ của bên thứ ba. Tuy nhiên, vì OAuth không hỗ trợ khám phá, nó yêu cầu lựa chọn trước và mã hóa cứng các nhà cung cấp mà bạn quyết định sử dụng. Người dùng truy cập trang web của bạn không thể sử dụng bất kỳ số nhận dạng nào, chỉ những người được bạn chọn trước. Ngoài ra, OAuth không có khái niệm về danh tính nên sử dụng nó để đăng nhập có nghĩa là thêm một tham số tùy chỉnh (như được thực hiện bởi Twitter) hoặc thực hiện một lệnh gọi API khác để có được người dùng hiện đang "đăng nhập".

3. Triển khai kỹ thuật

Hai giao thức chia sẻ một kiến ​​trúc phổ biến trong việc sử dụng chuyển hướng để có được sự cho phép của người dùng. Trong OAuth, người dùng cho phép truy cập vào các tài nguyên được bảo vệ của họ và trong OpenID, đối với danh tính của họ. Nhưng đó là tất cả những gì họ chia sẻ.

Mỗi giao thức có một cách tính chữ ký khác nhau được sử dụng để xác minh tính xác thực của yêu cầu hoặc phản hồi và mỗi giao thức có các yêu cầu đăng ký khác nhau.

OpenID (chủ yếu) để nhận dạng / xác thực, để stackoverflow.combiết rằng tôi sở hữu chris.boyle.name(hoặc bất cứ nơi nào) và do đó tôi có thể là người sở hữu chris.boyle.namengày hôm qua và kiếm được một số điểm danh tiếng.

OAuth được thiết kế để ủy quyền thực hiện các hành động thay mặt bạn, để stackoverflow.com(hoặc bất cứ nơi nào) có thể tự động cho phép, nói, Tweet thay mặt bạn, mà không cần biết mật khẩu Twitter của bạn.

Nhiều người vẫn truy cập vào đây vì vậy đây là một sơ đồ rất đơn giản để giải thích nó

Wikipedia lịch sự

Ôi

Chỉ được sử dụng cho ủy quyền authorization- có nghĩa là bạn cho phép truy cập dịch vụ của bên thứ ba để sử dụng dữ liệu cá nhân mà không đưa ra mật khẩu. Ngoài ra "phiên" OAuth thường sống lâu hơn phiên người dùng. Có nghĩa là OAuth được thiết kế để cho phép ủy quyền

tức là Flickr sử dụng OAuth để cho phép các dịch vụ của bên thứ ba đăng và chỉnh sửa ảnh của một người thay mặt họ mà không cần phải cung cấp tên người dùng và mật khẩu nhấp nháy.

OpenID

Được sử dụng để nhận authenticatedạng đăng nhập một lần. Tất cả OpenID được cho là phải làm là cho phép nhà cung cấp OpenID chứng minh rằng bạn nói bạn là. Tuy nhiên, nhiều trang web sử dụng xác thực danh tính để cung cấp ủy quyền (tuy nhiên hai trang web có thể được tách ra)

tức là Một người cho xem hộ chiếu của họ tại sân bay để xác thực (hoặc chứng minh) tên của người đó trên vé họ đang sử dụng là họ.

Sử dụng OAuth nếu người dùng của bạn có thể chỉ muốn đăng nhập bằng Facebook hoặc Twitter. Sử dụng OpenID nếu người dùng của bạn là những người yêu thích chạy các nhà cung cấp OpenID của riêng họ vì họ "không muốn ai khác sở hữu danh tính của họ".

• OpenID là một giao thức xác thực tiêu chuẩn và phi tập trung được kiểm soát bởi OpenID Foundation.
• OAuth là một tiêu chuẩn mở cho phái đoàn truy cập.
• OpenID Connect (OIDC) Kết hợp các tính năng của OpenID và OAuth tức là cả Xác thực và Ủy quyền.

OpenID có dạng URI duy nhất được quản lý bởi một số "nhà cung cấp OpenID" tức là nhà cung cấp nhận dạng (idP).

Ôi có thể được sử dụng cùng với XACML trong đó OAuth được sử dụng để ủy quyền sở hữu và ủy quyền truy cập trong khi XACML được sử dụng để xác định các chính sách ủy quyền.

OIDC sử dụng Mã thông báo Web JSON đơn giản (JWT) mà bạn có thể có được bằng cách sử dụng các luồng tuân theo thông số kỹ thuật của OAuth 2.0 . OAuth liên quan trực tiếp đến OIDC vì OIDC là lớp xác thực được xây dựng trên OAuth 2.0 .

Ví dụ: nếu bạn chọn đăng nhập vào Auth0 bằng tài khoản Google của mình thì bạn đã sử dụng OIDC . Khi bạn xác thực thành công với Google và cho phép Auth0 truy cập thông tin của bạn, Google sẽ gửi lại thông tin Auth0 về người dùng và xác thực được thực hiện. Thông tin này được trả về trong Mã thông báo Web JSON (JWT). Bạn sẽ nhận được Mã thông báo truy cập và, nếu được yêu cầu, Mã thông báo ID. Các loại Mã : Nguồn: OpenID Connect

Tương tự :
Một tổ chức sử dụng thẻ ID cho mục đích nhận dạng và nó chứa chip, nó lưu trữ thông tin chi tiết về Nhân viên cùng với Quyền truy cập, ví dụ như quyền truy cập vào Khuôn viên / Cổng / ODC. Thẻ ID hoạt động như một OIDC và Chip hoạt động như một OAuth . thêm ví dụ và hình thức wiki

OpenID và OAuth là mỗi giao thức dựa trên HTTP để xác thực và / hoặc ủy quyền. Cả hai đều nhằm mục đích cho phép người dùng thực hiện các hành động mà không cần cung cấp thông tin xác thực hoặc quyền hạn cho khách hàng hoặc bên thứ ba. Mặc dù chúng tương tự nhau, và có các tiêu chuẩn được đề xuất để sử dụng cả hai cùng nhau, chúng là các giao thức riêng biệt.

OpenID được dành cho xác thực liên kết. Một khách hàng chấp nhận xác nhận danh tính từ bất kỳ nhà cung cấp nào (mặc dù khách hàng được miễn phí danh sách trắng hoặc nhà cung cấp danh sách đen).

OAuth được dành cho ủy quyền. Một khách hàng đăng ký với một nhà cung cấp, cung cấp mã thông báo ủy quyền mà họ sẽ chấp nhận thực hiện các hành động thay mặt người dùng.

OAuth hiện phù hợp hơn để ủy quyền, bởi vì các tương tác tiếp theo sau khi xác thực được tích hợp vào giao thức, nhưng cả hai giao thức đều đang phát triển. OpenID và các phần mở rộng của nó có thể được sử dụng để ủy quyền và OAuth có thể được sử dụng để xác thực, có thể được coi là ủy quyền không hoạt động.

Tôi tin rằng nó có ý nghĩa khi xem lại câu hỏi này cũng như được chỉ ra trong các bình luận, việc giới thiệu OpenID Connect có thể đã mang lại nhiều nhầm lẫn.

OpenID Connect là một giao thức xác thực như OpenID 1.0 / 2.0 nhưng nó thực sự được xây dựng dựa trên OAuth 2.0, vì vậy bạn sẽ nhận được các tính năng ủy quyền cùng với các tính năng xác thực. Sự khác biệt giữa hai điều này được giải thích khá chi tiết trong bài viết này (tương đối gần đây, nhưng quan trọng): http://oauth.net/articles/authentication/

Giải thích về sự khác biệt giữa OpenID, OAuth, OpenID Connect:

OpenID là một giao thức để xác thực trong khi OAuth là ủy quyền. Xác thực là về việc đảm bảo rằng người mà bạn đang nói chuyện thực sự là người mà anh ta tuyên bố là. Ủy quyền là về việc quyết định những gì anh chàng đó nên được phép làm.

Trong OpenID, xác thực được ủy quyền: máy chủ A muốn xác thực người dùng U, nhưng thông tin đăng nhập của U (ví dụ tên và mật khẩu của U) được gửi đến một máy chủ khác, B, mà A tin tưởng (ít nhất là tin tưởng để xác thực người dùng). Thật vậy, máy chủ B đảm bảo rằng U thực sự là U, và sau đó nói với A: "ok, đó là U chính hãng".

Trong OAuth, ủy quyền được ủy quyền: thực thể A có được từ thực thể B một "quyền truy cập" mà A có thể hiển thị cho máy chủ S để được cấp quyền truy cập; Do đó, B có thể cung cấp các khóa truy cập cụ thể, tạm thời cho A mà không cung cấp cho chúng quá nhiều năng lượng. Bạn có thể tưởng tượng một máy chủ OAuth là chủ nhân chính trong một khách sạn lớn; anh ta đưa cho nhân viên chìa khóa mở cửa của các phòng mà họ phải vào, nhưng mỗi chìa khóa đều bị giới hạn (nó không cho phép truy cập vào tất cả các phòng); hơn nữa, các phím tự hủy sau vài giờ.

Ở một mức độ nào đó, ủy quyền có thể bị lạm dụng vào một số xác thực giả, trên cơ sở rằng nếu thực thể A có được từ B một khóa truy cập thông qua OAuth và hiển thị nó cho máy chủ S, thì máy chủ S có thể suy ra rằng B đã xác thực A trước khi cấp quyền truy cập Chìa khóa. Vì vậy, một số người sử dụng OAuth nơi họ nên sử dụng OpenID. Lược đồ này có thể hoặc không thể khai sáng; nhưng tôi nghĩ việc xác thực giả này khó hiểu hơn bất cứ điều gì. OpenID Connect thực hiện điều đó: nó lạm dụng OAuth vào một giao thức xác thực. Tương tự trong khách sạn: nếu tôi gặp một nhân viên có mục đích và người đó cho tôi thấy rằng anh ta có chìa khóa mở phòng tôi, thì tôi cho rằng đây là một nhân viên thực thụ, trên cơ sở chủ nhân chìa khóa sẽ không đưa cho anh ta chìa khóa Nó sẽ mở phòng tôi nếu anh ta không.

(nguồn)

OpenID Connect khác với OpenID 2.0 như thế nào?

OpenID Connect thực hiện nhiều tác vụ giống như OpenID 2.0, nhưng thực hiện theo cách thân thiện với API và có thể sử dụng được bởi các ứng dụng gốc và di động. OpenID Connect xác định các cơ chế tùy chọn để ký và mã hóa mạnh mẽ. Trong khi tích hợp OAuth 1.0a và OpenID 2.0 cần có một phần mở rộng, trong OpenID Connect, các khả năng của OAuth 2.0 được tích hợp với chính giao thức.

(nguồn)

Kết nối OpenID sẽ cung cấp cho bạn mã thông báo truy cập cộng với mã thông báo id. Mã thông báo id là JWT và chứa thông tin về người dùng được xác thực. Nó được ký bởi nhà cung cấp nhận dạng và có thể được đọc và xác minh mà không cần truy cập vào nhà cung cấp nhận dạng.

Ngoài ra, kết nối OpenID tiêu chuẩn hóa khá nhiều thứ mà oauth2 để lại tùy chọn. ví dụ phạm vi, khám phá điểm cuối và đăng ký động của khách hàng.

Điều này giúp viết mã dễ dàng hơn cho phép người dùng lựa chọn giữa nhiều nhà cung cấp nhận dạng.

(nguồn)

OAuth 2.0 của Google

API OAuth 2.0 của Google có thể được sử dụng cho cả xác thực và ủy quyền. Tài liệu này mô tả triển khai OAuth 2.0 của chúng tôi để xác thực, phù hợp với đặc điểm kỹ thuật OpenID Connect và được chứng nhận OpenID. Tài liệu được tìm thấy trong Sử dụng OAuth 2.0 để truy cập Google API cũng áp dụng cho dịch vụ này. Nếu bạn muốn khám phá giao thức này một cách tương tác, chúng tôi khuyên dùng Sân chơi Google OAuth 2.0 .

(nguồn)

Nhiều phần mở rộng cho câu hỏi hơn là một câu trả lời, nhưng nó có thể thêm một số quan điểm cho các câu trả lời kỹ thuật tuyệt vời ở trên. Tôi là một lập trình viên có kinh nghiệm trong một số lĩnh vực, nhưng hoàn toàn không biết lập trình cho web. Hiện đang cố gắng xây dựng một ứng dụng dựa trên web bằng Zend Framework.

Chắc chắn sẽ thực hiện giao diện xác thực tên người dùng / mật khẩu cơ bản dành riêng cho ứng dụng, nhưng nhận ra rằng đối với số lượng người dùng ngày càng tăng, suy nghĩ về một tên người dùng và mật khẩu khác là một yếu tố ngăn chặn. Mặc dù không chính xác là mạng xã hội, tôi biết rằng một tỷ lệ rất lớn người dùng tiềm năng của ứng dụng đã có tài khoản facebook hoặc twitter. Ứng dụng không thực sự muốn hoặc cần truy cập thông tin về tài khoản của người dùng từ các trang web đó, nó chỉ muốn cung cấp sự tiện lợi của việc không yêu cầu người dùng thiết lập thông tin đăng nhập tài khoản mới nếu họ không muốn. Từ quan điểm chức năng, điều đó có vẻ như là một con đẻ của OpenID. Nhưng có vẻ như cả facebook và twitter đều không phải là nhà cung cấp OpenID như vậy, mặc dù họ không hỗ trợ xác thực OAuth để truy cập dữ liệu người dùng của họ.

Trong tất cả các bài viết tôi đã đọc về hai người và chúng khác nhau như thế nào, cho đến khi tôi thấy quan sát của Karl Anderson ở trên, rằng "OAuth có thể được sử dụng để xác thực, có thể được coi là ủy quyền không hoạt động" mà Tôi thấy bất kỳ xác nhận rõ ràng rằng OAuth là đủ tốt cho những gì tôi muốn làm.

Trong thực tế, khi tôi đi đăng "câu trả lời" này, không phải là thành viên vào thời điểm đó, tôi đã nhìn rất lâu và chăm chỉ ở cuối trang này ở các tùy chọn để nhận dạng chính mình. Tùy chọn sử dụng thông tin đăng nhập OpenID hoặc lấy tài khoản nếu tôi không có, nhưng không có gì về twitter hoặc facebook, dường như cho thấy OAuth không phù hợp với công việc. Nhưng sau đó tôi đã mở một cửa sổ khác và tìm kiếm quy trình đăng ký chung cho stackoverflow - và lo và có một loạt các tùy chọn xác thực của bên thứ 3 bao gồm facebook và twitter. Cuối cùng, tôi quyết định sử dụng google id của mình (là OpenID) vì lý do chính xác là tôi không muốn cấp quyền truy cập stackoverflow vào danh sách bạn bè của mình và bất cứ điều gì khác mà facebook thích để chia sẻ về người dùng của nó - nhưng ít nhất là nó '

Sẽ thật tuyệt nếu ai đó có thể đăng thông tin hoặc con trỏ lên thông tin về việc hỗ trợ loại thiết lập ủy quyền phần 3 này và cách bạn đối phó với người dùng thu hồi ủy quyền hoặc mất quyền truy cập vào trang web bên thứ 3 của họ. Tôi cũng có ấn tượng rằng tên người dùng của tôi ở đây xác định một tài khoản stackoverflow duy nhất mà tôi có thể truy cập bằng xác thực cơ bản nếu tôi muốn thiết lập nó và cũng truy cập cùng tài khoản này thông qua các trình xác thực bên thứ 3 khác (ví dụ như vậy tôi sẽ được coi là đã đăng nhập vào stackoverflow nếu tôi đã đăng nhập vào bất kỳ google, facebook hoặc twitter nào ...). Vì trang web này đang làm điều đó, ai đó ở đây có lẽ có một cái nhìn sâu sắc khá tốt về chủ đề này. :-)

Xin lỗi điều này quá dài và nhiều câu hỏi hơn là một câu trả lời - nhưng nhận xét của Karl khiến nó có vẻ như là nơi thích hợp nhất để đăng giữa khối lượng chủ đề trên OAuth và OpenID. Nếu có một nơi tốt hơn cho điều này mà tôi không tìm thấy, tôi xin lỗi trước, tôi đã thử.

OpenID chứng minh bạn là ai.

OAuth cấp quyền truy cập vào các tính năng được cung cấp bởi bên ủy quyền.

Tôi hiện đang làm việc trên OAuth 2.0 và thông số kết nối OpenID. Vì vậy, đây là sự hiểu biết của tôi: Trước đó họ đã:

1. OpenID là triển khai độc quyền của Google cho phép các ứng dụng của bên thứ ba như đối với các trang web báo chí, bạn có thể đăng nhập bằng google và nhận xét về một bài viết, v.v. Vì vậy, về cơ bản, không chia sẻ mật khẩu đến trang web báo. Hãy để tôi đưa ra một định nghĩa ở đây, cách tiếp cận này trong cách tiếp cận doanh nghiệp được gọi là Liên đoàn. Trong Liên kết, Bạn có một máy chủ nơi bạn xác thực và ủy quyền (được gọi là IDP, Nhà cung cấp danh tính) và nói chung là người giữ thông tin đăng nhập của Người dùng. ứng dụng khách nơi bạn có doanh nghiệp được gọi là SP hoặc Nhà cung cấp dịch vụ. Nếu chúng ta quay lại ví dụ trang web báo tương tự thì trang web báo là SP ở đây và Google là IDP. Trong doanh nghiệp, vấn đề này đã được giải quyết trước đó bằng SAML. thời gian đó XML được sử dụng để cai trị ngành công nghiệp phần mềm. Vì vậy, từ dịch vụ web đến cấu hình, mọi thứ được sử dụng để chuyển sang XML để chúng tôi có SAML,

2. OAuth: OAuth thấy nó nổi lên như một tiêu chuẩn nhìn vào tất cả các cách tiếp cận độc quyền này và vì vậy chúng tôi đã có OAuth 1.o là tiêu chuẩn nhưng chỉ giải quyết ủy quyền. Không nhiều người chú ý nhưng nó bắt đầu nhặt. Sau đó, chúng tôi đã có OAuth 2.0 vào năm 2012. CTO, Kiến trúc sư thực sự bắt đầu chú ý khi thế giới đang chuyển sang điện toán đám mây và với các thiết bị điện toán di chuyển sang di động và các thiết bị khác như vậy. OAuth được coi là giải quyết vấn đề lớn trong đó khách hàng phần mềm có thể cung cấp Dịch vụ IDP cho một công ty và có nhiều dịch vụ từ các nhà cung cấp khác nhau như lực lượng bán hàng, SAP, v.v. Vì vậy, việc tích hợp ở đây thực sự giống như kịch bản liên kết một vấn đề lớn, sử dụng SAML rất tốn kém vì vậy hãy khám phá OAuth 2.o. Ồ, đã bỏ lỡ một điểm quan trọng mà trong thời gian này, Google đã cảm thấy rằng OAuth thực sự không '

   a. OAuth 2.o không nói rõ ràng, việc đăng ký khách hàng sẽ diễn ra như thế nào b. nó không đề cập bất cứ điều gì về sự tương tác giữa SP (Máy chủ tài nguyên) và ứng dụng khách (như Máy chủ Analytics cung cấp dữ liệu là Máy chủ tài nguyên và ứng dụng hiển thị dữ liệu đó là Máy khách)

Đã có những câu trả lời tuyệt vời được đưa ra ở đây về mặt kỹ thuật, tôi nghĩ đến việc đưa ra quan điểm tiến hóa ngắn gọn

OpenId sử dụng OAuth để xử lý xác thực.

Bằng cách tương tự, nó giống như .NET dựa trên API Windows. Bạn có thể gọi trực tiếp API Windows nhưng đối số phương thức rất rộng, phức tạp và phương thức rất lớn, bạn có thể dễ dàng mắc lỗi / lỗi / vấn đề bảo mật.

Tương tự với OpenId / OAuth. OpenId dựa vào OAuth để quản lý Xác thực nhưng xác định Mã thông báo cụ thể (Id_token), chữ ký số và các luồng cụ thể.

Tôi muốn giải quyết một khía cạnh cụ thể của câu hỏi này, như được ghi lại trong bình luận này:

OAuth: trước khi cấp quyền truy cập vào một số tính năng, phải xác thực, phải không? vậy OAuth = những gì OpenId làm + cấp quyền truy cập vào một số tính năng? - Hassan Makarov ngày 21 tháng 6 lúc 1:57

Có và không. Câu trả lời là tinh tế, vì vậy hãy chịu đựng với tôi.

Khi luồng OAuth chuyển hướng bạn đến một dịch vụ đích (nhà cung cấp OAuth, nghĩa là), đó là khả năng là bạn sẽ cần phải xác thực với dịch vụ đó trước khi một mã thông báo sẽ bàn giao lại cho các ứng dụng client / dịch vụ. Mã thông báo kết quả sau đó cho phép ứng dụng khách thực hiện các yêu cầu thay mặt cho một người dùng nhất định.

Lưu ý về tính tổng quát của câu cuối cùng đó: cụ thể, tôi đã viết "thay mặt cho một người dùng nhất định", chứ không phải "thay mặt bạn ". Đó là một lỗi phổ biến khi cho rằng "có khả năng tương tác với tài nguyên thuộc sở hữu của một người dùng nhất định" ngụ ý "bạn và chủ sở hữu của tài nguyên đích là một trong cùng một".

Đừng phạm sai lầm này.

Mặc dù đúng là bạn xác thực với nhà cung cấp OAuth (giả sử, bằng tên người dùng và mật khẩu, hoặc có thể là máy khách SSL, hoặc một số phương tiện khác), những gì khách hàng nhận được không nhất thiết phải được lấy làm bằng chứng nhận dạng. Một ví dụ sẽ là một luồng trong đó quyền truy cập vào tài nguyên của người dùng khác được ủy quyền cho bạn (và theo proxy, ứng dụng khách OAuth). Ủy quyền không ngụ ý xác thực.

Để xử lý xác thực, bạn có thể muốn xem xét OpenID Connect, về cơ bản là một lớp khác trên nền tảng được đặt bởi OAuth 2.0. Dưới đây là một trích dẫn ghi lại (theo ý kiến ​​của tôi) những điểm nổi bật nhất về OpenID Connect (từ https://oauth.net/articles/authentication/ ):

OpenID Connect là một tiêu chuẩn mở được xuất bản vào đầu năm 2014, định nghĩa một cách có thể tương tác để sử dụng OAuth 2.0 để thực hiện xác thực người dùng. Về bản chất, nó là một công thức được công bố rộng rãi cho kẹo mềm sô cô la đã được thử và kiểm tra bởi nhiều chuyên gia và nhiều chuyên gia. Thay vì xây dựng một giao thức khác nhau cho mỗi nhà cung cấp nhận dạng tiềm năng, một ứng dụng có thể nói một giao thức cho nhiều nhà cung cấp mà họ muốn làm việc cùng. Vì là một tiêu chuẩn mở, OpenID Connect có thể được thực hiện bởi bất kỳ ai mà không bị hạn chế hoặc lo ngại về sở hữu trí tuệ.

OpenID Connect được xây dựng trực tiếp trên OAuth 2.0 và trong hầu hết các trường hợp được triển khai ngay cùng với (hoặc trên cùng) một cơ sở hạ tầng OAuth. OpenID Connect cũng sử dụng bộ thông số kỹ thuật về ký hiệu và mã hóa đối tượng JSON (JOSE) để mang thông tin được ký và mã hóa ở những nơi khác nhau. Trên thực tế, việc triển khai OAuth 2.0 với các khả năng của JOSE đã là một chặng đường dài để xác định hệ thống OpenID Connect tuân thủ đầy đủ và đồng bằng giữa hai bên là tương đối nhỏ. Nhưng đồng bằng đó tạo ra sự khác biệt lớn và OpenID Connect quản lý để tránh nhiều cạm bẫy được thảo luận ở trên bằng cách thêm một số thành phần chính vào cơ sở OAuth: [...]

Tài liệu sau đó tiếp tục mô tả (trong số những thứ khác) ID mã thông báo và điểm cuối UserInfo. Cái trước cung cấp một tập hợp các khiếu nại (bạn là ai, khi mã thông báo được phát hành, v.v. và có thể là chữ ký để xác minh tính xác thực của mã thông qua khóa công khai được công bố mà không phải hỏi dịch vụ ngược dòng) và sau này cung cấp có nghĩa là yêu cầu họ / tên, email và các mẩu thông tin tương tự của người dùng, tất cả đều theo cách được tiêu chuẩn hóa (trái ngược với các tiện ích mở rộng đặc biệt cho OAuth mà mọi người đã sử dụng trước khi mọi thứ được chuẩn hóa OpenID Connect).

Cả hai giao thức được tạo ra vì những lý do khác nhau. OAuth được tạo ra để ủy quyền cho các bên thứ ba truy cập tài nguyên. OpenID được tạo để thực hiện phân cấp xác thực danh tính. Trang web này nêu sau:

OAuth là một giao thức được thiết kế để xác minh danh tính của người dùng cuối và cấp quyền cho bên thứ ba. Xác minh này dẫn đến một mã thông báo. Bên thứ ba có thể sử dụng mã thông báo này để truy cập tài nguyên thay mặt cho người dùng. Mã thông báo có một phạm vi. Phạm vi được sử dụng để xác minh xem tài nguyên có thể truy cập được đối với người dùng hay không

OpenID là một giao thức được sử dụng để xác thực phi tập trung. Xác thực là về danh tính; Thiết lập người dùng trên thực tế là người mà anh ta tuyên bố là. Phân cấp điều đó, có nghĩa là dịch vụ này không biết về sự tồn tại của bất kỳ tài nguyên hoặc ứng dụng nào cần được bảo vệ. Đó là điểm khác biệt chính giữa OAuth và OpenID.

OpenID Connect mở rộng giao thức ủy quyền OAuth 2.0 để sử dụng làm giao thức xác thực, để bạn có thể thực hiện đăng nhập một lần bằng OAuth. OpenID Connect giới thiệu khái niệm về mã thông báo ID, đây là mã thông báo bảo mật cho phép khách hàng xác minh danh tính của người dùng

OAuth 2.0 là một giao thức bảo mật. Đó là NEITHER một xác thực B giao thức ủy quyền.

Xác thực bằng định nghĩa hai câu trả lời.

1. Ai là người dùng?
2. Là người dùng hiện đang có mặt trên hệ thống?

OAuth 2.0 có các loại cấp sau

• client_credentials: Khi một ứng dụng cần tương tác với ứng dụng khác và sửa đổi dữ liệu của nhiều người dùng.
• ủy quyền_code: Người dùng ủy quyền cho máy chủ ủy quyền phát hành access_token mà khách hàng có thể sử dụng để truy cập tài nguyên được bảo vệ
• refresh_token: Khi access_token hết hạn, mã thông báo làm mới có thể được tận dụng để có được access_token mới
• mật khẩu: Người dùng cung cấp thông tin đăng nhập của họ cho khách hàng gọi máy chủ Ủy quyền và nhận access_token

Cả 4 đều có một điểm chung, access_token, một tạo phẩm có thể được sử dụng để truy cập tài nguyên được bảo vệ.

Access_token không cung cấp câu trả lời cho 2 câu hỏi mà giao thức "Xác thực" phải trả lời.

Một ví dụ để giải thích Oauth 2.0 (tín dụng: OAuth 2 in Action, Manning ấn phẩm)

Hãy nói về sô cô la. Chúng ta có thể tạo ra nhiều loại bánh kẹo từ sô cô la, bao gồm kẹo mềm, kem và bánh. Nhưng, không ai trong số này có thể được đánh đồng với sô cô la vì nhiều thành phần khác như kem và bánh mì là cần thiết để làm bánh kẹo, mặc dù sô cô la nghe giống như thành phần chính. Tương tự, OAuth 2.0 là sô cô la và cookie, cơ sở hạ tầng TLS, Nhà cung cấp nhận dạng là các thành phần khác được yêu cầu để cung cấp chức năng "Xác thực".

Nếu bạn muốn Xác thực, bạn có thể sử dụng OpenID Connect, cung cấp "id_token", ngoài access_token, trả lời các câu hỏi mà mọi giao thức xác thực phải trả lời.

OAuth xây dựng xác thực trên ủy quyền: Người dùng ủy quyền truy cập vào danh tính của họ cho ứng dụng, sau đó, trở thành người tiêu dùng API nhận dạng, từ đó tìm ra ai đã ủy quyền cho khách hàng ở vị trí đầu tiên http://oauth.net/ bài viết / xác thực /