深入了解身份认证和授权机制，看看API请求到底发生了什么？
跳跃的键盘手 人气:0前段时间写了一篇基于.NetCore环境使用IdentityServer4为API接口鉴权的文章，更多的是从快速上手的角度描述了IdentityServer4的使用。后续使用过程中，自己有了一些其他想法和困惑，于是便进行一番探索，在这里记录分享一下。
本文主要和大家认识下Client获取到Token之后，请求API资源时具体是如何实现身份认证和资源授权的。
解决以下困惑：
1.Client请求时携带的Token具体是如何实现认证的？
2.Token中自包含的信息（IdentityServer4使用的Token实际是JWT类型）是如何传递到API资源服务器中的？
3.为什么被标识了【Authorize】特性或者被全局设置过滤器AuthorizeFilter的资源就能实现鉴权，系统是如何实现的？
准备环境：
1.IdentityServer4授权服务
2.API资源服务
3.Postman模拟发起http请求的客户端
由于之前文章讲解过如何实现IdentityServer鉴权，本文就不再赘述如何搭建项目环境，感兴趣的同学可以看下之前的文章IdentityServer4实现.Net Core API接口权限认证
关注下代码核心部分：
API资源服务中注册认证服务
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();//注册身份认证服务
services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = Configuration.GetValue<string>("Authority:Url");//你要请求验证的identity服务端的地址
options.RequireHttpsMetadata = false;
options.ApiName = "api";//你选择的验证方式。 对应的GetClients中定义的作用域
});
}
1）AddAuthentication内部注册了我们最主要的三个对象AuthenticationService, AuthenticationHandlerProvider, AuthenticationSchemeProvider
2）AddIdentityServerAuthentication（或者AddCookie、AddJwtBearer）指定Scheme类型和需要验证的参数
API资源服务中添加身份认证、授权管道中间件：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseHsts();
}
app.UseRouting();
//添加权限认证中间件
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
1） app.UseAuthentication() 添加了中间件AuthenticationMiddleware
2） app.UseAuthorization() 添加了中间件AuthorizationMiddleware
.NetCore中Http请求过程：
Http请求 > 其它中间件 > 路由中间件（这里就拿到终点路由了） > 身份验证中间件 > 授权中间件 > MVC中间件 > Controller > Action
深入认识下身份认证和授权两个过程：
发起API接口请求(header中参数Authorization携带token)
Http请求先经过身份认证AuthenticationMiddleware中间件请求管道，然后经过授权AuthorizationMiddleware中间件请求管道。
1.身份认证 即token认证
借用一张大佬的图，给小伙伴们解解渴。
结合上面这张图，我们来详细看看这其中到底是如何实现的？
API服务一共向IdentityServer4授权服务请求了两次
1）第一次请求IdentityServer4授权服务，指向终点路由DiscoveryEndPoint（/.well-known/openid-configuration）,获取IdentityServer授权服务配置信息
{
"issuer": "http://localhost:7000",
"jwks_uri": "http://localhost:7000/.well-known/openid-configuration/jwks",
"authorization_endpoint": "http://localhost:7000/connect/authorize",
"token_endpoint": "http://localhost:7000/connect/token",
"userinfo_endpoint": "http://localhost:7000/connect/userinfo",
"end_session_endpoint": "http://localhost:7000/connect/endsession",
"check_session_iframe": "http://localhost:7000/connect/checksession",
"revocation_endpoint": "http://localhost:7000/connect/revocation",
"introspection_endpoint": "http://localhost:7000/connect/introspect",
"device_authorization_endpoint": "http://localhost:7000/connect/deviceauthorization",
"frontchannel_logout_supported": true,
"frontchannel_logout_session_supported": true,
"backchannel_logout_supported": true,
"backchannel_logout_session_supported": true,
"scopes_supported": ["openid", "profile", "api1", "api2", "offline_access"],
"claims_supported": ["sub", "name", "family_name", "given_name", "middle_name", "nickname", "preferred_username", "profile", "picture", "website", "gender", "birthdate", "zoneinfo", "locale", "updated_at"],
"grant_types_supported": ["authorization_code", "client_credentials", "refresh_token", "implicit", "password", "urn:ietf:params:oauth:grant-type:device_code"],
"response_types_supported": ["code", "token", "id_token", "id_token token", "code id_token", "code token", "code id_token token"],
"response_modes_supported": ["form_post", "query", "fragment"],
"token_endpoint_auth_methods_supported": ["client_secret_basic", "client_secret_post"],
"id_token_signing_alg_values_supported": ["RS256"],
"subject_types_supported": ["public"],
"code_challenge_methods_supported": ["plain", "S256"],
"request_parameter_supported": true
}
2）第二次请求IdentityServer授权服务，指向终点路由DiscoveryKeyEndPoint（/.well-known/openid-configuration/jwks）,获取IdentityServer授权服务中jwks信息(kid和公钥)。kid唯一标识一个token
{
"keys": [{
"kty": "RSA",
"use": "sig",
"kid": "B22FBEC9ACABEF0F9DFFD4DFD370D445",
"e": "AQAB",
"n": "45H1Uw6EFjClHK-LQpUptFWX0PrpQEqy-YVNljj8cYmrPK3Zjqgk6XyW8tSCEYpClJJnuvSrae9yyrYdCghChDkNFVU1H8PT3Y_aSYDrULfqKO39HdqF7pZoxayZpyseAHE9tYQjtAw7E5IBpnXd_02Wz4K2mpt8Z2s5hPwos2_ze1Msvdl7iPmPfNdncl2tvERkr9pM5vRvbzxA9N1aTF58W03oq6bZoIA2w28FhTedcCxpPb3euT926ribOKCtsxCKCqFiIZYc0ovAiSV-kuLhaywd9e5KA18sOObg0McOBGmCJsQ6PTkkpn_yqvb3Eu9jhgxCO-_8K3Ml_dFIXQ",
"alg": "RS256"
}]
}
3）API服务根据kid本地缓存token资源，当同一个kid再次发起请求时，不再向授权服务identityserver请求。
4）通过授权服务拿到token的kid和公钥之后，由API资源服务验证token，我们看下AuthenticationMiddleware中间件做了什么
public IAuthenticationSchemeProvider Schemes { get; set; }
public async Task Invoke(HttpContext context)
{
context.Features.Set<IAuthenticationFeature>((IAuthenticationFeature) new AuthenticationFeature()
{
OriginalPath = context.Request.Path,
OriginalPathBase = context.Request.PathBase
});
IAuthenticationHandlerProvider handlers = context.RequestServices.GetRequiredService<IAuthenticationHandlerProvider>();
foreach (AuthenticationScheme authenticationScheme in await this.Schemes.GetRequestHandlerSchemesAsync())
{
IAuthenticationRequestHandler handlerAsync = await handlers.GetHandlerAsync(context, authenticationScheme.Name) as IAuthenticationRequestHandler;
bool flag = handlerAsync != null;
if (flag)
flag = await handlerAsync.HandleRequestAsync();
if (flag)
return;
}
AuthenticationScheme authenticateSchemeAsync = await this.Schemes.GetDefaultAuthenticateSchemeAsync();
if (authenticateSchemeAsync != null)
{
//实际核心认证处理的地方
AuthenticateResult authenticateResult = await context.AuthenticateAsync(authenticateSchemeAsync.Name);
if (authenticateResult?.Principal != null)
context.User = authenticateResult.Principal;
}
await this._next(context);
}
在认证过程中， Schemes.GetRequestHandlerSchemesAsync() 通过AuthenticationSchemeProvider获取Scheme列表，
handlers.GetHandlerAsync 通过IAuthenticationHandlerProvider 获取scheme对应的handler并存在handlerMap缓存字典里，
context.AuthenticateAsync 通过Scheme和AuthenticationHandlerProvider获取实际处理请求的AuthenticationHandler（如JwtBearerHandler），最后通过实际的AuthenticationHandler的AuthenticateAsync方法进行认证流程。
解析认证后会将token（JWT格式：header+payload+签名）中的Payload主体部分赋值到当前请求上下文context.User中。
然后我们便可以在API资源服务器中通过ClaimsPrincipal—User获取解析后的相关信息。
public ActionResult<IEnumerable<string>> Get()
{
var claims = User.Claims.Select(x => new { x.Type, x.Value }).ToList();
var claimSub = User.FindFirstValue("sub");
var claimId = User.FindFirstValue("id");
return new string[] { "Hello,WebAPI" };
}
2.资源鉴权
通过【Authorize】特性指定Controller或Action实现鉴权
[HttpGet]
[Authorize(Roles = "admin")]
public ActionResult<IEnumerable<string>> Get()
{
return new string[] { "Hello,WebAPI" };
}
或者
通过AuthorizeFilter给Controller添加全局鉴权
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers(x => x.Filters.Add(new AuthorizeFilter()));//全局添加权限认证
//将身份验证服务添加到管道中
services.AddAuthentication("Bearer")
.AddIdentityServerAuthentication(options =>
{
options.Authority = Configuration.GetValue<string>("Authority:Url"); //你要请求验证的identity服务端的地址
options.RequireHttpsMetadata = false;
options.ApiName = "api"; //你选择的验证方式。 对应的GetClients中定义的作用域
});
}
那么.Net框架内部又是如何识别上面两种方式来实现鉴权的呢？
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseAuthorization();
}
通过 app.UseAuthorization(); 在Http请求管道中添加了授权中间件AuthorizationMiddleware。
public static IApplicationBuilder UseAuthorization(this IApplicationBuilder app)
{
if (app == null)
{
throw new ArgumentNullException(nameof(app));
}
VerifyServicesRegistered(app);
return app.UseMiddleware<AuthorizationMiddleware>();
}
AuthorizationMiddleware 中间件中，我们发现了下面这行代码：
var authorizeData = endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>() ?? Array.Empty<IAuthorizeData>();
再看IAuthorizeData，定义了授权规则信息
public interface IAuthorizeData
{
string AuthenticationSchemes { get; set; }
string Policy { get; set; }
string Roles { get; set; }
}
不难看出，正是通过 endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>() 获取了终点路由元素对应的授权规则信息。
那么又如何与AuthorizeAttribute特性和全局过滤器实现了AuthorizeFilter关联呢？继续往下看
先看AuthorizeAttribute特性
public class AuthorizeAttribute : Attribute, IAuthorizeData
{}
实际上 AuthorizeAttribute 实现了 IAuthorizeData 授权规则接口，这也就不难理解被标识了特性【Authorize】的Controller和Action是如何被发现的。
再看AuthorizeFilter过滤器，这里仅列出方法中部分代码，便于展示和理解
public class AuthorizeFilter : IAsyncAuthorizationFilter, IFilterFactory,IFilterMetadata
{
public IEnumerable<IAuthorizeData> AuthorizeData { get; }
//默认构造函数中默认创建了AuthorizeAttribute 对象
public AuthorizeFilter()
: this(authorizeData: new[] { new AuthorizeAttribute() })
{
}
//赋值AuthorizeData
public AuthorizeFilter(IEnumerable<IAuthorizeData> authorizeData)
{
if (authorizeData == null)
{
throw new ArgumentNullException(nameof(authorizeData));
}
AuthorizeData = authorizeData;
}
}
实际上 AuthorizeFilter 在默认构造函数中实例化了 AuthorizeAttribute 对象，并且完成了 IAuthorizeData 集合的赋值。
这也就能理解为什么通过 IAuthorizeData 可以获取到过滤器AuthorizeFilter 对应的终点路由元素的授权规则信息。
从本质上来说以上两种方式都是关联实现了接口 IAuthorizeData ，因此直接通过 endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>() 便可以获取到终点路由元素的授权规则信息。
我相信看了上述文章之后，最开始的3个疑惑大家应该内心都有自己的答案了。
1.client请求的时携带的Token具体是如何实现认证的？
首先API资源服务向IdentityServer认证服务请求获取token的公钥，然后API服务根据公钥解密token的加签部分，认证token是否有效。
2.Token中自包含的信息是如何传递到API资源服务器中的？
IdentityServer认证服务使用的是JWT类型的token，自包含了用户信息。当API服务认证token有效后，会在AuthenticationMiddleware中间件中对token进行解析获取token中payload部分的信息，并赋值到当前请求的context.User上下文当中。
3.为什么被标识了【Authorize】特性或者被全局设置过滤器AuthorizeFilter的资源就能实现鉴权，系统是如何实现的？
AuthorizationMiddleware授权中间件中通过 endpoint?.Metadata.GetOrderedMetadata<IAuthorizeData>() 获取终点路由元素的授权规则，实现API资源鉴权。
加载全部内容