identity4 系列————開篇概念
- 2022 年 8 月 13 日
- 筆記
- .net core(web)
前言
identity4 其實是openid connection, 那麼我們還聽說過openid 還有 oauth 2.0
那麼下面就介紹一下Oath 2.0和openid 還有 openid connection
正文
網上說openid 是身份認證, 然後oauth2.0 是授權。
真的是這樣嗎?
直接看官網。
OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.
You may choose to associate information with your OpenID that can be shared with the websites you visit, such as a name or email address. With OpenID, you control how much of that information is shared with the websites you visit.
With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit. Other than your provider, no website ever sees your password, so you don』t need to worry about an unscrupulous or insecure website compromising your identity.
OpenID is rapidly gaining adoption on the web, with over one billion OpenID enabled user accounts and over 50,000 websites accepting OpenID for logins. Several large organizations either issue or accept OpenIDs, including Google, Facebook, Yahoo!, Microsoft, AOL, MySpace, Sears, Universal Music Group, France Telecom, Novell, Sun, Telecom Italia, and many more.
這上面介紹了,openid 作用是做到去中心化登錄,實現資訊共享。
You may choose to associate information with your OpenID that can be shared with the websites you visit, such as a name or email address. With OpenID, you control how much of that information is shared with the websites you visit.
上面提及到了,你能選擇自己的哪些資訊被共享給你要登錄的網站, 也就是授權給網站可以去idp(identity provider)獲取哪些資訊。
openid 要做的是實現去中心化登陸,實現資訊共享,資訊共享才是最終目的。
那麼有 openid 感覺已經可以搞定了,已經實現我們的資訊共享的目的了,要啥oauth(open oauthorization)。
openid 的確目的是為了去中心化登錄,讓用戶選擇自己的資訊進行授權給對應的網站,但是關鍵是如何授權呢? openid 可沒有指定什麼授權。
來看下oauth 提供的方案,不僅提供了網站還提供給了桌面等授權:
OAuth 2.0 is the industry-standard protocol for authorization.
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
This specification and its extensions are being developed within the IETF OAuth Working Group.
這裡說明了oauth2.0 專註於,對網站、桌面端提供授權。
很多人這裡就開始聯想了,認為oauth 2.0 是對openid的補充。
其實oauth 2.0 跟 openid 沒有任何關係。 openid 是實現去中心化登錄實現資訊共享, oauth 2.0 是為了實現對第三方應用授權。
oauth 2.0 中就沒提到登錄這回事, 比如訪問我的某個url,我就會給你一個access_token,你通過我的這個access_token 就可以訪問我的計算功能的api,我就不需要你登錄。
同樣openid,也不一定要使用你oauth 2.0去授權, 未來還會出現其他方案的嘛。
所以也不要說什麼openid 管什麼認證,oauth 2.0 管什麼授權,搞得他們好像有啥關係一樣。openid 是一套去中心化身份認證,為了實現資訊共享。
有些人提及左邊是openid 認證,右邊是oauth 授權,我個人認為這是不正確的。這個就是實現openid,授權用的是oauth 2.0 方案。
那麼openid connection 是什麼呢?
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server,
as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.
這裡可以看到openid connection 結合了openid這種去中心化身份驗證的場景加上了oauth 2.0的授權方式,是他們的結合體。
裡面也說了openid2.0 和 openidconnection的區別:
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
好了,現在知道他們的區別了,關於auth2.0 還是有必要看一下的,比較要學的是identity4,然後identity4基於openid connection,openid connection 授權又是在oauth 2.0 的基礎上。
看阮一峰的網址吧,太清晰了,沒有從新整理的必要性://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
這裡新手值得注意這裡的授權和我們的獲取token 訪問api授權不一樣。
怎麼不一樣呢? 這裡解釋一下。
比如我們以前的是去獲取到了token,然後呢,通過角色或者什麼策略去訪問這個api,判斷是否是這個角色可以訪問。
這種授權可以理解為內部授權。
OAuth協議一般用於用戶決定是否把自己在某個服務商上面的資源(比如:用戶基本資料、照片、影片等)授權給第三方應用訪問。
可以看到這裡oauth 協議呢,指的是第三方授權,這個很重要,而不是說在你們內部獲取一個token,然後這個token 驗證用戶是否可以訪問這個介面。
舉個例子,簡書通過qq登錄可以獲取到qq的頭像,名字等。如果你授權後, 簡書就可以拿到你qq的頭像和名字,否則就拿不到。
我們內部的授權是針對的是內部的資源(api等),第三方授權針對的是開放的資源,比如說在伺服器的名字頭像等。
還是以簡書這個例子來說。
比如簡書上跳轉到qq,然後可以勾選哪些資訊授權給簡書(有些是不能選的,因為簡書要求一定要獲取,不獲取就不給你登錄),用戶輸入賬戶密碼後,就跳轉到了簡書。
想下面這種灰色的就是不能去掉的。
當我們登錄完後跳轉到簡書後,發現簡書有了我的qq頭像了。
我們來抓包看下:
當qq 登錄完成之後:
這裡302跳轉會簡書。
請求了簡書的這個callback。
拿到這個code 後,獲取access_token,然後access_token 可以獲取到用戶的openid,通過openid 和 access_token獲取到用戶的頭像和名字。
這樣看可能還是會迷糊。
直接現場演示如何接入qq。
qq 第三方登陸提供了兩種模式:
一種是service-side 模式, 這種對應的是authorization code 模式。
另外一種是client-side 模式,implisit grant type 模式。
別人已經寫了,所以這裡就不寫了。
//www.php.cn/js/js-Server-side.html
implicit grant type 模式可能別人有誤解哈,有些人直接翻譯過來是簡易模式, 認為這種方式不安全,感覺沒人會使用。
其實不是的,這種模式用的還挺多的。
下面是不同場景。
舉個例子,比如隔壁前端部門要做個工具,他們純粹調用你們部門的api,那麼直接implicit grant type 模式就好了。
他們不需要伺服器保存什麼數據,只需要授權api 訪問就好了。這樣安全達到了,且又讓項目複雜度變得更加簡單。
之所以有幾種模式,是因為場景不同, 需要的安全程度不一樣。
結
identity 章節開始了,上面只是個人整理,主要是介紹了一下概念,主要介紹openid是中心化登錄的一套資訊共享方案, 同樣oauth 2.0 跟openid 沒有任何關係,準備來說oauth 2.0 是一個對第三方授權的方案,所以整理一下概念,如有錯誤望請指出。