第八節：理解認證和授權、Oauth2.0及四種授權模式、OpenId Connect

一. 認證和授權

1. 身份驗證

　　指當客戶端訪問服務端資源時，驗證客戶端是否合法的一種機制. eg: Core MVC中通過 app.UseAuthentication() 開啟。最常見的是通過 用戶名和密碼，來驗證您的身份。

2. 授權

　　指當客戶端經過身份認證后，能夠有限的訪問服務端資源的一種機制. eg: Core MVC中通過 app.UseAuthorization() 開啟。授權發生在系統成功驗證您的身份后，最終會授予您訪問資源（如信息，文件，數據庫，資金，位置，幾乎任何內容）的完全權限。簡單來說，授權決定了您訪問系統的能力以及達到的程度。驗證成功后，系統驗證您的身份后，即可授權您訪問系統資源。

二者比較：

舉一個容易理解的例子：

　　用戶ypf要去博客網站發帖子，要通過輸入賬號：admin 密碼：123456，進行登錄，博客系統后台驗證 admin 123456的賬號和密碼的合法性， 驗證賬號和密碼合法后，然后要賦予該賬號權限，比如：可以發博客，查看博客，但不能刪除博客，這個過程就是“身份認證”； 然后該用戶去刪除博客，系統要判斷該用戶是否有這個權限，這就是“授權”。

3. 常見的身份認證和授權方式

(1). Base認證

　　Base64編碼認證,Base64是可編譯的.

(2). Digest認證

　　MD5加密

(3). Bearer認證

　　就是基於token認證，將用戶信息等其他信息轉換成為token，然后以token進行認證，token認證是一種無狀態的認證方式，能夠無限擴展，特別適合做單點登錄。基於Token的主流方式有兩種：A. OAuth 2.0  ，B. JWT身份認證 

Token分兩種類型：

　①. 引用類型的token(OAuth 2.0),不包含任何用戶信息

　②. 自包含token(jwt)，包含用戶信息,但不要在里面存儲一些敏感的信息哦

　　在實際微服務項目中,為了保證系統統一登錄(SSO),使用OpenID協議標准來規范身份認證功能,同時使用OAuth 2.0協議標准來規范權限訪問,為了將身份認證和授權結合起來，誕生了OpenID Connect協議標准。

OpenID Connect = OpenID + OAuth 2.0， 而IDS4恰恰是基於OpenID Connect協議標准的身份認證和授權程序。

 

二. Oauth2.0簡介

1. 生活中的例子

(1). 背景

　　每個小區都有門禁系統，小區業主進入的時候可以：【刷卡】【人臉識別】【輸入密碼】等方式，現在很多年輕人喜歡點外賣，因為門禁的存在，外賣騎手是不能進入小區的，這個時候業主還不想出去拿，但是如果告訴騎手密碼，以后騎手都能進入了小區，很不安全，除非業主主動改密碼。

　　這個時候我們迫切的需要改進一下門禁系統，可以給外賣騎手進行臨時授權。

(2). 解決方案

　A. 騎手在門禁系統上，呼叫業主，報備基本信息，供業主確認。

　B. 業主在App上授權騎手的授權申請，點擊同意，會產生一個令牌，即一串數字，把這個數字告訴騎手。

　C. 騎手在門禁系統中輸入這個令牌，即可進入小區。

PS. 令牌是有有效期的，而且業主可以隨時取消。

分析：這里小區相當於【資源服務器】，外賣騎手相當於【第三方應用】，【我】授權【外賣騎手】一個令牌，【外賣騎手】通過令牌可以進入【小區】。

2. 互聯網例子

經典例子：某博客網站支持用戶使用QQ登錄。

　　用戶：也就是資源持有者，也就是我，比如：ypf

　　第三方應用：博客網站。

　　服務器提供商：QQ

