【.NET Core項目實戰-統一認證平臺】第十三章 受權篇-如何強制有效令牌過時

時間  2019-11-05
標籤 core 項目 實戰 統一 認證 平臺 第十三 受權 如何 強制 有效 過時 简体版
原文   原文鏈接

【.NET Core項目實戰-統一認證平臺】開篇及目錄索引

上一篇我介紹了JWT的生成驗證及流程內容，相信你們也對JWT很是熟悉了，今天將從一個小衆的需求出發，介紹如何強制令牌過時的思路和實現過程。html

.netcore項目實戰交流羣（637326624），有興趣的朋友能夠在羣裏交流討論。git

1、前言

衆所周知，IdentityServer4 默認支持兩種類型的 Token，一種是 Reference Token，一種是 JWT Token 。前者的特色是 Token 的有效與否是由 Token 頒發服務集中化控制的，頒發的時候會持久化 Token，而後每次驗證都須要將 Token 傳遞到頒發服務進行驗證，是一種中心化的驗證方式。JWT Token的特色與前者相反，每一個資源服務不須要每次都要都去頒發服務進行驗證 Token 的有效性驗證，上一篇也介紹了，該 Token 由三部分組成，其中最後一部分包含了一個簽名，是在頒發的時候採用非對稱加密算法進行數據的簽名，保證了 Token 的不可篡改性，校驗時與頒發服務的交互，僅僅是獲取公鑰用於驗證簽名，且該公鑰獲取之後能夠本身緩存，持續使用，不用再去交互得到，除非數字證書發生變化。github

2、Reference Token的用法

上一篇已經介紹了JWT Token的整個生成過程，爲了演示強制過時策略，這裏須要瞭解下Reference Token是如何生成和存儲的，這樣能夠幫助掌握IdentityServer4全部的工做方式。redis

一、新增測試客戶端算法

因爲咱們已有數據庫，爲了方便演示，我直接使用SQL腳本新增。sql

--新建客戶端(AccessTokenType 0 JWT 1 Reference Token)
INSERT INTO Clients(AccessTokenType,AccessTokenLifetime,ClientId,ClientName,Enabled) VALUES(1,3600,'clientref','測試Ref客戶端',1);

-- SELECT * FROM Clients WHERE ClientId='clientref'

--二、添加客戶端密鑰,密碼爲(secreta) sha256
INSERT INTO ClientSecrets VALUES(23,'',null,'SharedSecret','2tytAAysa0zaDuNthsfLdjeEtZSyWw8WzbzM8pfTGNI=');

--三、增長客戶端受權權限
INSERT INTO ClientGrantTypes VALUES(23,'client_credentials');

--四、增長客戶端可以訪問scope
INSERT INTO ClientScopes VALUES(23,'mpc_gateway');

這裏添加了認證類型爲Reference Token客戶端爲clientref，並分配了客戶端受權和能訪問的scope，而後咱們使用PostMan測試下客戶端。數據庫

如上圖所示，能夠正確的返回access_token，且有標記的過時時間。c#

二、如何校驗token的有效性？api

IdentityServer4給已經提供了Token的校驗地址http://xxxxxx/connect/introspect，能夠經過訪問此地址來校驗Token的有效性，使用前須要瞭解傳輸的參數和校驗方式。緩存

在受權篇開始時我介紹了IdentityServer4的源碼剖析，相信都掌握了看源碼的方式，這裏就不詳細介紹了。

核心代碼爲IntrospectionEndpoint,標註出校驗的核心代碼,用到的幾個校驗方式已經註釋出來了。

