題:
為什麼使用OpenID Connect代替普通的OAuth2?
rdmueller
2013-06-21 11:18:15 UTC
view on stackexchange narkive permalink

我剛剛開始使用 OAuth 2.0作為對用戶進行身份驗證的方式。效果很好-我只是使用每個提供商的身份/配置文件API來獲取用戶的經過驗證的電子郵件地址。

現在,我了解了 OpenID Connect,並且有點困惑。

OpenID Connect和通過OAuth2使用身份API有什麼區別?僅僅是我有一個標準的配置文件API,這樣我就不必擔心我得到“電子郵件” 還是“電子郵件” JSON了嗎?

還是它還有更多,這使OpenID Connect方法比我的第一種方法更安全?

好吧,我不了解“ OpenID Connect”,我將其理解為“ OpenID” +“ Connect”。我確定您已經檢查了以下內容:http://softwareforallseasons.blogspot.fr/2011/10/oauth-vs-openid-connect.html +我建議您編輯問題,以使其讀取OAuth 2.0而不是OAuth。
@Aki:是的,我看過博客文章,但什麼也做不了。
-1
“我只是使用每個提供商的身份/配置文件API **以獲取用戶的經過驗證的電子郵件地址**。”這意味著您需要限制允許的提供者的集合。任意提供者不保證驗證。或者,您可以拒絕與提供商域不匹配的電子郵件地址。
作為[oauth.net上的文章:OAuth 2.0不是身份驗證協議](http://oauth.net/articles/authentication/)。它實際上是授權框架。他們建議您使用OpenID Connect(基於OAuth 2.0),以進行身份驗證。
我發現這個YouTube視頻演示非常有幫助:Nate Barbettini撰寫的[* OAuth 2.0和OpenID Connect(以純英語顯示)*](https://youtu.be/996OiexHze0)。
六 答案:
flup
2013-12-17 09:33:57 UTC
view on stackexchange narkive permalink

OpenID connect將為您提供訪問令牌和 id令牌。 id令牌是 JWT,其中包含有關已認證用戶的信息。它由身份提供者簽名,無需訪問身份提供者即可讀取和驗證。

此外,OpenID connect標準化了oauth2可以選擇的很多方面。例如作用域,端點發現和客戶端動態註冊。

這樣可以更輕鬆地編寫代碼,使用戶可以在多個身份提供者之間進行選擇。

您確定您的語句“ OpenID connect將為您提供訪問令牌和ID令牌”。是正確的?我認為一個應用程序可以具有id_token並與其他應用程序共享,然後從該應用程序獲取訪問令牌。OIDC依靠OAuth2協議,但不一定要兩者兼得。雖然,它可能在大多數時間發生。
“ OpenID connect將為您提供訪問令牌和id令牌。”>>在大多數情況下,這是正確的,而且通常是這樣處理的。您發出一個請求,該請求由“ token id_token”作為responseTypes和“ openid”作為範圍組成,這將同時返回訪問令牌和id令牌。ID令牌用於客戶端,而訪問令牌對於客戶端則是不透明的,並且應在請求中傳遞給資源服務器以進行保護,例如API或其他後端。
“我認為一個應用程序可以具有一個id_token並與其他應用程序共享,然後從該應用程序獲取訪問令牌。”>>如果您要這樣做,則不要將ID令牌交換為訪問令牌。兩者都是授權服務器/ IdP的問題,而不是另一個應用程序或資源服務器的問題(儘管授權服務器和資源服務器有時可以相同)。
Nereis
2014-01-21 20:07:21 UTC
view on stackexchange narkive permalink

OAuth僅提供並且僅應使用訪問令牌提供授權。 OpenID connect建立在OAuth 2上,以提供用戶身份驗證信息。但是,它不會為您提供比OAuth更健壯的實現(因為它使用OAuth並添加了與OpenID提供程序的一些額外交互)。

OpenID Connect 1.0是位於頂部的簡單身份層OAuth 2.0 [RFC6749]協議。它使客戶端能夠基於授權服務器執行的身份驗證來驗證最終用戶的身份,並以可互操作且類似於REST的方式獲取有關最終用戶的基本配置文件信息。 OpenID Connect Core 1.0-草稿17

OpenID connect為您提供了一種獲取用戶身份的“標準”方式。如果您使用OAuth和API,則應針對每種資源調整您的請求,這些資源可能並不總是提供相同的信息,或者隨時間而變化。從概念上講,您可以使用OAuth來使用API​​,而不是對用戶進行身份驗證。

作為背景,OAuth 2.0授權框架[RFC6749]和OAuth 2.0承載令牌使用情況[RFC6750]規範為第三方應用程序提供了一個通用框架,以獲取和使用對HTTP資源的有限訪問。它們定義了獲取和使用訪問令牌訪問資源的機制,但是沒有定義提供身份信息的標準方法。值得注意的是,如果不對OAuth 2.0進行概要分析,則無法提供有關最終用戶身份驗證的信息。 OpenID Connect Core 1.0-草稿17

請注意,OpenID connect為 id_token 提供了有關用戶的一些信息。但是,如果您需要全部信息,則仍然需要 access_token 來請求OpenID提供程序獲取userinfo(這是我第一次看到它時感到困惑)。這表明從API或OpenID提供程序請求用戶信息使用的方法幾乎相同。參見 5.3.1。草案中的userinfo請求。

這個答案是絕對正確的。只是想指出一個小問題:“但是,如果您需要全部信息,則仍然需要access_token來請求OpenID提供程序獲取userinfo” >>不一定是這種情況,具體取決於授權服務器/ broken used:還可能已經在ID令牌= JWT令牌或甚至其他任何使用自定義聲明的信息中包含了完整的個人資料;例如https://auth0.com/docs/tokens/id-token#add-custom-claims。然後,您不再需要執行/ userinfo請求。
Tim
2015-02-26 10:12:29 UTC
view on stackexchange narkive permalink

OAuth是一種授權協議,提供了一種授權訪問受保護資源的方法。授權過程的副產品是對用戶進行身份驗證。

從技術上講,OAuth不必向您提供有關該用戶的任何信息。它提供的驗證是用戶已授予應用程序訪問某些數據的權限。這受授權授予的範圍支配。

OpenID Connect提供了一種方法,使應用程序可以檢索有關已認證用戶的信息。最重要的是,它提供了一定程度的保證,即該信息是有效的(就授權服務器而言)。

過去,通過授予允許訪問用戶身份信息的範圍的OAuth,可以實現OAuth的聯合。 OpenID Connect對該範圍進行了標準化。

外部提供商仍然需要支持開放ID嗎?您不能僅僅在現有的oauth 2提供程序之上實現開放ID作為這些外部服務的客戶端。
Mike Schwartz
2016-06-24 00:02:41 UTC
view on stackexchange narkive permalink

OpenID Connect是OAuth2的配置文件...定義了一種體系結構,該體系結構使人可以授權身份提供者向客戶端(網站/移動應用程序)發布某些用戶聲明。

OAuth2提供了資源所有者密碼憑據授予,被IAM專家正確地稱為“惡魔”。

OpenID Connect API的常見模式包括三個步驟:
1)獲取代碼
2)獲取令牌,如 access_token refresh_token id_token
3)獲取包含諸如用戶名,電子郵件等聲明的用戶信息。與其他許多細節一樣,在OpenID Connect範圍內定義了ID_token(即JWT)的架構。

