一、前言
在上一篇中，我們IdentityServer4的說明，認識到是一個基於OpenID Connect協議標准的身份認證和授權程序，並簡單的對基礎知識的認識以及區別說明，從OAuth、OpenID、OpenID Connect以及JWT等進行對比區別說明。
而在這一篇中，我們主要對IdentityServer4中涉及使用的特定的相關術語進行說明。
二、術語
2.1 身份認證服務器（IdentityServer）
IdentityServer 是基於OpenID Connect協議標准的身份認證和授權程序，它實現了OpenID Connect 和 OAuth 2.0 協議。
同樣的角色，不同的文檔使用不同的術語。在有些文檔中，它（IdentityServer）可能會被叫做安全令牌服務器（security token service）、身份提供者（identity provider）、授權服務器（authorization server）、 標識提供方（(IP-STS，什么是IP-STS）等等。
但是它們都是一樣的，都是向客戶端發送安全令牌（security token），
IdentityServer有許多功能：
- 保護你的資源
- 使用本地帳戶或通過外部身份提供程序對用戶進行身份驗證
- 提供會話管理和單點登錄
- 管理和驗證客戶機
- 向客戶發出標識和訪問令牌
- 驗證令牌
2.2 用戶（User）
用戶是使用已注冊的客戶端訪問資源的人。
指在id4中已經注冊的用戶
2.3 客戶端（Client）
客戶端就是從identityserver請求令牌的軟件，既可以通過身份認證令牌來驗證識別用戶身份，又可以通過授權令牌來訪問服務端的資源。但是客戶端首先必須在申請令牌前已經在identityserver服務中注冊過。
實際客戶端不僅可以是Web應用程序，app或桌面應用程序，SPA，服務器進程等。
客戶端：web、app、桌面應用、SPA、服務器進程
2.4 資源（Resources）
資源就是你想用identityserver保護的東西，可以是用戶的身份數據或者api資源。
每一個資源都有一個唯一的名稱，客戶端使用這個唯一的名稱來確定想訪問哪一個資源
在訪問之前，實際identityserver服務端已經配置好了哪個客戶端可以訪問哪個資源，所以你不必理解為客戶端只要指定名稱他們就可以隨便訪問任何一個資源
用戶的身份信息實際由一組claim組成，例如姓名或者郵件都會包含在身份信息中。
用戶身份信息將來通過identityserver校驗后都會返回給被調用的客戶端
API資源就是客戶端想要調用的功能——通常通過 Web API 來對 API 資源建模，但這不是必須的，如下說明：
通常以json或xml的格式返回給客戶端，例如webapi，wcf,webservice，可以使其他類型的格式，這個要看具體的使用場景了。
2.5 身份令牌（Id Token）
OIDC對OAuth2最主要的擴展就是提供了ID Token。來解決第三方客戶端標識用戶身份認證的問題。
OIDC的核心在於在OAuth2的授權流程中，一並提供用戶的身份認證信息（ID Token）給到第三方客戶端，ID Token使用JWT格式來包裝，得益於JWT（JSON Web Token）的自包含性，緊湊性以及防篡改機制，使得ID Token可以安全的傳遞給第三方客戶端程序並且容易被驗證。此外還提供了UserInfo的接口，用戶獲取用戶的更完整的信息。
ID Token是一個安全令牌，表示的是認證過程的輸出，是一個授權服務器提供的包含用戶信息，還包含了用戶的認證時間和認證方式。身份令牌可以包含額外的身份數據。
由一組Cliams構成以及其他輔助的Cliams的JWT格式的數據結構組成。
ID Token的主要構成部分如下（使用OAuth2流程的OIDC）。
- iss = Issuer Identifier：必須。提供認證信息者的唯一標識。一般是一個https的url（不包含querystring和fragment部分）。
- sub = Subject Identifier：必須。iss提供的EU的標識，在iss范圍內唯一。它會被RP用來標識唯一的用戶。最長為255個ASCII個字符。
- aud = Audience(s)：必須。標識ID Token的受眾。必須包含OAuth2的client_id。
- exp = Expiration time：必須。過期時間，超過此時間的ID Token會作廢不再被驗證通過。
- iat = Issued At Time：必須。JWT的構建的時間。
- auth_time = AuthenticationTime：EU完成認證的時間。如果RP發送AuthN請求的時候攜帶max_age的參數，則此Claim是必須的。
- nonce：RP發送請求的時候提供的隨機字符串，用來減緩重放攻擊，也可以來關聯ID Token和RP本身的Session信息。
- acr = Authentication Context Class Reference：可選。表示一個認證上下文引用值，可以用來標識認證上下文類。
- amr = Authentication Methods References：可選。表示一組認證方法。
- azp = Authorized party：可選。結合aud使用。只有在被認證的一方和受眾（aud）不一致時才使用此值，一般情況下很少使用。
ID Token通常情況下還會包含其他的Claims。
（畢竟上述claim中只有sub是和EU相關的，這在一般情況下是不夠的，必須還需要EU的用戶名，頭像等其他的資料，OIDC提供了一組公共的cliams，請移步這里http://openid.net/specs/openid-connect-core-1_0.html#StandardClaims）。另外ID Token必須使用JWS進行簽名和JWE加密，從而提供認證的完整性、不可否認性以及可選的保密性。
簡而言之ID Token就是JWT格式的數據，包含一個人類用戶的身份認證的信息，一個ID Token的例子如下：
2.6 訪問令牌（Access Token）
訪問令牌允許客戶端訪問某個 API 資源。客戶端請求到訪問令牌，然后使用這個令牌來訪問 API資源。訪問令牌包含了客戶端和用戶（如果有的話，這取決於業務是否需要，但通常不必要）的相關信息，API通過這些令牌信息來授予客戶端的數據訪問權限。
OAuth2提供了Access Token來解決授權第三方客戶端訪問受保護資源的問題；
2.7 刷新令牌（Refresh Token）
Access Token 是客戶端訪問資源服務器的令牌。擁有這個令牌代表着得到用戶的授權。然而，這個授權應該是臨時的，有一定有效期。這是因為，Access Token 在使用的過程中可能會泄露。給 Access Token 限定一個較短的有效期可以降低因 Access Token 泄露而帶來的風險。
然而引入了有效期之后，客戶端使用起來就不那么方便了。每當 Access Token 過期，客戶端就必須重新向用戶索要授權。這樣用戶可能每隔幾天，甚至每天都需要進行授權操作。這是一件非常影響用戶體驗的事情。希望有一種方法，可以避免這種情況。
於是 Oauth2.0 引入了 Refresh Token 機制。Refresh Token 的作用是用來刷新 Access Token。鑒權服務器提供一個刷新接口，例如：
http://xxx.xxx.com/refresh?refreshtoken=&client_id=
傳入 refresh token 和 client_id，鑒權服務器驗證通過后，返回一個新的 access token。為了安全，Oauth2.0 引入了兩個措施：
1，Oauth2.0 要求，refresh token 一定是保存在客戶端的服務器上的，而絕不能存放在狹義的客戶端（例如移動 app、PC端軟件） 上。調用 refresh 接口的時候，一定是從服務器到服務器的訪問；
2，Oauth2.0 引入了 client_secret 機制。即每一個 client_id 都對應一個 client_secret。這個 client_secret 會在客戶端申請 client_id 時，隨 client_id 一起分配給客戶端。客戶端必須把 client_secret 妥善保管在服務器上，決不能泄露。刷新 access token 時，需要驗證這個 client_secret。
於是，實際上的刷新接口應該是類似這樣的：
http://xxx.xxx.com/refresh?refreshtoken=&client_id=&client_secret=
以上就是 Refresh Token 機制。 Refresh Token 的有效期非常長，會在用戶授權時，隨 Access Token 一起重定向到回調 url，傳遞給客戶端。
三、總結
- 本篇主要是對IdentityServer4的說明，以及其中涉及常見的術語的表述說明。
- 從身份認證服務器、用戶、客戶端、資源以及各個令牌等進行對比區別說明。
- 在后續中會對多種授權模式，數據庫持久化以及UI界面優化和常見問題，搭建一個完整可用的認證授權項目。
- 如果有不對的或不理解的地方，希望大家可以多多指正，提出問題，一起討論,不斷學習,共同進步。