QQ登錄的時候，該【博客網站】希望得到關於【我】的一些【QQ信息(比如：昵稱和頭像)】，這個時候【我】不能直接把用戶名和密碼給【第三方應用(博客網站)】，這個時候我要授權【博客網站】到【QQ認證服務器】拿令牌，拿到令牌以后，向【QQ資源服務器】申請獲取昵稱和頭像等信息。

PS：

(1). QQ認證服務器 和 QQ資源服務器 可能是同一台服務器，也可能是不同服務器。

(2). 用戶在授權第三方應用拿信息的時候通常是需要自己輸入賬號和密碼的，這個不是給第三方應用的。

 

3. Oauth 2.0的相關概念

(1). 含義

　　OAuth（Open Authorization，開放授權）是為用戶資源的授權定義了一個安全、開放及簡單的標准，“第三方應用"無需知道用戶的賬號及密碼，就可獲取到用戶的授權信息，OAuth2.0是OAuth協議的延續版本，但不向后兼容OAuth 1.0即完全廢止了OAuth1.0。

(2). 專用名詞：

　A.Third-party application：第三方應用程序，本文中又稱"客戶端"（client），即上面的【博客網站】。

　B.HTTP service：HTTP服務提供商，本文中簡稱"服務提供商"，即上面的 【QQ服務】。

　C.Resource Owner：資源所有者，本文中又稱"用戶"（user）。

　D.User Agent：用戶代理，比如：瀏覽器。

　E. Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器，即上面的【QQ認證服務器】。

　F. Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，可以是同一台服務器，也可以是不同的服務器，即上面的【QQ資源服務器】。

 

4. Oauth 2.0的思路和運行流程

(1). 思路　　

　　OAuth2.0 在【第三方應用】與【服務提供商】之間，設置了一個授權層（authorization layer）。【第三方應用】不能直接登錄【服務提供商】，只能登錄授權層，以此將【用戶】與【第三方應用】區分開來。【第三方應用】登錄授權層所用的令牌（token），與【用戶】的密碼不同。【用戶】可以在登錄的時候，指定授權層令牌的權限范圍和有效期。

　【第三方應用】登錄授權層以后，【服務提供商】根據令牌的權限范圍和有效期，向【第三方應用】開放用戶儲存的資料。

(2). 運行流程

 

步驟：

（A）用戶打開【第三方應用】以后，【第三方應用】要求用戶給予授權。

（B）用戶同意給予【第三方應用】授權。

（C）【第三方應用】使用上一步獲得的授權，向認證服務器申請令牌。

（D）認證服務器對【第三方應用】進行認證以后，確認無誤，同意發放令牌。

（E）【第三方應用】使用令牌，向資源服務器申請獲取資源。

（F）資源服務器確認令牌無誤，同意向【第三方應用】開放資源。

PS. 上面六個步驟之中，B是關鍵，即用戶怎樣才能給於客戶端授權。有了這個授權以后，客戶端就可以獲取令牌，進而憑令牌獲取資源。

 

5. Oauth2.0的四種授權模式

　(1). 客戶端模式

　(2). 密碼模式

　(3). 簡化模式（也叫：隱式模式）

　(4). 授權碼模式 

其中，其中授權碼模式是步驟流程最為詳細嚴謹的一種模式，而網絡上大部分的第三方Oauth2實現都是基於授權碼模式的。

 

三. Oauth2.0的四種授權模式

 這里也可以放在后面結合IDS4的每個章節代碼來詳細介紹。

 

 

四. OpenId Connect簡介

1. 簡介　

　　OpenID Connect是基於Oauth 2.0規范族的可互操作的身份驗證協議。它使用簡單的REST / JSON消息流來實現，和之前任何一種身份認證協議相比，開發者可以輕松集成。OpenID Connect允許開發者驗證跨網站和應用的用戶，而無需擁有和管理密碼文件。OpenID Connect允許所有類型的客戶，包括基於瀏覽器的JavaScript和本機移動應用程序，啟動登錄流動和接收可驗證斷言對登錄用戶的身份。

