asp.net core 整合JWT（二）token的強制失效，基於策略模式細化api許可權

阿新 • • 發佈：2019-06-14

【前言】

　　上一篇我們介紹了什麼是JWT，以及如何在asp.net core api專案中整合JWT許可權認證。傳送門：https://www.cnblogs.com/7tiny/p/11012035.html

　　很多博友在留言中提出了疑問：

如何結合jwt認證對使用者進行API授權？
token過期了怎麼辦?
如何自動重新整理token？
如何強制token失效？
如何應用到叢集模式？

　　那麼，便有了本篇。本篇在上一篇的基礎上繼續完善JWT的使用，並陸續回答上面的疑問。當然Demo中沒有體現的也會提供思路供博友參考。

【一、如何結合JWT認證對使用者進行API授權】

　　場景：我們有多個API介面，我們希望細化地控制哪個使用者可以訪問哪些API（可能是在某個授權介面進行API授權）

　　還是我們上一篇中的Demo專案：https://github.com/sevenTiny/Demo.Jwt

　　我們添加了兩個類:PolicyHandler.cs和PolicyRequirement.cs

　　首先是：PolicyRequirement.cs，這個類檔案中定義了一個使用者名稱和url的對應實體，UserPermission使用者許可權承載實體。然後實現了微軟自帶的介面IAuthorizationRequirement，裡面構造方法賦值瞭如果沒有許可權將要跳轉的介面和某使用者所有有許可權的介面的配置集合，因為只寫了一個介面，這裡只配置了一條作為Demo，當然了，在實際應用的時候，所有的這些配置我們都可以寫在資料庫中持久化，需要的時候讀取出來即可。

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Http;
using System.Collections.Generic;

namespace Demo.Jwt.AuthManagement
{
    /// <summary>
    /// 許可權承載實體
    /// </summary>
    public class PolicyRequirement : IAuthorizationRequirement
    {
        /// <summary>
        /// 使用者許可權集合
        /// </summary>
        public List<UserPermission> UserPermissions { get; private set; }
        /// <summary>
        /// 無許可權action
        /// </summary>
        public string DeniedAction { get; set; }
        /// <summary>
        /// 構造
        /// </summary>
        public PolicyRequirement()
        {
            //沒有許可權則跳轉到這個路由
            DeniedAction = new PathString("/api/nopermission");
            //使用者有許可權訪問的路由配置,當然可以從資料庫獲取
            UserPermissions = new List<UserPermission> {
                              new UserPermission {  Url="/api/value3", UserName="admin"},
                          };
        }
    }

    /// <summary>
    /// 使用者許可權承載實體
    /// </summary>
    public class UserPermission
    {
        /// <summary>
        /// 使用者名稱
        /// </summary>
        public string UserName { get; set; }
        /// <summary>
        /// 請求Url
        /// </summary>
        public string Url { get; set; }
    }
}

　　PolicyHandler 這個類繼承了微軟提供的型別AuthorizationHandler<PolicyRequirement>，泛型是我們上一步剛定義的型別。

　　在這個類裡面，我們實現了抽象方法 Task HandleRequirementAsync(AuthorizationHandlerContext context, PolicyRequirement requirement)，這個方法裡面明確瞭如何具體地校驗使用者是否有API許可權，並且根據校驗結果控制應該跳轉到提示API，還是繼續執行有許可權的API。

　　這裡的校驗邏輯比較簡單，Demo級別的，但是提供了校驗的入口，具體業務場景根據需求進行適當替換即可。

using Microsoft.AspNetCore.Authorization;
using System.Linq;
using System.Security.Claims;
using System.Threading.Tasks;

