我要使用asp.net core 2.0 web api 搭建一個(gè)基礎(chǔ)框架并立即應(yīng)用于一個(gè)實(shí)際的項(xiàng)目中去.這里需要使用identity server 4 做單點(diǎn)登陸.下面就簡單學(xué)習(xí)一下相關(guān)的預(yù)備知識(shí).

基于Token的安全驗(yàn)證體系

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

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

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

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

使用基于token的安全體系有什么優(yōu)點(diǎn)?

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

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

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

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

交換憑證獲取token并使用token

有一個(gè)已注冊(cè)用戶, 她為了獲取token, 就需要與authorization server進(jìn)行通信. 這個(gè)authorization server負(fù)責(zé)發(fā)放token, 并且確保token是否仍然有效. 它同時(shí)也負(fù)責(zé)跟蹤用戶的用戶名和密碼. 而這個(gè)authorization server可以存在于世界的任何地方, 它并不是非得和我們的web api或者網(wǎng)站放在一起. 它完全是一個(gè)獨(dú)立的系統(tǒng), 跟蹤著用戶的用戶名密碼以及用戶的訪問權(quán)限.

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

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

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

要把Token向密碼一樣對(duì)待

保護(hù)好token, 因?yàn)閯e人獲得token后將會(huì)和你擁有一樣的權(quán)限.

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

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

如何保證token的安全

如圖, 用戶帶著token向api發(fā)出請(qǐng)求, token是附帶在header中, api收到請(qǐng)求后會(huì)返回一些數(shù)據(jù).

如果有人查看了這個(gè)token, 并要篡改token里面的數(shù)據(jù), 那可就不好了

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

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

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

private key 可以用于鎖定 token.

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

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

Token

如果在api里面驗(yàn)證了token的完整性, 那么我們就會(huì)知道token是ok的.

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

token是由authorization server簽名發(fā)布的.

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

private key 是用來簽發(fā)token用的, 它只存在于authorization server, 永遠(yuǎn)不要讓別人知道private key.

public key 是用來驗(yàn)證token的, authorization server 會(huì)讓所有人都知道這個(gè)public key的.

api或者各種消費(fèi)者應(yīng)該一直檢驗(yàn)token, 以確保它們沒有被篡改. 它們可以向authorization server申請(qǐng)public key, 并使用它來驗(yàn)證token. 也可以把token傳遞給authorization server, 并讓authorization server來進(jìn)行驗(yàn)證.

Token同時(shí)也包含著authorization server的一些信息. 比如是由哪個(gè)authorization server發(fā)布的token.

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

OAuth 和 OpenId Connect

他們都是安全協(xié)議.

現(xiàn)在使用的都是OAuth 2.0, 注意它與1.0不兼容.

OAuth 2.0是用于authorization的工業(yè)標(biāo)準(zhǔn)協(xié)議. 它關(guān)注的是為web應(yīng)用, 桌面應(yīng)用, 移動(dòng)應(yīng)用等提供特定的authorization流程并保證開發(fā)的簡單性.

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

OAuth是基于token的協(xié)議.

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

OAuth只負(fù)責(zé)Authorization. 那么誰來負(fù)責(zé)Authentication呢?

那就是OpenId Connect,?OpenId Connect是對(duì)OAuth的一種補(bǔ)充, 因?yàn)樗苓M(jìn)行Authentication.

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

可以有多種方式來實(shí)現(xiàn)OAuth和OpenId Connect這套協(xié)議.

你可以自己去實(shí)現(xiàn).?

我要使用的是Identity Server 4.

其實(shí)也可以使用一些Saas/Paas服務(wù), 例如Amazon Cognito, Auth0(這個(gè)用過, 有免費(fèi)版), Stormpath.

OAuth 2.0 RFC 6794

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

OAuth通常有以下幾種endpoint:

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

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

3. /revocation, 吊銷token.

OpenId Connect 通常有以下幾種 endpoints:

1. /userinfo, 獲取用戶信息

2. /checksession, 檢查當(dāng)前用戶的session

3. /endsession, 終結(jié)當(dāng)前用戶的session

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

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

獲取Token的例子:

使用postman大約是這樣發(fā)送請(qǐng)求.

請(qǐng)求返回的結(jié)果大約是這樣的:

access_token就是token, expires_in是有效時(shí)間, 類型是 Bearer.

可以到j(luò)wt.io去解析token:?http://jwt.io/

由于網(wǎng)絡(luò)問題, 我今天無法使用這個(gè)網(wǎng)站.....以后做項(xiàng)目寫文章的時(shí)候再介紹. 這里你可以試試把一個(gè)token的數(shù)據(jù)更改之后, token驗(yàn)證就出錯(cuò)了.?

下面這個(gè)圖是如何使用token訪問api:

Access Token (JWT)

紅色的是Header, 橘色的是Payload, 藍(lán)色的是簽名Signature. 它們是用.分開的

Signature主要是來保證Payload的完整性. Header包含了token的結(jié)構(gòu)信息.

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

Scopes

scopes可以限定訪問的范圍.

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

當(dāng)然也可以自定義scope.

選擇一個(gè)流程 Flow

Redirect Flows, 它可以這樣解釋: 有一個(gè)用戶想要訪問我的網(wǎng)站, 我想讓他登錄, 但又不想讓他把用戶名和密碼提供給我, 因?yàn)槲覜]有用戶的信息. 用戶的信息都在authorization server上了. 所以我把用戶重定向到authorization server, 提供他們的用戶名和密碼, 然后重定向返回到我的網(wǎng)站, 獲取了token, 這時(shí)我就知道他們已經(jīng)登錄好了.

?

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

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

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

相關(guān)文章：

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

• IdentityServer4 實(shí)現(xiàn) OpenID Connect 和 OAuth 2.0

• IdentityServer4 使用OpenID Connect添加用戶身份驗(yàn)證

• IdentityServer4 ASP.NET Core的OpenID Connect OAuth 2.0框架學(xué)習(xí)保護(hù)API

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

• IdentityServer4 SigningCredential（RSA 證書加密）

• IdentityServer4 實(shí)現(xiàn)自定義 GrantType 授權(quán)模式

• IdentityServer4 配置負(fù)載均衡

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

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺(tái)或掃描二維碼關(guān)注

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。