private async Task<IEndpointResult> ProcessIntrospectionRequestAsync(HttpContext context)
{
    _logger.LogDebug("Starting introspection request.");

    // 校驗ApiResources信息，支持 basic 和 form兩種方式，和受權時同樣
    var apiResult = await _apiSecretValidator.ValidateAsync(context);
    if (apiResult.Resource == null)
    {
        _logger.LogError("API unauthorized to call introspection endpoint. aborting.");
        return new StatusCodeResult(HttpStatusCode.Unauthorized);
    }

    var body = await context.Request.ReadFormAsync();
    if (body == null)
    {
        _logger.LogError("Malformed request body. aborting.");
        await _events.RaiseAsync(new TokenIntrospectionFailureEvent(apiResult.Resource.Name, "Malformed request body"));

        return new StatusCodeResult(HttpStatusCode.BadRequest);
    }

    // 驗證access_token的有效性，根據
    _logger.LogTrace("Calling into introspection request validator: {type}", _requestValidator.GetType().FullName);
    var validationResult = await _requestValidator.ValidateAsync(body.AsNameValueCollection(), apiResult.Resource);
    if (validationResult.IsError)
    {
        LogFailure(validationResult.Error, apiResult.Resource.Name);
        await _events.RaiseAsync(new TokenIntrospectionFailureEvent(apiResult.Resource.Name, validationResult.Error));

        return new BadRequestResult(validationResult.Error);
    }

    // response generation
    _logger.LogTrace("Calling into introspection response generator: {type}", _responseGenerator.GetType().FullName);
    var response = await _responseGenerator.ProcessAsync(validationResult);

    // render result
    LogSuccess(validationResult.IsActive, validationResult.Api.Name);
    return new IntrospectionResult(response);
}

//校驗Token有效性核心代碼
public async Task<TokenValidationResult> ValidateAccessTokenAsync(string token, string expectedScope = null)
{
    _logger.LogTrace("Start access token validation");

    _log.ExpectedScope = expectedScope;
    _log.ValidateLifetime = true;

    TokenValidationResult result;

    if (token.Contains("."))
    {//jwt
        if (token.Length > _options.InputLengthRestrictions.Jwt)
        {
            _logger.LogError("JWT too long");

            return new TokenValidationResult
            {
                IsError = true,
                Error = OidcConstants.ProtectedResourceErrors.InvalidToken,
                ErrorDescription = "Token too long"
            };
        }

        _log.AccessTokenType = AccessTokenType.Jwt.ToString();
        result = await ValidateJwtAsync(
            token,
            string.Format(Constants.AccessTokenAudience, _context.HttpContext.GetIdentityServerIssuerUri().EnsureTrailingSlash()),
            await _keys.GetValidationKeysAsync());
    }
    else
    {//Reference token
        if (token.Length > _options.InputLengthRestrictions.TokenHandle)
        {
            _logger.LogError("token handle too long");

            return new TokenValidationResult
            {
                IsError = true,
                Error = OidcConstants.ProtectedResourceErrors.InvalidToken,
                ErrorDescription = "Token too long"
            };
        }

        _log.AccessTokenType = AccessTokenType.Reference.ToString();
        result = await ValidateReferenceAccessTokenAsync(token);
    }

    _log.Claims = result.Claims.ToClaimsDictionary();

    if (result.IsError)
    {
        return result;
    }

    // make sure client is still active (if client_id claim is present)
    var clientClaim = result.Claims.FirstOrDefault(c => c.Type == JwtClaimTypes.ClientId);
    if (clientClaim != null)
    {
        var client = await _clients.FindEnabledClientByIdAsync(clientClaim.Value);
        if (client == null)
        {
            _logger.LogError("Client deleted or disabled: {clientId}", clientClaim.Value);

            result.IsError = true;
            result.Error = OidcConstants.ProtectedResourceErrors.InvalidToken;
            result.Claims = null;

            return result;
        }
    }

    // make sure user is still active (if sub claim is present)
    var subClaim = result.Claims.FirstOrDefault(c => c.Type == JwtClaimTypes.Subject);
    if (subClaim != null)
    {
        var principal = Principal.Create("tokenvalidator", result.Claims.ToArray());

        if (result.ReferenceTokenId.IsPresent())
        {
            principal.Identities.First().AddClaim(new Claim(JwtClaimTypes.ReferenceTokenId, result.ReferenceTokenId));
        }

        var isActiveCtx = new IsActiveContext(principal, result.Client, IdentityServerConstants.ProfileIsActiveCallers.AccessTokenValidation);
        await _profile.IsActiveAsync(isActiveCtx);

        if (isActiveCtx.IsActive == false)
        {
            _logger.LogError("User marked as not active: {subject}", subClaim.Value);

            result.IsError = true;
            result.Error = OidcConstants.ProtectedResourceErrors.InvalidToken;
            result.Claims = null;

            return result;
        }
    }

    // check expected scope(s)
    if (expectedScope.IsPresent())
    {
        var scope = result.Claims.FirstOrDefault(c => c.Type == JwtClaimTypes.Scope && c.Value == expectedScope);
        if (scope == null)
        {
            LogError(string.Format("Checking for expected scope {0} failed", expectedScope));
            return Invalid(OidcConstants.ProtectedResourceErrors.InsufficientScope);
        }
    }

    _logger.LogDebug("Calling into custom token validator: {type}", _customValidator.GetType().FullName);
    var customResult = await _customValidator.ValidateAccessTokenAsync(result);

    if (customResult.IsError)
    {
        LogError("Custom validator failed: " + (customResult.Error ?? "unknown"));
        return customResult;
    }

    // add claims again after custom validation
    _log.Claims = customResult.Claims.ToClaimsDictionary();

    LogSuccess();
    return customResult;
}