namespace Demo.Jwt.AuthManagement
{
    public class PolicyHandler : AuthorizationHandler<PolicyRequirement>
    {
        protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, PolicyRequirement requirement)
        {
            //賦值使用者許可權
            var userPermissions = requirement.UserPermissions;
            //從AuthorizationHandlerContext轉成HttpContext，以便取出表求資訊
            var httpContext = (context.Resource as Microsoft.AspNetCore.Mvc.Filters.AuthorizationFilterContext).HttpContext;
            //請求Url
            var questUrl = httpContext.Request.Path.Value.ToUpperInvariant();
            //是否經過驗證
            var isAuthenticated = httpContext.User.Identity.IsAuthenticated;
            if (isAuthenticated)
            {
                if (userPermissions.GroupBy(g => g.Url).Any(w => w.Key.ToUpperInvariant() == questUrl))
                {
                    //使用者名稱
                    var userName = httpContext.User.Claims.SingleOrDefault(s => s.Type == ClaimTypes.NameIdentifier).Value;
                    if (userPermissions.Any(w => w.UserName == userName && w.Url.ToUpperInvariant() == questUrl))
                    {
                        context.Succeed(requirement);
                    }
                    else
                    {
                        //無許可權跳轉到拒絕頁面
                        httpContext.Response.Redirect(requirement.DeniedAction);
                    }
                }
                else
                {
                    context.Succeed(requirement);
                }
            }
            return Task.CompletedTask;
        }
    }
}

　　然後我們改造一下模擬資料的API，新增一個 api/value3 不同的是，這個action我們添加了一個帶有策略名稱的許可權特性標籤：[Authorize("Permission")] 通過這個特性標籤制定了這個action 會走我們自定義的策略方法。我們在返回值裡面提示了“這個介面只有管理員才能訪問到”，並且返回了登陸使用者的使用者名稱和角色資訊。

[HttpGet]
[Route("api/value3")]
[Authorize("Permission")]
public ActionResult<IEnumerable<string>> Get3()
{
    //這是獲取自定義引數的方法
    var auth = HttpContext.AuthenticateAsync().Result.Principal.Claims;
    var userName = auth.FirstOrDefault(t => t.Type.Equals(ClaimTypes.NameIdentifier))?.Value;
    var role = auth.FirstOrDefault(t => t.Type.Equals("Role"))?.Value;
    return new string[] { "這個介面有管理員許可權才可以訪問", $"userName={userName}",$"Role={role}" };
}

　　上文中獲取token的方法我們也微微進行了調整，對不同的登陸使用者返回不同的角色名，讓演示更加直觀一些，因為改動較小，這裡不貼上程式碼，有想看詳情的請下載程式碼檢視。

　　然後我們改造一下Startup，主要改造的地方是添加了策略模式的配置

services.AddAuthorization(options =>
{
    options.AddPolicy("Permission", policy => policy.Requirements.Add(new PolicyRequirement()));
})

　　還有添加了策略模式控制類的依賴注入

//注入授權Handler
services.AddSingleton<IAuthorizationHandler, PolicyHandler>();

　　下面是完整的Startup.cs程式碼

using Demo.Jwt.AuthManagement;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.IdentityModel.Tokens;
using System;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace Demo.Jwt
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            //新增策略鑑權模式
            services.AddAuthorization(options =>
            {
                options.AddPolicy("Permission", policy => policy.Requirements.Add(new PolicyRequirement()));
            })
            .AddAuthentication(s =>
            {
                //新增JWT Scheme
                s.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                s.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
                s.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            })
            //新增jwt驗證：
            .AddJwtBearer(options =>
            {
                options.TokenValidationParameters = new TokenValidationParameters
                {
                    ValidateLifetime = true,//是否驗證失效時間
                    ClockSkew = TimeSpan.FromSeconds(30),

                    ValidateAudience = true,//是否驗證Audience
                    //ValidAudience = Const.GetValidudience(),//Audience
                    //這裡採用動態驗證的方式，在重新登陸時，重新整理token，舊token就強制失效了
                    AudienceValidator = (m, n, z) =>
                    {
                        return m != null && m.FirstOrDefault().Equals(Const.ValidAudience);
                    },
                    ValidateIssuer = true,//是否驗證Issuer
                    ValidIssuer = Const.Domain,//Issuer，這兩項和前面簽發jwt的設定一致

                    ValidateIssuerSigningKey = true,//是否驗證SecurityKey
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Const.SecurityKey))//拿到SecurityKey
                };
                options.Events = new JwtBearerEvents
                {
                    OnAuthenticationFailed = context =>
                    {
                        //Token expired
                        if (context.Exception.GetType() == typeof(SecurityTokenExpiredException))
                        {
                            context.Response.Headers.Add("Token-Expired", "true");
                        }
                        return Task.CompletedTask;
                    }
                };
            });

            //注入授權Handler
            services.AddSingleton<IAuthorizationHandler, PolicyHandler>();

            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
        }

        // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            ///新增jwt驗證
            app.UseAuthentication();

            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseMvc(routes =>
            {
                routes.MapRoute(
                    name: "default",
                        template: "{controller=Home}/{action=Index}/{id?}");
            });
        }
    }
}