2. 歷史　

　　OpenID Connect是OpenID的第三代技術。首先是原始的OpenID，它不是商業應用，但讓行業領導者思考什么是可能的。OpenID 2.0設計更為完善，提供良好的安全性保證。然而，其自身存在一些設計上的局限性，最致命的是其中依賴方必須是網頁，但不能是本機應用程序；此外它還要依賴XML，這些都會導致一些應用問題。

　　OpenID Connect的目標是讓更多的開發者使用，並擴大其使用范圍。幸運的是，這個目標並不遙遠，現在有很好的商業和開源庫來幫助實現身份驗證機制。

3. OIDC基礎

　　OIDC是一種安全機制，用於應用連接到身份認證服務器（Identity Service）獲取用戶信息，並將這些信息以安全可靠的方法返回給應用。在最初，因為OpenID1、OpenID2經常和OAuth協議（一種授權協議）一起提及，所以二者經常被搞混，這里澄清解釋一下：

(1). OpenID: 是Authentication，即認證，對用戶的身份進行認證，判斷其身份是否有效，也就是讓網站知道“你是你所聲稱的那個用戶.

(2). OAuth:是Authorization，即授權，在已知用戶身份合法的情況下，經用戶授權來允許某些操作，也就是讓網站知道“你能被允許做那些事情”。 由此可知，授權要在認證之后進行，只有確定用戶身份只有才能授權。

　　OpenID Connect是“認證”和“授權”的結合，因為其基於OAuth協議，所以OpenID-Connect協議中也包含了client_id、client_secret還有redirect_uri等字段標識。這些信息被保存在“身份認證服務器”，以確保特定的客戶端收到的信息只來自於合法的應用平台。這樣做是目的是為了防止client_id泄露而造成的惡意網站發起的OIDC流程。

(OpenID+ OAuth 2.0 = OpenID Connect)

4. OIDC流程

　　Oauth2.0 提供了Access Token來解決授權第三方客戶端訪問受保護資源的問題；相似的，OIDC在這個基礎上提供了ID Token來解決第三方客戶端標識用戶身份認證的問題。OIDC的核心在於在OAuth2.0 的授權流程中，一並提供用戶的身份認證信息（ID-Token）給到第三方客戶端，ID-Token使用JWT格式來包裝，得益於JWT的自包含性，緊湊性以及防篡改機制，使得ID-Token可以安全的傳遞給第三方客戶端程序並且容易被驗證。應有服務器，在驗證ID-Token正確只有，使用Access-Token向UserInfo的接口換取用戶的更多的信息。

　　有上述可知，OIDC是遵循OAuth協議流程，在申請Access-Token的同時，也返回了ID-Token來驗證用戶身份。

5. 三種流程

(1). 如果是JS應用，其所有的代碼都會被加載到瀏覽器而暴露出來，沒有后端可以保證client_secret的安全性，則需要是使用默認模式流程(Implicit Flow)。

(2). 如果是傳統的客戶端應用，后端代碼和用戶是隔離的，能保證client_secret的不被泄露，就可以使用授權碼模式流程（Authentication Flow）。

(3). 此外還有混合模式流程(Hybrid Flow)，簡而言之就是以上二者的融合。

 (PS: 未完，待補充)

 

 

 

　　參考文章：http://www.ruanyifeng.com/blog/2019/04/oauth_design.html     

　　　　　　　https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

                 

 

 

 

!

• 作       者 : Yaopengfei(姚鵬飛)
• 博客地址 : http://www.cnblogs.com/yaopengfei/
• 聲     明1 : 如有錯誤，歡迎討論，請勿謾罵^_^。
• 聲     明2 : 原創博客請在轉載時保留原文鏈接或在文章開頭加上本人博客地址，否則保留追究法律責任的權利。