使用OpenID Connect的另一個原因是,存在用於移動軟件(至少是IOS和Android)的集中式身份驗證的安全解決方案。 Google定義的當前最佳做法是使用新的安全功能,以阻止移動應用程序在Web視圖中查看Cookie或憑據。 Google發布了AppAuth IOS和Android庫,因為它們確實不希望您洩漏Google憑據!在撰寫本文時,有多個支持Google OpenID Connect AppAuth軟件的OpenID提供程序(又名IDP ...),包括:Google,OKTA,Ping和我的產品Gluu。

請參閱此外:

  • 用於本機應用程序的OAuth 2.0 draft-wdenniss-oauth-native-apps-02
  • 用於iOS的AppAuth
  • 用於Android的AppAuth
Alex White
2015-12-24 17:32:39 UTC
view on stackexchange narkive permalink

不建議將OAuth用作身份驗證方法,而是將其明確設計為委託授權方法。

Facebook曾經使用OAuth作為身份驗證方法,但是進取心的人發現瞭如何竊取來自Facebook的> access_token -完整的博客條目

OpenID Connect使通過這種機制竊取訪問令牌更加困難。

感謝您的鏈接-必須檢查有什麼區別...
好。閱讀博客條目。對我來說,這聽起來像是Facebook實施了一些安全漏洞,但並未破壞OAuth ...因此,當我使用OAuth方案(必須在服務器之間驗證訪問令牌)時,博客中描述的問題就無法解決。尚未露面...我仍然堅信OAuth(以正確的方式實施)非常好...
這個更好地解釋了為什麼使用OAuth作為身份驗證機制會造成安全漏洞:http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
Utsav
2013-10-11 18:52:08 UTC
view on stackexchange narkive permalink

Open id connect建立在OAuth的頂部,因此更加健壯。 OAuth是僅用於授權的協議,開放ID連接與OAuth非常相似,但它也結合了OAuth的功能。您可以使用此協議開始RP和IP之間的通信,它們是OAuth協議中的各種漏洞,因此最好使用Open Id Connect。

知道這個答案為什麼會被拒絕會很有趣...
您指的是哪些漏洞(誠實的好奇心)。我正與OP一樣在苦苦掙扎。儘管我熟悉使用簡單Bearer令牌可能進行的會話劫持和MiM重放攻擊,但oAuth2(基於Openid Connect的基礎)已經在進行身份驗證。這些是您所指的漏洞嗎?
7年後... OIDC肯定不會解決這些漏洞嗎?畢竟,您仍然擁有訪問令牌,並且它們仍在執行OIDC的OAuth2中應該執行的相同操作?在我看來,如果您在OAuth2的實現中存在缺陷,那麼將OIDC放在頂層將無法解決這些問題。


該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...