　　我們完成了這些工作以後，我們明確我們的目標：

api/value1 介面我們不登陸就可以直接進行訪問
api/value2 介面只有登陸使用者可以訪問，不登入的使用者是沒有許可權的
api/value3 介面只有admin賬號登陸（程式碼裡寫死的賬號admin，也只為admin配置了許可權）才可以訪問，普通使用者是不能訪問的

　　明確了上面的幾個目標後，下面我們進行測試，依然是執行起來我們的專案：

　　1.api/value1 介面我們不登陸就可以直接進行訪問

　　我們沒有登陸便可以訪問到api/value1介面

　　2.api/value2 介面只有登陸使用者可以訪問，不登入的使用者是沒有許可權的

　　2.1. 我們先直接訪問api/value2介面

　　返回了狀態碼：401 無許可權

　　2.2. 那麼我們呼叫登陸介面獲取token

　　2.3. 成功返回了token，我們拿該token去訪問 api/value2 介面

　　可以看到，我們成功拿到了資料，足以證明，api/value2 介面是需要登陸許可權的

　　3. 那麼，我們用這個token去訪問 api/value3 又會怎樣呢？

　　返回了403，訪問錯誤。這個403是怎麼來的呢？

　　我們上文說過的PolicyHandler.cs檔案中如果校驗介面沒有許可權呢，我們會走下面這段邏輯：

//無許可權跳轉到拒絕頁面
httpContext.Response.Redirect(requirement.DeniedAction);

　　requirement.DeniedAction是我們PolicyRequirement.cs檔案中配置死的地址："/api/nopermission"

　　這個地址返回的就是403 Forbid，當然這裡可以根據需要修改返回內容，不再贅述。

　　4. 我們換一個admin賬號重新登陸，然後訪問 api/value3 介面

　　4.1 首先我們呼叫獲取token介面進行token獲取

　　4.2 我們拿到一個新的token，然後用這個新的token去訪問剛才沒許可權的介面

　　成功地獲取到了結果，說明我們的配置策略生效了，只有admin賬號才有許可權獲取到這個介面。

　　上面就是我們完整的策略模式的實現方案，完整的程式碼可以在github地址中進行下載或clone。

【二、Token的使用策略】

　　1.token過期了怎麼辦?

　　關於token過期這個話題呢，有很多應用場景，對應不同的處理方式。

　　比如：token過期可以提示使用者重新登陸，常見的有登陸一段時間後要重新登陸校驗密碼；

　　比如：token過期可以使用其他手段進行“偷偷”重新整理，使用者感覺不到，但是token已經是新的了；

　　2.如何自動重新整理token

　　那麼token偷偷重新整理有什麼實現方式呢？

　　比如：約定好失效的時間，前端在失效前進行重新呼叫登陸介面進行獲取；

　　比如：使用SingleR，保持前後端通訊也可以一定時間輪詢重新整理token；

　　比如：後端執行策略，定時任務重新整理token，如果持續請求介面，就可以拿到最新的token進行“續命”，如果長時間不訪問任意介面，那麼token也就失效了；

　　3.如何強制token失效？

　　什麼場景要強制token失效呢？比如我們只允許賬號一個地方登陸一次，異地登陸會將賬號擠下線。這種時候我們就要將舊token失效，僅僅讓新的token生效。

　　下面我們在Demo中體現如何讓舊token強制失效。

　　3.1 在我們之前說過的Const.cs類中新增一個靜態變數（不是const，const是隻讀的），讓我們在程式中可以直接修改值。當然又是為了模擬，真實場景這個值應該持久化或者存在redis裡面，這裡我們為了程式碼簡潔易懂就不整合太多的元件了。

　　3.2 稍微修改一下我們的獲取token的action，在密碼驗證成功之後，修改靜態變數的值。

　　變數值採用賬號密碼加當前時間字串，以保證每次登陸都是不一樣的值。

//每次登陸動態重新整理
Const.ValidAudience = userName + pwd + DateTime.Now.ToString();