有了上面的校驗代碼，就能夠很容易掌握使用的參數和校驗的方式，如今咱們就分別演示JWT Token和Reference token兩個校驗方式及返回的值。

首先須要新增資源端的受權記錄，由於校驗時須要，咱們就以mpc_gateway爲例新增受權記錄，爲了方便演示，直接使用SQL語句。

-- SELECT * FROM dbo.ApiResources WHERE Name='mpc_gateway'
INSERT INTO dbo.ApiSecrets VALUES(28,NULL,NULL,'SharedSecret','2tytAAysa0zaDuNthsfLdjeEtZSyWw8WzbzM8pfTGNI=');

首先咱們測試剛纔使用Reference token生成的access_token，參數以下圖所示。

查看是否校驗成功，從返回的狀態碼和active結果判斷，若是爲true校驗成功，若是爲false或者401校驗失敗。

咱們直接從數據庫裏刪除剛纔受權的記錄，而後再次提交查看結果,返回結果校驗失敗。

DELETE FROM PersistedGrants WHERE ClientId='clientref'

而後咱們校驗下Jwt Token，一樣的方式，先生成jwt token,而後進行校驗，結果以下圖所示。

能夠獲得預期結果。

3、強制過時的方式

一、簡易黑名單模式

在每次有Token請求時，資源服務器對請求的Token進行校驗，在校驗有效性校驗經過後，再在黑名單裏校驗是否強制過時，若是存在黑名單裏，返回受權過時提醒。資源服務器提示Token無效。注意因爲每次請求都會校驗Token的有效性，所以黑名單最好使用好比Redis緩存進行保存。

實現方式：

此種方式只須要重寫Token驗證方式便可實現。

優勢

實現簡單，改造少。

缺點

一、很差維護黑名單列表

二、對認證服務器請求壓力太大

二、策略黑名單模式

建議黑名單有一個最大的弊端是每次請求都須要對服務器進行訪問，會對服務器端形成很大的請求壓力，而實際請求數據中99%都是正常訪問，對於可疑的請求咱們才須要進行服務器端驗證，因此咱們要在客戶端校驗出可疑的請求再提交到服務器校驗，能夠在Claim裏增長客戶端IP信息，當請求的客戶端IP和Token裏的客戶端IP不一致時，咱們標記爲可疑Token，這時候再發起Token校驗請求，校驗Token是否過時，後續流程和簡易黑名單模式完成一致。

實現方式

此種方式須要增長Token生成的Claim，增長自定義的ip的Claim字段，而後再重寫驗證方式。

優勢

能夠有效的減小服務器端壓力

缺點

很差維護黑名單列表

三、強化白名單模式

