學習Identity Server 4的預備知識 (誤刪, 重補)

我要使用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(例如適用於沒有用戶參與的狀況).