預備知識
可能需要看一點點預備知識
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部分.