我要使用asp.net core 2.0 web api 搭建一個基礎框架并立即應用于一個實際的項目中去.這里需要使用identity server 4 做單點登陸.下面就簡單學習一下相關的預備知識.

基于Token的安全驗證體系

這個比較簡單, 簡單來說就是為了證明我們有訪問權限, 我們首先需要獲得一個token.

什么是token? 比如說: 可以訪問某些大樓的門禁卡就是一種token, 回家開門的鑰匙也是一種token.

為了獲取到token, 首先你需要驗證你的身份, 以證明你確實有權利獲得token. 比如說, 你可以亮出身份證來證明自己, 或者使用密碼.

比如說你想訪問我的辦公室, 你首先去安全部門亮出身份證, 然后安全辦公室給你一個token, 然后使用這個token你就可以進入辦公室去干事了.

使用基于token的安全體系有什么優點?

如果不使用token, 你可能需要到處使用密碼來證明身份. 這樣的話, 那每個地方都會知道你的密碼了.

如果token丟失了, 我們可以吊銷token.

并且token都有一定的時效性. 過期作廢

總之, 使用這種方式, 你可以只在一個地方使用密碼, 別的地方不會知道你的密碼.

交換憑證獲取token并使用token

有一個已注冊用戶, 她為了獲取token, 就需要與authorization server進行通信. 這個authorization server負責發放token, 并且確保token是否仍然有效. 它同時也負責跟蹤用戶的用戶名和密碼. 而這個authorization server可以存在于世界的任何地方, 它并不是非得和我們的web api或者網站放在一起. 它完全是一個獨立的系統, 跟蹤著用戶的用戶名密碼以及用戶的訪問權限.

這里這個用戶就向authorization server提供了用戶名和密碼, 然后她就獲得了token. 然后她就可以使用這個token做一些事情了, 比如使用token訪問api請求所有的訂單信息, 這時api就會知道這個token是有效的.

甚至, 用戶使用token可以訪問第三方服務, 第三方服務再使用這個token來訪問我們的api.

向第三方服務提供token肯定比提供用戶名密碼安全多了.

要把Token向密碼一樣對待

保護好token, 因為別人獲得token后將會和你擁有一樣的權限.

token是有時效性的, 具體有效期是多久是由authorization server決定的.

token是可以吊銷的, 你可以告訴authorization server注銷你的token, 但是要注意的是, 是由api決定是否向authorization server查詢token的有效性, 如果你吊銷token或api沒有向authorization server進行查詢, 那么你的token對api來說依然有效.

如何保證token的安全

如圖, 用戶帶著token向api發出請求, token是附帶在header中, api收到請求后會返回一些數據.

如果有人查看了這個token, 并要篡改token里面的數據, 那可就不好了

那么如何保證token不被篡改呢? 這個工作是由api來做的, 它要確保沒人篡改過token.

在基于token驗證的情景中, 所有從authorization server獲取的token都是使用一個private key簽過名的. token包括一些信息: 用戶本身(email, 權限等等), 也可能包括是誰發布了token.

任何一個服務想確定沒人篡改過token, 就需要使用public key.

private key 可以用于鎖定 token.

針對token和它帶的數據以及在token尾部的簽名信息, 只要沒人篡改數據, 那么token的簽名就是一定的.

authorization server提供的public key是任何人都可以訪問的, public key是用來確保沒人篡改過數據.

Token

如果在api里面驗證了token的完整性, 那么我們就會知道token是ok的.

我們這里研究的token是Json Web Token.

token是由authorization server簽名發布的.

authorization server就是使用oauth和openid connect等協議, 并且用戶可以使用用戶名密碼等方式來換取token的服務, 這些token讓我們擁有了訪問一些資源的權限.

private key 是用來簽發token用的, 它只存在于authorization server, 永遠不要讓別人知道private key.

public key 是用來驗證token的, authorization server 會讓所有人都知道這個public key的.

api或者各種消費者應該一直檢驗token, 以確保它們沒有被篡改. 它們可以向authorization server申請public key, 并使用它來驗證token. 也可以把token傳遞給authorization server, 并讓authorization server來進行驗證.

Token同時也包含著authorization server的一些信息. 比如是由哪個authorization server發布的token.

Token的信息是使用Base64編碼的.

OAuth 和 OpenId Connect

他們都是安全協議.

現在使用的都是OAuth 2.0, 注意它與1.0不兼容.

OAuth 2.0是用于authorization的工業標準協議. 它關注的是為web應用, 桌面應用, 移動應用等提供特定的authorization流程并保證開發的簡單性.

