在Program.cs中引入：

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：域名注冊、虛擬空間、營銷軟件、網(wǎng)站建設(shè)、彭州網(wǎng)站維護(hù)、網(wǎng)站推廣。

app.UseAuthentication();//鑒權(quán) ?中間件

然后引入，并配置跳轉(zhuǎn)地址：

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,options =>{
        options.LoginPath = "/Home/Index";  //登陸地址 沒有登錄就跳轉(zhuǎn)
        options.AccessDeniedPath= "/Home/Index"; //權(quán)限地址 沒有權(quán)限就跳轉(zhuǎn)
    });

編寫一個測試案例：?

[Authorize()]?
? ? ? ? public IActionResult Privacy()
? ? ? ? {
? ? ? ? ? ? return View();
? ? ? ? }

當(dāng)訪問：網(wǎng)址的時候：

就會跳轉(zhuǎn)到設(shè)置好的主頁：

從 Http 無狀態(tài) ---- 到 Cookie-Session---- 到 Token 機(jī)制 （什么是HTTP無狀態(tài)？ HTTP無狀態(tài)協(xié)議，是指 協(xié)議對于交互性場景沒有記憶能力 ）

舉例：

在點(diǎn)擊一個純的html網(wǎng)頁，請求獲取服務(wù)器的html文件資源時，每次http請求都會返回同樣的信息，因為這個是沒有交互的，每一次的請求都是相互獨(dú)立的。第一個請求和第二個請求也沒有先后順序，返回處理哪個，結(jié)果都是同樣的資源頁面，因為這種場景是無交互的，無論是什么人請求這個地址，服務(wù)器都是返回那個相同的響應(yīng)。?

Cookie

由于HTTP是一種無狀態(tài)的協(xié)議，服務(wù)器單純從網(wǎng)絡(luò)連接上無從知道客戶身份。怎么辦呢？就給客戶端們頒發(fā)一個通行證吧，每人一個，無論誰訪問都必須攜帶自己通行證。這樣服務(wù)器就能從通行證上確認(rèn)客戶身份了。這就是Cookie的工作原理。?

Cookie實際上是一小段的文本信息?？蛻舳苏埱蠓?wù)器，如果服務(wù)器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie。客戶端瀏覽器會把Cookie保存起來。當(dāng)瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務(wù)器。服務(wù)器檢查該Cookie，以此來辨認(rèn)用戶狀態(tài)。服務(wù)器還可以根據(jù)需要修改Cookie的內(nèi)容。

?Cookie的不可跨域名性

很多網(wǎng)站都會使用Cookie。例如，Google會向客戶端頒發(fā)Cookie，Baidu也會向客戶端頒發(fā)Cookie。那瀏覽器訪問Google會不會也攜帶上Baidu頒發(fā)的Cookie呢？或者Google能不能修改Baidu頒發(fā)的Cookie呢？

答案是否定的。Cookie具有不可跨域名性。根據(jù)Cookie規(guī)范，瀏覽器訪問Google只會攜帶Google的Cookie，而不會攜帶Baidu的Cookie。Google也只能操作Google的Cookie，而不能操作Baidu的Cookie。

Cookie在客戶端是由瀏覽器來管理的。瀏覽器能夠保證Google只會操作Google的Cookie而不會操作Baidu的Cookie，從而保證用戶的隱私安全。瀏覽器判斷一個網(wǎng)站是否能操作另一個網(wǎng)站Cookie的依據(jù)是域名。Google與Baidu的域名不一樣，因此Google不能操作Baidu的Cookie。

Cookie的一個實例

基本流程： 1 請求服務(wù)端拿到憑證 2 客戶端請求帶上憑證 3 服務(wù)端通過憑證來決定是否允許訪問 什么是SSO：

單點(diǎn)登錄(SingleSignOn，SSO)，就是通過用戶的一次性鑒別登錄。當(dāng)用戶在身份認(rèn)證服務(wù)器上登錄一次以后，即可獲得訪問單點(diǎn)登錄系統(tǒng)中其他關(guān)聯(lián)系統(tǒng)和應(yīng)用軟件的權(quán)限，同時這種實現(xiàn)是不需要管理員對用戶的登錄狀態(tài)或其他信息進(jìn)行修改的，這意味著在多個應(yīng)用系統(tǒng)中，用戶只需一次登錄就可以訪問所有相互信任的應(yīng)用系統(tǒng)。這種方式減少了由登錄產(chǎn)生的時間消耗，輔助了用戶管理，是比較流行的。

什么是鑒權(quán) ？什么是授權(quán)?

鑒權(quán)：就是檢測一下操作人/用戶---是不是張三

授權(quán)： 如果是張三 就給他一定的權(quán)限 比如 是管理員才能進(jìn)入某個網(wǎng)頁

