" 【.NET Core項目實戰 統一認證平臺】開篇及目錄索引 " 上一篇我介紹了 的生成驗證及流程內容,相信大家也對 非常熟悉了,今天將從一個小眾的需求出發,介紹如何強制令牌過期的思路和實現過程。 .netcore項目實戰交流群(637326624),有興趣的朋友可以在群里交流討論。 一、前言 眾 ...
【.NET Core項目實戰-統一認證平臺】開篇及目錄索引
上一篇我介紹了
JWT
的生成驗證及流程內容,相信大家也對JWT
非常熟悉了,今天將從一個小眾的需求出發,介紹如何強制令牌過期的思路和實現過程。.netcore項目實戰交流群(637326624),有興趣的朋友可以在群里交流討論。
一、前言
眾所周知,IdentityServer4
預設支持兩種類型的 Token,一種是 Reference Token
,一種是 JWT Token
。前者的特點是 Token
的有效與否是由 Token
頒發服務集中化控制的,頒發的時候會持久化 Token
,然後每次驗證都需要將 Token
傳遞到頒發服務進行驗證,是一種中心化的驗證方式。JWT Token
的特點與前者相反,每個資源服務不需要每次都要都去頒發服務進行驗證 Token
的有效性驗證,上一篇也介紹了,該 Token
由三部分組成,其中最後一部分包含了一個簽名,是在頒發的時候採用非對稱加密演算法進行數據的簽名,保證了 Token
的不可篡改性,校驗時與頒發服務的交互,僅僅是獲取公鑰用於驗證簽名,且該公鑰獲取以後可以自己緩存,持續使用,不用再去交互獲得,除非數字證書發生變化。
二、Reference Token的用法
上一篇已經介紹了JWT Token
的整個生成過程,為了演示強制過期策略,這裡需要瞭解下Reference Token
是如何生成和存儲的,這樣可以幫助掌握IdentityServer4
所有的工作方式。
1、新增測試客戶端
由於我們已有資料庫,為了方便演示,我直接使用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'
--2、添加客戶端密鑰,密碼為(secreta) sha256
INSERT INTO ClientSecrets VALUES(23,'',null,'SharedSecret','2tytAAysa0zaDuNthsfLdjeEtZSyWw8WzbzM8pfTGNI=');
--3、增加客戶端授權許可權
INSERT INTO ClientGrantTypes VALUES(23,'client_credentials');
--4、增加客戶端能夠訪問scope
INSERT INTO ClientScopes VALUES(23,'mpc_gateway');
這裡添加了認證類型為Reference Token
客戶端為clientref
,並分配了客戶端授權和能訪問的scope,然後我們使用PostMan
測試下客戶端。
如上圖所示,可以正確的返回access_token
,且有標記的過期時間。
2、如何校驗token的有效性?
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
,然後進行校驗,結果如下圖所示。
可以得到預期結果。
三、強制過期的方式
1、簡易黑名單模式
在每次有Token
請求時,資源伺服器對請求的Token進行校驗,在校驗有效性校驗通過後,再在黑名單里校驗是否強制過期,如果存在黑名單里,返回授權過期提醒。資源伺服器提示Token
無效。註意由於每次請求都會校驗Token的有效性,因此黑名單最好使用比如Redis
緩存進行保存。
實現方式:
此種方式只需要重寫Token驗證方式即可實現。
優點
實現簡單,改造少。
缺點
1、不好維護黑名單列表
2、對認證伺服器請求壓力太大
2、策略黑名單模式
建議黑名單有一個最大的弊端是每次請求都需要對伺服器進行訪問,會對伺服器端造成很大的請求壓力,而實際請求數據中99%都是正常訪問,對於可疑的請求我們才需要進行伺服器端驗證,所以我們要在客戶端校驗出可疑的請求再提交到伺服器校驗,可以在Claim里增加客戶端IP信息,當請求的客戶端IP和Token里的客戶端IP不一致時,我們標記為可疑Token,這時候再發起Token校驗請求,校驗Token是否過期,後續流程和簡易黑名單模式完成一致。
實現方式
此種方式需要增加Token生成的Claim,增加自定義的ip的Claim欄位,然後再重寫驗證方式。
優點
可以有效的減少伺服器端壓力
缺點
不好維護黑名單列表
3、強化白名單模式
通常不管使用客戶端、密碼、混合模式等方式登錄,都可以獲取到有效的Token,這樣會造成簽發的不同Token可以重覆使用,且很難把這些歷史的Token手工加入黑名單里,防止被其他人利用。那如何保證一個客戶端同一時間點只有一個有效Token呢?我們只需要把最新的Token加入白名單,然後驗證時直接驗證白名單,未命中白名單校驗失敗。校驗時使用策略黑名單模式,滿足條件再請求驗證,為了減輕認證伺服器的壓力,可以根據需求在本地緩存一定時間(比如10分鐘)。
實現方式
此種方式需要重寫Token生成方式,重寫自定義驗證方式。
優點
伺服器端請求不頻繁,驗證塊,自動管理黑名單。
缺點
實現起來比較改造的東西較多
綜上分析後,為了網關的功能全面和性能,建議採用強化白名單模式來實現強制過期策略。
四、強制過期的實現
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策略發起校驗等,這裡就比較簡單了,就不一一實現了,如果在使用中遇到問題可以聯繫我。
五、總結與思考
本篇我介紹了IdentityServer4
里Token認證的介面及實現過程,然後介紹強制有效Token過期的實現思路,並使用了白名單模式實現了強制過期策略。但是這種實現方式不一定是非常合理的實現方式,也希望有更好實現的朋友批評指正並告知本人。
實際生產環境中如果使用JWT Token
,建議還是使用Token頒發的過期策略來強制Token過期,比如對安全要求較高的設置幾分鐘或者幾十分鐘過期等,避免Token泄漏造成的安全問題。
至於單機登錄,其實只要開啟強制過期策略就基本實現了,因為只要最新的登錄會自動把之前的登錄Token強制失效,如果再配合signalr
強制下線即可。
項目源代碼地址:https://github.com/jinyancao/Czar.IdentityServer4