預備知識
可能需要看一點點預備知識
OAuth 2.0 不完全簡介: https://www.cnblogs.com/cgzl/p/9221488.html
OpenID Connect 不完全簡介: https://www.cnblogs.com/cgzl/p/9231219.html
回顧一下OAuth 2.0 和 OpenID Connect
OAuth 2.0 vs OpenID Connect 角色對應
客戶端/依賴方的型別
OAuth 2.0 vs OpenID Connect 端點定義
OAuth 2.0 vs OpenID Connect 主要授權方式/流程對比
實際上OpenID Connect 是完全相容OAuth 2.0的.
OpenID Connect 三種流程
本系列文章主要關注OpenID Connect的三個流程
三種Flow的Response Type的值
Hybrid Flow
本文只介紹Hybrid Flow. 而根據其response_type的不同, 它又分為三種情況:
- response_type=code id_token
- response_type=code token
- response_type=code id_token token
注意:為了表明是OpenID Connect協議的請求, scope引數裡必須包含openid.
1. response_type=code id_token:
當reponse_type為這種型別的時候, 授權碼和ID Token從授權端點發行返回, 然後Access Token 和 ID Token會從Token端點發行返回:
2. response_type=code token:
當reponse_type為這種型別的時候, 授權碼和Access Token從授權端點發行返回, 然後Access Token 和 ID Token會從Token端點發行返回:
3. response_type=code id_token token:
當reponse_type為這種型別的時候, 授權碼和Access Token和ID Token從授權端點發行返回, 然後Access Token 和 ID Token會從Token端點發行返回:
搭建Identity Server 4專案
Identity Server 4 是OpenID Connect和OAuth 2.0的框架, 它主要是為ASP.NET Core準備的. 它得到了OpenID基金會的官方認證. 它也是開源的, https://github.com/IdentityServer/IdentityServer4.
首先需要一個現成的API專案, 其實本文根本沒用到: https://github.com/solenovex/Identity-Server-4-Tutorial-Code, 在該連線的00目錄裡.
在此之上, 我再繼續搭建Identity Server 4.
在該解決方案裡建立一個ASP.NET Core Web Application:
由於Identity Provider 通常不是為某一個客戶端專案或API資源所準備的, 所以該專案的名稱通常獨立於其它專案的名稱. 在這裡我教它Dave.IdentityProvider.
然後選擇Empty模板, 並使用ASP.NET Core 2.1:
點選OK, 專案建立好之後, 為該專案安裝Identity Server 4, 我通過Nuget:
隨後是配置Identity Server 4.
開啟Dave.IdentityProvider的Startup.cs, 在ConfigureServices裡面呼叫 services.AddIdentityServer()來把Identity Server註冊到ASP.NET Core的容器裡面; 隨後我呼叫了services.AddDeveloperSigningCredentials()方法, 它會建立一個用於對token簽名的臨時金鑰材料(但是在生產環境中應該使用可持久的金鑰材料):
然後需要新增資源和客戶端, 按照官方文件的做法, 我新增一個Config類:
這裡我首先新增了一個GetUsers()方法, 裡面有兩個終端使用者.
注意TestUser的SubjectId屬性的值, 在這個Identity Provider裡面必須是唯一的.
每個使用者下面還有個Claims屬性, claims裡面都是代表使用者的一些資訊.
但是如何讓這些claims通過Identity Token返回來呢?
Claims 與 Scope 是緊密相連的, 是多對一的. 下面我建立一個方法來返回Scope:
在這裡IdentityResource對映於那些關於使用者資訊的scope, 後邊還要介紹ApiResource, 它對映於API資源的scopes. IdentityResource就是一些關於使用者身份的資料, 例如user ID, name, email等等. 每個Identity Resource都有一個唯一的名稱, 你可以為它賦一些claims, 然後這些claims就會包含在該使用者的Identity Token裡面(這只是一種情況), 客戶端需要使用scope引數來請求訪問某個identity resource.
OpenID Connect協議裡的scopes可以理解為一組預定義的claims的簡稱.
OpenID Connect預定義了幾組標準的scopes 或者叫 identity resources:
- openid, 這個是必須的. 它會為使用者提供一個唯一的ID, 也叫做subject id. 它的出現也就是告訴授權伺服器客戶端發出的是OpenID Connect 請求. 它同時也要求返回ID Token. 如果 response_type 含有 "token" (指的是Access Token), 那麼ID Token在授權的響應裡和Access Token一同返回; 如果response_type 包含 "code" (指授權碼), 那麼ID Token會作為Token端點響應的一部分返回.
- profile, 這個是可選的. 這個scope請求訪問的是終端使用者的個人資料, 但是不包括email, address和phone, 它包括的claims有: name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, 和 updated_at.
- email, 這個是可選的. 它包括 email 和 email_verified 兩個claims.
- address, 這個是可選的. 它只有address 一個claim.
- phone, 這個是可選的. 它包括 phone_number 和 phone_number_verified 兩個claims.
其中通過profile, email, address, phone這四個scope請求的claims, 如果請求的response_type的值包含"token"(指的是access token), 那麼這些claims是從使用者資訊端點(UserInfo Endpoint)返回的. 而如果response_type不包含Access Token, 那麼這些claims是在ID Token裡面返回.
Identity Server 4的IdentityResources類裡面包含著上述這5個預定義的scopes.
所以上面方法裡TestUser的given_name和family_name將會在ID_Token裡面返回.
最後, 還需要定義客戶端:
暫時它還只是返回一個空的集合.
這個Config類先到這, 現在還需要再修改一下Startup裡的ConfigureServices方法, 把上面Config裡面的配置都加進去:
然後修改Startup裡的Configure方法, 把IdentityServer新增到ASP.NET Core的管道里:
啟用TLS(SSL)
我直接修改的launchSettings.json檔案, 只保留了這一部分.
然後執行程式, 訪問該網址: https://localhost:5001/.well-known/openid-configuration, 會得到以下畫面就說明Identity Server 4配置成功了:
為Identity Server 4 新增UI
Identity Server 4 的UI可以在這裡找到: https://github.com/IdentityServer/IdentityServer4.Quickstart.UI
根據文件描述, 在Dave.IdentityProvider專案目錄下開啟Powershell執行這句話即可安裝UI:
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/IdentityServer/IdentityServer4.Quickstart.UI/release/get.ps1'))
安裝好之後可以看到專案檔案的變化:
但是由於這套UI使用了ASP.NET Core MVC, 所以我還需要再配置一些東西.
在Startup的ConfigureServices裡, 註冊MVC:
在Startup的Configure裡, 在管道里使用靜態檔案和MVC:
再次執行程式, 首頁如下:
點選discovery document, 它就是我之前開啟的那個頁面.
ASP.NET Core MVC 作為客戶端
首先考慮ASP.NET Core MVC 作為客戶端應用的情況.
ASP.NET Core MVC是機密客戶端(Confidential Client), 它是傳統的伺服器端Web應用.
它需要長時間訪問(long-lived access), 所以需要refresh token. 那麼它可以使用Authorization Code Flow或Hybrid Flow.
在這裡Hybrid Flow是相對高階一些的, 它可以讓客戶端首先從授權端點獲得一個ID Token並通過瀏覽器(front-channel)傳遞過來, 這樣我們就可以驗證這個ID Token. 如果驗證成功然後, 客戶端再開啟一個後端通道(back-channel), 從Token端點獲取Access Token.
下面是OpenID Connect官方文件給出的一個身份認證請求的例子.
第一行的URI: "/authorize" 就是授權端點(Authorization Endpoint), 它位於身份提供商(Identity provider, IDP)那裡. 這個URI可以從前面介紹的discovery document裡面找到.
第二行 response_type=code id_token, 它決定了採取了哪一種Hybrid流程(參考上面那三個圖).
第三行 client_id=xxxx, 這是客戶端的身份標識.
第四行 redirect_uri=https...., 這是客戶端那裡的重定向端點(Redirection Endpoint).
第五行 scope=openid profile email, 這就是客戶端所請求的scopes.
再看一遍這張圖:
為什麼要返回兩次ID Token呢? 這是因為第(4)步裡面請求Token的時候要求客戶端身份認證, 這時請求Token的時候需要提供Authorization Code, Client ID和 Client Secret, 這些secret並不暴露給外界, 這些東西是由客戶端伺服器通過後端通道傳遞給Token端點的. 而第一次獲得的ID Token是從前端通道(瀏覽器)返回的.
當這個ID Token被驗證通過之後, 也就證明了當前使用者到底是誰.
下面簡單對比一下前端和後端通道:
建立ASP.NET Core MVC 客戶端
建立好後回到IdentityProvider專案, 新增一個Client:
這裡ClientName是客戶端名稱, 它會出現在使用者同意授權的頁面. 流程選擇的是Hybrid. 這裡暫時只請求OpenId這一個Scope, 以便只返回ID Token, 在GetIdentityResources()方法裡我知道支援這個scope. 這個流程的授權碼和tokens是通過跳轉來傳遞到瀏覽器的URI上面的, 所以我需要一個URI來接收這些東西, 而RedirectUris裡面的URI就是允許做這個工作的URI.
下面繼續配置MVC客戶端 (官方文件: https://identityserver4.readthedocs.io/en/release/quickstarts/3_interactive_login.html#creating-an-mvc-client).
在MVC客戶端的Startup的ConfigureServices裡:
下面的文字都是翻譯的官方文件.
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear(); 這句話是指, 我們關閉了JWT的Claim 型別對映, 以便允許well-known claims.
這樣做, 就保證它不會修改任何從Authorization Server返回的Claims.
這裡通過呼叫services.AddAuthentication()方法來新增和配置身份認證中介軟體.
這裡我們使用Cookie作為驗證使用者的首選方式, 而DefaultScheme = "Cookies", 這個"Cookies"字串是可以任意填寫的, 只要與後邊的一致即可. 但是如果同一個伺服器上有很多應用的話, 這個Scheme的名字不能重複.
而把DefaultChanllangeScheme設為"oidc", 這個名字與後邊配置OpenIdConnect的名字要一樣. 當使用者需要登陸的時候, 將使用的是OpenId Connect Scheme.
然後的AddCookie, 其引數是之前配置的DefaultScheme名稱, 這配置了Cookie的處理者, 並讓應用程式為我們的DefaultScheme啟用了基於Cookie的身份認證. 一旦ID Token驗證成功並且轉化為Claims身份標識後, 這些資訊就將會儲存於被加密的Cookie裡.
下面的AddOpenIdConnect()方法新增了對OpenID Connect流程的支援, 它讓配置了用來執行OpenId Connect 協議的處理者.
這個處理者會負責建立身份認證請求, Token請求和其它請求, 並負責ID Token的驗證工作.
它的身份認證scheme就是之前配置的"oidc", 它的意思就是如果該客戶端的某部分要求身份認證的時候, OpenID Connect將會作為預設方案被觸發(因為之前設定的DefaultChallengeScheme是"oidc", 和這裡的名字一樣).
SignInScheme和上面的DefaultScheme一致, 它保證身份認證成功的結果將會被儲存在方案名為"Cookies"的Cookie裡.
Authority就是Identity Provider的地址.
ClientId和Secret要與IdentityProvider裡面的值一樣.
ResponseType就是前面介紹過的.
請求的Scope有openid和profile, 其實中介軟體預設也包括了這些scope, 但是寫出來更明確一些.
SaveTokens=true, 表示允許儲存從Identity Provider那裡獲得的tokens.
然後配置管道:
確保中介軟體在UseMvc()之前呼叫.
還要確保監聽地址和IdentityProvider裡面配置的Client一致:
然後我對HomeController要求身份認證:
隨後修改一下About方法, 我僅僅是想展示token的資料:
這個token來自於cookie.
再修改About的頁面:
下面測試一下MVC客戶端的身份認證:
同時執行Identity Provider 和 Mvc 兩個程式, 最好使用控制檯, 這樣如果有錯誤的話就可以方便的看到相關資訊了.
在訪問Mvc的首頁時, 會自動跳轉到Identity Provider上:
具體的請求可以通過Chrome的Developer Tools看到:
在Identity Provider的控制檯上, 也可以看到相關資訊:
登入使用者之後, 就會看到徵求使用者同意授權的頁面:
點選Yes即可.
然後瀏覽器會調轉會MVC Client, 通過Chrome的工具檢視:
可以看到跳轉回來的時候是到了signin-oidc這個地址, 它就是我之前在Identity Provider裡面Client的RedirectUri.
與此同時, 可以在Identity Provider的控制檯看到, MVC客戶端通過後端通道向Token端點發出了Token請求, 這個過程使用者是不會發現的:
這個過程就和前面圖示的一樣, 最後從token端點請求到新的ID Token之後, 會再次進行驗證, 然後會通過它建立Claims Identity, 也就是前面程式碼裡的User.Claims.
這個身份驗證的憑據都會儲存在加密的Cookie裡面:
來到About選單:
最上面可以看到ID Token的值.
sid是sessionid.
sub是使用者的subjectid
idp是本地的.
我們可以在jwt.io來解析一下這個ID Token
解碼之後的ID Token:
這裡的內容以後再講.
登入好用之後, 就考慮一下登出.
再_Layout.cshtml裡面新增登出按鈕, 這部分官方文件都有:
然後建立Action方法:
首先要清除本地的Cookie, 這個Cookie的名字要與之前配置的預設方案裡的名字一致, 這一步就相當於登出MVC客戶端.
後一行程式碼的作用是跳轉回到Identity Provider, 然後使用者可以繼續登出IDP, 也就是IDP會清除它的Cookie.
但是登出之後, 使用者會留在Identity Provider那裡:
檢視IDP的控制檯, 可以看到這個失敗: Invalida post logout URI:
這是因為我們配置Client的時候沒有指定在登出之後的跳轉URI地址.
回到IDP的客戶端配置那裡:
新增PostLogoutRedirectUris屬性, 裡面這個值是就是預設的登出後跳轉地址.
再次操作後, 效果如下:
點選here之後會回到MVC客戶端, 然後由於許可權問題會又立即跳轉到IDP.
如果想讓這個過程自動跳轉, 可以修改IDP的Quickstart/Account/AccountOptions類裡面的這個值改成true:
再次操作, 跳轉就是自動完成的了.
使用者資訊節點
檢視解碼的ID Token, 可以看到裡面包含了這些claims:
這裡除了sub之外, 並沒有關於使用者的其他資訊.
我們可以通過指定引數來要求在ID Token裡面返回使用者其他的claims, 但是由於id token是從URI進行傳輸的, 而瀏覽器會有URI的長度限制, 所以儘量讓token小點, 以免超限.
為了獲得使用者其他的claims, 客戶端應用可以使用使用者資訊端點, 這需要用access token和相關claims對應的scopes.
首先在MVC客戶端配置, GetClaimsFromUserInfoEndpoit為true, 並請求profile scope:
隨後在IDP那裡為MVC Client新增上profile scope:
再次執行操作, 回到About頁面:
可以看到profile scope裡對應的這兩個claims值已經出來了.
再把ID Token到jwt.io去解碼一下:
可以看到這兩個claims並不在ID Token裡面, 這就說明它們來自使用者資訊端點.
在ID Token裡面的東西(官方文件有介紹: http://openid.net/specs/openid-connect-core-1_0.html#IDToken):
sub是使用者的subjectid, 也就是使用者的身份標識.
iss是ID Token的發行者.
aud是這個token的目標觀眾, 這裡就是MVC客戶端的clientid.
nbf是指在這個時間之前, ID Token是不被接受的.
exp是ID Token的過期時間.
iat是這個JWT token發行的時間.
auth_time是原始身份認證的時間.
amr是指身份認證的方法. 這裡用的是pwd, 密碼.
nonce, 它是Number only to be used once的意思. 它是一個字串, 使用ID Token和客戶端Session關聯, 來減少重複攻擊.
最後是at_hash, 其實還有c_hash, 它們分別代表Access Token Hash和Code Hash. 就是通過某種方式對Access Token和Code的Base64編碼. 它們可以用來把Access Token或Authorization Code連結到這個ID Token上.
今天先到這.
程式碼在: https://github.com/solenovex/Identity-Server-4-Tutorial-Code 的01部分.