理解鑒權(quán)：

憑證位置：怎么去傳遞的憑證：-url地址，header，authorize--AuthenticationScheme

憑證格式：加密/序列化--JWT是兩種，Cookie--AuthenticationScheme

信息的有效性：JWT的屬性檢測

鑒權(quán)后信息的保存：context.User

特殊情況處理：沒登錄--沒權(quán)限--其他

Token憑證：

token就相當(dāng)于一個憑證? ?也就是相當(dāng)于一個工牌? 和cookie 差不多

訪問服務(wù)的時候就上傳憑證

服務(wù)直接可以認(rèn)可token? ?不需要去授權(quán)中心檢測

Token的信任機(jī)制：

如何建立的信任關(guān)系呢？

靠的是----非對稱可逆加密

加密是對原文加密

解密是對原文解密

加密鑰和解密鑰是一一對應(yīng)的? 不可以從解密鑰中推出加密鑰

可逆加密是指經(jīng)過加密過后的信息可以通過對應(yīng)的密鑰反向解析還原信息內(nèi)容，

第一是：Https

鑒權(quán)中心會生成一組密鑰： 解密鑰公開，加密鑰保密，用戶登錄驗證成功，把用戶信息轉(zhuǎn)成json字符串，然后用私秘鑰加密，其他API都可以用公鑰解開密文，這就能證明Token來自于授權(quán)服務(wù)器，別人是無法偽造的。

或者用非對稱可逆加密?但是密鑰是一樣的 容易泄露

Token過期？信息被篡改？

其實都不會發(fā)生，傳遞的信息帶上時間

刷新Token 也叫雙Token Access Token + Refresh Token

Cookie和Sesson的區(qū)別：

cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。

2、cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙
考慮到安全應(yīng)當(dāng)使用session。

3、session會在一定時間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多，會比較占用你服務(wù)器的性能
考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE。

4、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點(diǎn)最多保存20個cookie。

5、所以個人建議：
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留，可以放在COOKIE中

JWT局限性 基于 JWT 登陸驗證鑒權(quán)授權(quán)雖然完成了 SSO ，但真的上生產(chǎn)環(huán)境，還有很多 問題要解決！因為 Token 是天生有缺陷的： 1 萬一 Token 泄漏 ---- 確實會泄露，因為在瀏覽器是明文保存，有心是能看到 的 --- 難道 Cookie 就不泄露嗎？ ---SSL 通信保證傳輸安全，客戶端的安全靠 客戶自己 --- 在敏感環(huán)節(jié)，再做一些額外驗證 --- 2 改密碼刪用戶等不能立即失效 Token---- 因為沒有實時驗證，本質(zhì)決定了幾 乎做不到 --- 除非用中心化模式 ( 搞個 Redis 集中校驗 )--- 還有就是縮短有效 期，降低傷害 ( 但是頻繁過期登陸的體驗也不好 ) 3 滑動過期， token 在用，就別過期 --- 但是又不可能，因為 token 是不可變更 的 --- 搞個 Redis 保存正在用的 Token( 問題是 Token 不過期也不行，萬一改 密碼了呢？ ) 什么是刷新Token：

刷新Token優(yōu)勢 改密碼等 Token 過期問題 ---- 滑動過期問題 ----- 1 短期需要請求一次授權(quán)中心，類似改密碼等問題能解決 ( 清理對應(yīng)的 refreshToken 即可 ) 2 用戶感知不到刷新 Token 刷新Token的流程：（定期和服務(wù)器做通信 ，用戶無感）

客戶請求時候 返回AccessToken + RefreshToken? 且服務(wù)端緩存refreshToken

正常帶AccessToken訪問

當(dāng)token過期時候就返回401

自動使用refreshToken（服務(wù)端緩存數(shù)據(jù)，不需要賬號密碼）獲取心得AccessToken（用戶無感）

使用心得AccessToken

刷新Token驗證流程 1 客戶端請求時，返回 AccessToken+RefreshToken ，且服務(wù)端緩存 refreshToken 2 正常帶 AccessToken 訪問 3 當(dāng) Token 過期，返回 401( 用 Header 更可靠 ) 4 自動使用 refreshToken( 服務(wù)端緩存數(shù)據(jù)，不需要賬號密碼 ) ，獲取新的 AccessToken( 用戶無感 ) 5 使用新的 accessToken 訪問

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

網(wǎng)頁名稱：JWT鑒權(quán)中心實現(xiàn)鑒權(quán)授權(quán)刷新Token-創(chuàng)新互聯(lián)
文章位置：http://jinyejixie.com/article42/ddeshc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、電子商務(wù)、品牌網(wǎng)站設(shè)計、Google、ChatGPT、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)