一般無論使用客戶端、密碼、混合模式等方式登陸，均可以獲取到有效的Token，這樣會形成簽發的不一樣Token能夠重複使用，且很難把這些歷史的Token手工加入黑名單裏，防止被其餘人利用。那如何保證一個客戶端同一時間點只有一個有效Token呢？咱們只須要把最新的Token加入白名單，而後驗證時直接驗證白名單，未命中白名單校驗失敗。校驗時使用策略黑名單模式，知足條件再請求驗證，爲了減輕認證服務器的壓力，能夠根據需求在本地緩存必定時間（好比10分鐘）。

實現方式

此種方式須要重寫Token生成方式，重寫自定義驗證方式。

優勢

服務器端請求不頻繁，驗證塊，自動管理黑名單。

缺點

實現起來比較改造的東西較多

綜上分析後，爲了網關的功能全面和性能，建議採用強化白名單模式來實現強制過時策略。

4、強制過時的實現

1.增長白名單功能

爲了增長強制過時功能，咱們須要在配置文件裏標記是否開啓此功能，默認設置爲不開啓。

/// <summary>
/// 金焰的世界
/// 2018-12-03
/// 配置存儲信息
/// </summary>
public class DapperStoreOptions
{
    /// <summary>
    /// 是否啓用自定清理Token
    /// </summary>
    public bool EnableTokenCleanup { get; set; } = false;

    /// <summary>
    /// 清理token週期（單位秒），默認1小時
    /// </summary>
    public int TokenCleanupInterval { get; set; } = 3600;

    /// <summary>
    /// 鏈接字符串
    /// </summary>
    public string DbConnectionStrings { get; set; }

    /// <summary>
    /// 是否啓用強制過時策略,默認不開啓
    /// </summary>
    public bool EnableForceExpire { get; set; } = false;
    
    /// <summary>
    /// Redis緩存鏈接
    /// </summary>
    public List<string> RedisConnectionStrings { get; set; }
}

而後重寫Token生成策略，增長白名單功能，並使用Redis存儲白名單。白名單的存儲的Key格式爲clientId+sub+amr，詳細實現代碼以下。

using Czar.IdentityServer4.Options;
using IdentityModel;
using IdentityServer4.ResponseHandling;
using IdentityServer4.Services;
using IdentityServer4.Stores;
using IdentityServer4.Validation;
using Microsoft.AspNetCore.Authentication;
using Microsoft.Extensions.Logging;
using System;
using System.Threading.Tasks;

namespace Czar.IdentityServer4.ResponseHandling
{
    public class CzarTokenResponseGenerator : TokenResponseGenerator
    {

        private readonly DapperStoreOptions _config;
        private readonly ICache<CzarToken> _cache;
        public CzarTokenResponseGenerator(ISystemClock clock, ITokenService tokenService, IRefreshTokenService refreshTokenService, IResourceStore resources, IClientStore clients, ILogger<TokenResponseGenerator> logger, DapperStoreOptions config, ICache<CzarToken> cache) : base(clock, tokenService, refreshTokenService, resources, clients, logger)
        {
            _config = config;
            _cache = cache;
        }

        /// <summary>
        /// Processes the response.
        /// </summary>
        /// <param name="request">The request.</param>
        /// <returns></returns>
        public override async Task<TokenResponse> ProcessAsync(TokenRequestValidationResult request)
        {
            var result = new TokenResponse();
            switch (request.ValidatedRequest.GrantType)
            {
                case OidcConstants.GrantTypes.ClientCredentials:
                    result = await ProcessClientCredentialsRequestAsync(request);
                    break;
                case OidcConstants.GrantTypes.Password:
                    result = await ProcessPasswordRequestAsync(request);
                    break;
                case OidcConstants.GrantTypes.AuthorizationCode:
                    result = await ProcessAuthorizationCodeRequestAsync(request);
                    break;
                case OidcConstants.GrantTypes.RefreshToken:
                    result = await ProcessRefreshTokenRequestAsync(request);
                    break;
                default:
                    result = await ProcessExtensionGrantRequestAsync(request);
                    break;
            }
            if (_config.EnableForceExpire)
            {//增長白名單
                var token = new CzarToken();
                string key = request.ValidatedRequest.Client.ClientId;
                var _claim = request.ValidatedRequest.Subject?.FindFirst(e => e.Type == "sub");
                if (_claim != null)
                {
                    //提取amr
                    var amrval = request.ValidatedRequest.Subject.FindFirst(p => p.Type == "amr");
                    if (amrval != null)
                    {
                        key += amrval.Value;
                    }
                    key += _claim.Value;
                }
                //加入緩存
                if (!String.IsNullOrEmpty(result.AccessToken))
                {
                    token.Token = result.AccessToken;
                    await _cache.SetAsync(key, token, TimeSpan.FromSeconds(result.AccessTokenLifetime));
                }
            }
            return result;
        }
    }
}

