我剛剛開始使用 OAuth 2.0作為對用戶進行身份驗證的方式。效果很好-我只是使用每個提供商的身份/配置文件API來獲取用戶的經過驗證的電子郵件地址。
現在,我了解了 OpenID Connect,並且有點困惑。
OpenID Connect和通過OAuth2使用身份API有什麼區別?僅僅是我有一個標準的配置文件API,這樣我就不必擔心我得到“電子郵件”
還是“電子郵件”
JSON了嗎?
還是它還有更多,這使OpenID Connect方法比我的第一種方法更安全?
我剛剛開始使用 OAuth 2.0作為對用戶進行身份驗證的方式。效果很好-我只是使用每個提供商的身份/配置文件API來獲取用戶的經過驗證的電子郵件地址。
現在,我了解了 OpenID Connect,並且有點困惑。
OpenID Connect和通過OAuth2使用身份API有什麼區別?僅僅是我有一個標準的配置文件API,這樣我就不必擔心我得到“電子郵件”
還是“電子郵件”
JSON了嗎?
還是它還有更多,這使OpenID Connect方法比我的第一種方法更安全?
OpenID connect將為您提供訪問令牌和 id令牌。 id令牌是 JWT,其中包含有關已認證用戶的信息。它由身份提供者簽名,無需訪問身份提供者即可讀取和驗證。
此外,OpenID connect標準化了oauth2可以選擇的很多方面。例如作用域,端點發現和客戶端動態註冊。
這樣可以更輕鬆地編寫代碼,使用戶可以在多個身份提供者之間進行選擇。
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請求。
OAuth是一種授權協議,提供了一種授權訪問受保護資源的方法。授權過程的副產品是對用戶進行身份驗證。
從技術上講,OAuth不必向您提供有關該用戶的任何信息。它提供的驗證是用戶已授予應用程序訪問某些數據的權限。這受授權授予的範圍支配。
OpenID Connect提供了一種方法,使應用程序可以檢索有關已認證用戶的信息。最重要的是,它提供了一定程度的保證,即該信息是有效的(就授權服務器而言)。
過去,通過授予允許訪問用戶身份信息的範圍的OAuth,可以實現OAuth的聯合。 OpenID Connect對該範圍進行了標準化。
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用作身份驗證方法,而是將其明確設計為委託授權方法。
Facebook曾經使用OAuth作為身份驗證方法,但是進取心的人發現瞭如何竊取來自Facebook的> access_token
-完整的博客條目
OpenID Connect使通過這種機制竊取訪問令牌更加困難。
Open id connect建立在OAuth的頂部,因此更加健壯。 OAuth是僅用於授權的協議,開放ID連接與OAuth非常相似,但它也結合了OAuth的功能。您可以使用此協議開始RP和IP之間的通信,它們是OAuth協議中的各種漏洞,因此最好使用Open Id Connect。