Authorization的意思是授權, 它表示我們可以授權給某些用戶, 以便他們能訪問一些數據, 也就是提供訪問權.

OAuth是基于token的協議.

有些人可能對Authorization和Authentication分不清, 上面講了authorization, 而authentication則是證明我是誰, 例如使用用戶名和密碼進行登錄就是authentication.

OAuth只負責Authorization. 那么誰來負責Authentication呢?

那就是OpenId Connect,?OpenId Connect是對OAuth的一種補充, 因為它能進行Authentication.

OpenId Connect 是位于OAuth 2.0上的一個簡單的驗證層, 它允許客戶端使用authorization server的authentication操作來驗證終端用戶的身份, 同時也可以或缺終端客戶的一些基本信息.

可以有多種方式來實現OAuth和OpenId Connect這套協議.

你可以自己去實現.?

我要使用的是Identity Server 4.

其實也可以使用一些Saas/Paas服務, 例如Amazon Cognito, Auth0(這個用過, 有免費版), Stormpath.

OAuth 2.0 RFC 6794

想研究的比較透徹的話, 還是要多讀幾遍 RC 6749文檔:?https://tools.ietf.org/html/rfc6749

OAuth通常有以下幾種endpoint:

1. /authorize, 請求token(通過特定的流程flows)

2. /token, 請求token(通過特定的流程flows), 刷新token, 使用authorization code來換取token.

3. /revocation, 吊銷token.

OpenId Connect 通常有以下幾種 endpoints:

1. /userinfo, 獲取用戶信息

2. /checksession, 檢查當前用戶的session

3. /endsession, 終結當前用戶的session

4. /.well-known/openid-configuration, 提供了authorization server的信息(endpoints列表和配置信息等)

5. /.well-known/jwks, 列出了JWT簽名key的信息, 它們是用來驗證token的.

獲取Token的例子:

使用postman大約是這樣發送請求.

請求返回的結果大約是這樣的:

access_token就是token, expires_in是有效時間, 類型是 Bearer.

可以到jwt.io去解析token:?http://jwt.io/

由于網絡問題, 我今天無法使用這個網站.....以后做項目寫文章的時候再介紹. 這里你可以試試把一個token的數據更改之后, token驗證就出錯了.?

下面這個圖是如何使用token訪問api:

Access Token (JWT)

紅色的是Header, 橘色的是Payload, 藍色的是簽名Signature. 它們是用.分開的

Signature主要是來保證Payload的完整性. Header包含了token的結構信息.

Payload有時候也叫做Claims, 它通常包括發布者issuer(authorization server), Audience, 有效期, 有時也包括token應該是從什么時候開始有效, Client ID(這是那些注冊于authorization server的應用), Scopes(限定訪問的范圍), 自定義數據.

Scopes

scopes可以限定訪問的范圍.

OpenId Connect為我們指定了一些 Scopes,?包括: openid, profile, email, address, offline_access等等.

當然也可以自定義scope.

選擇一個流程 Flow

Redirect Flows, 它可以這樣解釋: 有一個用戶想要訪問我的網站, 我想讓他登錄, 但又不想讓他把用戶名和密碼提供給我, 因為我沒有用戶的信息. 用戶的信息都在authorization server上了. 所以我把用戶重定向到authorization server, 提供他們的用戶名和密碼, 然后重定向返回到我的網站, 獲取了token, 這時我就知道他們已經登錄好了.

?

Redirect Flows又分兩種: 1?Implicit Grant(就是上面說的那個), 2?Authorization Code(它并沒有返回token, 而是返回了authorization code, 而網站可以使用authorization code來換取token).

所以implicit grant適合于javascript客戶端, 而其他應用更適合使用authorization code, 這些應用可以使用authorization code刷新token.

Credential Flows: 1.Resource Owner Password Credentials(用戶名密碼). 2.?Client Credentials(例如適用于沒有用戶參與的情況).

相關文章：

• IdentityServer4(OAuth2.0服務)折騰筆記

• IdentityServer4 實現 OpenID Connect 和 OAuth 2.0

• IdentityServer4 使用OpenID Connect添加用戶身份驗證

• IdentityServer4 ASP.NET Core的OpenID Connect OAuth 2.0框架學習保護API

• IdentityServer4 指定角色授權（Authorize(Roles="admin"))

• IdentityServer4 SigningCredential（RSA 證書加密）

• IdentityServer4 實現自定義 GrantType 授權模式

• IdentityServer4 配置負載均衡

原文地址：http://www.cnblogs.com/cgzl/p/7746496.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的学习Identity Server 4的预备知识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。