　　然後我們在生成token的時候，讓接收者=我們靜態變數的值，audience: Const.ValidAudience

　　完整的程式碼如下：

[AllowAnonymous]
        [HttpGet]
        [Route("api/auth")]
        public IActionResult Get(string userName, string pwd)
        {
            if (CheckAccount(userName, pwd, out string role))
            {
                //每次登陸動態重新整理
                Const.ValidAudience = userName + pwd + DateTime.Now.ToString();
                // push the user’s name into a claim, so we can identify the user later on.
                //這裡可以隨意加入自定義的引數，key可以自己隨便起
                var claims = new[]
                {
                    new Claim(JwtRegisteredClaimNames.Nbf,$"{new DateTimeOffset(DateTime.Now).ToUnixTimeSeconds()}") ,
                    new Claim (JwtRegisteredClaimNames.Exp,$"{new DateTimeOffset(DateTime.Now.AddMinutes(30)).ToUnixTimeSeconds()}"),
                    new Claim(ClaimTypes.NameIdentifier, userName),
                    new Claim("Role", role)
                };
                //sign the token using a secret key.This secret will be shared between your API and anything that needs to check that the token is legit.
                var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Const.SecurityKey));
                var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);
                //.NET Core’s JwtSecurityToken class takes on the heavy lifting and actually creates the token.
                var token = new JwtSecurityToken(
                    //頒發者
                    issuer: Const.Domain,
                    //接收者
                    audience: Const.ValidAudience,
                    //過期時間
                    expires: DateTime.Now.AddMinutes(30),
                    //簽名證書
                    signingCredentials: creds,
                    //自定義引數
                    claims: claims
                    );

                return Ok(new
                {
                    token = new JwtSecurityTokenHandler().WriteToken(token)
                });
            }
            else
            {
                return BadRequest(new { message = "username or password is incorrect." });
            }
        }

　　3.3 然後改造一下StartUp.cs

　　我們僅僅需要關心改動的地方，也就是AddJwtBearer這個驗證token的方法，我們不用原先的固定值的校驗方式，而提供一個代理方法進行執行時執行校驗

.AddJwtBearer(options =>

options.TokenValidationParameters = new TokenValidationParameters
{
    ValidateLifetime = true,//是否驗證失效時間
    ClockSkew = TimeSpan.FromSeconds(30),
    ValidateAudience = true,//是否驗證Audience
    //ValidAudience = Const.GetValidudience(),//Audience
    //這裡採用動態驗證的方式，在重新登陸時，重新整理token，舊token就強制失效了
    AudienceValidator = (m, n, z) =>
    {
        return m != null && m.FirstOrDefault().Equals(Const.ValidAudience);
    },
    ValidateIssuer = true,//是否驗證Issuer
    ValidIssuer = Const.Domain,//Issuer，這兩項和前面簽發jwt的設定一致
    ValidateIssuerSigningKey = true,//是否驗證SecurityKey
    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Const.SecurityKey))//拿到SecurityKey
};

　　這裡邏輯是這樣的：因為重新登陸將原來的變數更改了，所以這裡校驗的時候也一併修改成了新的變數值，那麼舊的token當然就不匹配了，也就是舊的token被強制失效了。

　　3.4 我們實際驗證一下

　　3.4.1 首先我們用admin賬號獲取token

　　3.4.2 然後用該token訪問有許可權的 api/value3 介面

　　意料之中，我們成功訪問到了值，而且在有效期內訪問多次都是可以訪問成功的。

　　3.4.3 那麼我們用admin賬號重新獲取token

　　拿到一個新的token

　　3.4.4 我們不更換token，再用舊的token呼叫一下 api/value3

　　返回狀態碼401了，說明沒有許可權了

　　同時headers裡面有錯誤描述時接收人蔘數錯誤，說明一切盡在我們的預期之中。

　　3.4.5 那麼我們使用我們第二次登陸用的新的token進行訪問api/value3

　　又成功地獲取到了資料，表明我們新的token佔有了當前寶座，老國王已經被擠下臺了！

　　4. 如何應用到叢集模式

　　這個問題其實在測試過Demo，然後再結合我們日常應用的話，答案很容易得到。以下幾種參考：