而後定一個通用緩存方法，默認使用Redis實現。

using Czar.IdentityServer4.Options;
using IdentityServer4.Services;
using System;
using System.Threading.Tasks;

namespace Czar.IdentityServer4.Caches
{
    /// <summary>
    /// 金焰的世界
    /// 2019-01-11
    /// 使用Redis存儲緩存
    /// </summary>
    public class CzarRedisCache<T> : ICache<T>
        where T : class
    {
        private const string KeySeparator = ":";
        public CzarRedisCache(DapperStoreOptions configurationStoreOptions)
        {
            CSRedis.CSRedisClient csredis;
            if (configurationStoreOptions.RedisConnectionStrings.Count == 1)
            {
                //普通模式
                csredis = new CSRedis.CSRedisClient(configurationStoreOptions.RedisConnectionStrings[0]);
            }
            else
            {
                csredis = new CSRedis.CSRedisClient(null, configurationStoreOptions.RedisConnectionStrings.ToArray());
            }
            //初始化 RedisHelper
            RedisHelper.Initialization(csredis);
        }

        private string GetKey(string key)
        {
            return typeof(T).FullName + KeySeparator + key;
        }

        public async Task<T> GetAsync(string key)
        {
            key = GetKey(key);
            var result = await RedisHelper.GetAsync<T>(key);
            return result;
        }

        public async Task SetAsync(string key, T item, TimeSpan expiration)
        {
            key = GetKey(key);
            await RedisHelper.SetAsync(key, item, (int)expiration.TotalSeconds);
        }
    }
}

而後從新注入下ITokenResponseGenerator實現。

builder.Services.AddSingleton<ITokenResponseGenerator, CzarTokenResponseGenerator>();
builder.Services.AddTransient(typeof(ICache<>), typeof(CzarRedisCache<>));

如今咱們來測試下生成Token，查看Redis裏是否生成了白名單？

Reference Token生成

客戶端模式生成

密碼模式生成

從結果中能夠看出來，不管那種認證方式，均可以生成白名單，且只保留最新的報名單記錄。

2.改造校驗接口來適配白名單校驗

前面介紹了認證原理後，實現校驗很是簡單，只須要重寫下IIntrospectionRequestValidator接口便可，增長白名單校驗策略，詳細實現代碼以下。

using Czar.IdentityServer4.Options;
using Czar.IdentityServer4.ResponseHandling;
using IdentityServer4.Models;
using IdentityServer4.Services;
using IdentityServer4.Validation;
using Microsoft.Extensions.Logging;
using System.Collections.Specialized;
using System.Linq;
using System.Threading.Tasks;

namespace Czar.IdentityServer4.Validation
{
    /// <summary>
    /// 金焰的世界
    /// 2019-01-14
    /// Token請求校驗增長白名單校驗
    /// </summary>
    public class CzarIntrospectionRequestValidator : IIntrospectionRequestValidator
    {
        private readonly ILogger _logger;
        private readonly ITokenValidator _tokenValidator;
        private readonly DapperStoreOptions _config;
        private readonly ICache<CzarToken> _cache;
        public CzarIntrospectionRequestValidator(ITokenValidator tokenValidator, DapperStoreOptions config, ICache<CzarToken> cache, ILogger<CzarIntrospectionRequestValidator> logger)
        {
            _tokenValidator = tokenValidator;
            _config = config;
            _cache = cache;
            _logger = logger;
        }