我們這個Demo其實相關引數都是從Const.cs常量檔案中獲取的，文中也說了，實際應用中應從資料庫或redis中獲取。這些訊號都表明了實際應用中很多都是走的配置中心或者是資料庫，這些中介軟體本就天然支援叢集模式，因此部署多套服務和部署一套服務是一樣的，一個介面能通過的驗證，多個介面也同樣能通過驗證。
第二種場景在大專案中或者微服務場景中比較常見，那就是微服務閘道器，我們完全可以將JWT整合在微服務閘道器上，而不用關心具體的下游服務。只要閘道器能通過認證就可以訪問到下游的服務節點。

【結尾】

　　到這裡，我們在上一篇中“JWT的簡介以及asp.net core 整合JWT”中遺留的問題已經全部解釋完畢了，當然了，如果有新的問題也非常歡迎各路朋友在評論區留下您寶貴的意見。

　　上一篇傳送門：https://www.cnblogs.com/7tiny/p/11012035.html

　　如果想要完整專案原始碼的，可以參考地址：https://github.com/sevenTiny/Demo.Jwt

　　如果有幸能幫助到你，高擡貴手點個star吧~

asp.net core 整合JWT（二）token的強制失效，基於策略模式細化api許可權

【前言】

【一、如何結合JWT認證對使用者進行API授權】

1.api/value1 介面我們不登陸就可以直接進行訪問

2.api/value2 介面只有登陸使用者可以訪問，不登入的使用者是沒有許可權的

3. 那麼，我們用這個token去訪問 api/value3 又會怎樣呢？

4. 我們換一個admin賬號重新登陸，然後訪問 api/value3 介面

【二、Token的使用策略】

1.token過期了怎麼辦?

2.如何自動重新整理token

3.如何強制token失效？

4. 如何應用到叢集模式

【結尾】

asp.net core 整合JWT（二）token的強制失效，基於策略模式細化api許可權

從零開始構建一個的asp.net Core 項目（二）

asp.net core 使用 signalR（二）

ASP.NET Core Authentication系列（二）實現認證、登入和登出

.net core整合JWT（基礎）

在ASP.NET Core中用HttpClient（二）——傳送POST, PUT和DELETE請求

.net core 實踐筆記（二）--EF連接Azure Sql

.net core 實踐筆記（二）--EF連線Azure Sql

ASP.NET Core多語言（轉載）

ASP.NET Core快速入門（Jessetalk）（第1章：介紹與引入）（持續更新）

ASP.NET MVC 開發隨筆（二）

asp.net mvc3 資料驗證（二）——錯誤資訊的自定義及其本地化

這應該是目前最快速有效的ASP NET Core學習方式（視訊）

ASP.NET之旅--淺談Asp.net的執行機制（二）

.Net Core實戰教程（二）：設置Kestrel的IP與端口的幾種方法

這應該是目前最快速有效的ASP.NET Core學習方式（視訊）

ASP.NET Core 系列目錄（轉）

asp.net core 整合JWT

（15）ASP.NET Core Web主機（IWebHostBuilder）

（16）ASP.NET Core 通用主機（HostBuilder）

asp.net core 整合JWT（二）token的強制失效，基於策略模式細化api許可權

【前言】

【一、如何結合JWT認證對使用者進行API授權】

1.api/value1 介面我們不登陸就可以直接進行訪問

2.api/value2 介面只有登陸使用者可以訪問，不登入的使用者是沒有許可權的

3. 那麼，我們用這個token去訪問 api/value3 又會怎樣呢？

4. 我們換一個admin賬號重新登陸，然後訪問 api/value3 介面

【二、Token的使用策略】

1.token過期了怎麼辦?

2.如何自動重新整理token

3.如何強制token失效？

4. 如何應用到叢集模式

【結尾】

相關推薦

　　1.api/value1 介面我們不登陸就可以直接進行訪問

　　2.api/value2 介面只有登陸使用者可以訪問，不登入的使用者是沒有許可權的

　　3. 那麼，我們用這個token去訪問 api/value3 又會怎樣呢？

　　4. 我們換一個admin賬號重新登陸，然後訪問 api/value3 介面

　　1.token過期了怎麼辦?

　　2.如何自動重新整理token

　　3.如何強制token失效？

　　4. 如何應用到叢集模式