        public async Task<IntrospectionRequestValidationResult> ValidateAsync(NameValueCollection parameters, ApiResource api)
        {
            _logger.LogDebug("Introspection request validation started.");

            // retrieve required token
            var token = parameters.Get("token");
            if (token == null)
            {
                _logger.LogError("Token is missing");

                return new IntrospectionRequestValidationResult
                {
                    IsError = true,
                    Api = api,
                    Error = "missing_token",
                    Parameters = parameters
                };
            }

            // validate token
            var tokenValidationResult = await _tokenValidator.ValidateAccessTokenAsync(token);

            // invalid or unknown token
            if (tokenValidationResult.IsError)
            {
                _logger.LogDebug("Token is invalid.");

                return new IntrospectionRequestValidationResult
                {
                    IsActive = false,
                    IsError = false,
                    Token = token,
                    Api = api,
                    Parameters = parameters
                };
            }

            _logger.LogDebug("Introspection request validation successful.");

            if (_config.EnableForceExpire)
            {//增長白名單校驗判斷
                var _key = tokenValidationResult.Claims.FirstOrDefault(t => t.Type == "client_id").Value;
                var _amr = tokenValidationResult.Claims.FirstOrDefault(t => t.Type == "amr");
                if (_amr != null)
                {
                    _key += _amr.Value;
                }
                var _sub = tokenValidationResult.Claims.FirstOrDefault(t => t.Type == "sub");
                if (_sub != null)
                {
                    _key += _sub.Value;
                }
                var _token = await _cache.GetAsync(_key);
                if (_token == null || _token.Token != token)
                {//已加入黑名單
                    _logger.LogDebug("Token已經強制失效");
                    return new IntrospectionRequestValidationResult
                    {
                        IsActive = false,
                        IsError = false,
                        Token = token,
                        Api = api,
                        Parameters = parameters
                    };
                }
            }
            // valid token
            return new IntrospectionRequestValidationResult
            {
                IsActive = true,
                IsError = false,
                Token = token,
                Claims = tokenValidationResult.Claims,
                Api = api,
                Parameters = parameters
            };
        }
    }
}

而後把接口從新注入，便可實現白名單的校驗功能。

builder.Services.AddTransient<IIntrospectionRequestValidator, CzarIntrospectionRequestValidator>();

只要幾句代碼就完成了功能校驗，如今可使用PostMan測試白名單功能。首先使用剛生成的Token測試，能夠正確的返回結果。

緊接着，我重新生成Token，而後再次請求，結果以下圖所示。

發現校驗失敗，提示Token已經失效，和咱們預期的結果徹底一致。

如今獲取的Token只有最新的是白名單，其餘的有效信息自動加入認定爲黑名單，若是想要強制token失效，只要刪除或修改Redis值便可。

有了這個認證結果，如今只須要在認證策略裏增長合理的校驗規則便可，好比5分鐘請求一次驗證或者使用ip策略發起校驗等，這裏就比較簡單了，就不一一實現了，若是在使用中遇到問題能夠聯繫我。

5、總結與思考

本篇我介紹了IdentityServer4裏Token認證的接口及實現過程，而後介紹強制有效Token過時的實現思路，並使用了白名單模式實現了強制過時策略。可是這種實現方式不必定是很是合理的實現方式，也但願有更好實現的朋友批評指正並告知本人。

實際生產環境中若是使用JWT Token，建議仍是使用Token頒發的過時策略來強制Token過時，好比對安全要求較高的設置幾分鐘或者幾十分鐘過時等，避免Token泄漏形成的安全問題。

至於單機登陸，其實只要開啓強制過時策略就基本實現了，由於只要最新的登陸會自動把以前的登陸Token強制失效，若是再配合signalr強制下線便可。

項目源代碼地址：https://github.com/jinyancao/Czar.IdentityServer4

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程