ASP.NET Core 认证与授权[1]:初识认证 (笔记)

摘要:
HttpContext和认证系统的集成在操作原理解剖[5]:认证中介绍。本系列文章将介绍ASP中的身份验证和授权。NET核心。基于声明的身份验证有两个主要特征:将身份验证和授权拆分为两个独立的服务。在ClaimsPrincipalASP。NETCore,HttpContext直接使用ClaimsPrincipal类型publicabstractclassHttpContext{publicbstractClaimsPrincipelUser{get;set;}}创建ClaimsPrinccipal非常简单,只需传入我们上面创建的用户ID:varprincipal=newClaimsPrincipal;由于HTTP是无状态的,我们通常使用cookie、请求头或请求参数来附加用户信息并通过网络传输,这涉及到序列化和安全问题。因此,还需要将主体对象包装为AuthenticationTicket对象。

原文链接:  https://www.cnblogs.com/RainingNight/p/introduce-basic-authentication-in-asp-net-core.html

在ASP.NET 4.X 中,我们最常用的是Forms认证,它既可以用于局域网环境,也可用于互联网环境,有着非常广泛的使用。但是它很难进行扩展,更无法与第三方认证集成,因此,在 ASP.NET Core 中对认证与授权进行了全新的设计,并使用基于声明的认证(claims-based authentication),以适应现代化应用的需求。在运行原理解剖[5]:Authentication中介绍了一下HttpContext与认证系统的集成,本系列文章则来详细介绍一下 ASP.NET Core 中认证与授权。

基于声明的认证有两个主要的特点:

  • 将认证与授权拆分成两个独立的服务。

  • 在需要授权的服务中,不用再去关心你是如何认证的,你用Windows认证也好,Forms认证也行,只要你出示你的 Claims就行了。

ASP.NET Core 中的用户身份

Claim

在 ASP.NET Core 中,使用Cliam类来表示用户身份中的一项信息,它由核心的TypeValue属性构成:

一个Claim可以是“用户的姓名”,“邮箱地址”,“电话”,等等,而多个Claim构成一个用户的身份,使用ClaimsIdentity类来表示:

public class ClaimsIdentity : IIdentity
{    
    public virtual IEnumerable<Claim> Claims {get;}

    public virtual string AuthenticationType => _authenticationType;
    public virtual bool IsAuthenticated => !string.IsNullOrEmpty(_authenticationType);
    public virtual string Name
    {
        get
        {
            Claim claim = FindFirst(_nameClaimType);
            if (claim != null) return claim.Value;
            return null;
        }
    }

}

如上,其Name属性用来查找Claims中,第一个Type为我们创建ClaimsIdentity时指定的NameClaimType的Claim的值,若未指定Type时则使用默认的ClaimTypes.Name。而IsAuthenticated只是判断_authenticationType是否为空,_authenticationType则对应上一章中介绍的Scheme。

// 创建一个用户身份,注意需要指定AuthenticationType,否则IsAuthenticated将为false。
var claimIdentity = new ClaimsIdentity("myAuthenticationType");
// 添加几个Claim
claimIdentity.AddClaim(new Claim(ClaimTypes.Name, "bob"));
claimIdentity.AddClaim(new Claim(ClaimTypes.Email, "bob@gmail.com"));
claimIdentity.AddClaim(new Claim(ClaimTypes.MobilePhone, "18888888888"));

如上,我们可以根据需要添加任意个的Claim,最后我们还需要再将用户身份放到ClaimsPrincipal对象中。

ClaimsPrincipal

ASP.NET Core 中,HttpContext直接使用的就是ClaimsPrincipal类型

public abstract class HttpContext
{
    public abstract ClaimsPrincipal User { get; set; }
}

ClaimsPrincipal的创建非常简单,只需传入我们上面创建的用户身份即可:

var principal = new ClaimsPrincipal(claimIdentity);

由于HTTP是无状态的,我们通常使用Cookie,请求头或请求参数等方式来附加用户的信息,在网络上进行传输,这就涉及到序列化和安全方面的问题。因此,还需要将principal对象包装成AuthenticationTicket对象。

AuthenticationTicket

我们创建完ClaimsPrincipal对象后,需要将它生成一个用户票据并颁发给用户,然后用户拿着这个票据,便可以访问受保持的资源,而在 ASP.NET Core 中,用户票据用AuthenticationTicket来表示,如在Cookie认证中,其认证后的Cookie值便是对该对象序列化后的结果,它的定义如下:

用户票据除了包含上面创建的principal对象外,还需要指定一个AuthenticationScheme (通常在授权中用来验证Scheme),并且还包含一个AuthenticationProperties对象,它主要是一些用户票据安全方面的一些配置,如过期时间,是否持久等。

var properties = new AuthenticationProperties();
var ticket = new AuthenticationTicket(principal, properties, "myScheme");
// 加密 序列化
var token = Protect(ticket);

最后,我们可以将票据(token)写入到Cookie中,或是也可以以JSON的形式返回让客户端自行保存,由于我们对票据进行了加密,可以保证在网络中安全的传输而不会被篡改。

最终身份令牌的结构大概是这样的:

claim-token

Microsoft.AspNetCore.Authentication

上面,我们介绍了身份票据的创建过程,下面就来介绍一下 ASP.NET Core 中的身份认证。

ASP.NET Core 中的认证系统具体实现在 Security 项目中,它包含 CookieJwtBearerOAuthOpenIdConnect 等:

ASP.NET Core 认证与授权[1]:初识认证 (笔记)第2张

Usage

而对于认证系统的配置,分为两步,也是我们所熟悉的注册服务和配置中间件:

首先,在DI中注册服务认证所需的服务:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultSignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddOpenIdConnect(o =>
    {
        o.ClientId = "server.hybrid";
        o.ClientSecret = "secret";
        o.Authority = "https://demo.identityserver.io/";
        o.ResponseType = OpenIdConnectResponseType.CodeIdToken;
    });
}

最后,注册认证中间件:

public void Configure(IApplicationBuilder app)
{
    app.UseAuthentication();
}

如上,我们的系统便支持了CookieJwtBearer两种认证方式

Microsoft.AspNetCore.Authentication,是所有认证实现的公共抽象类,它定义了实现认证Handler的规范,并包含一些共用的方法,如令牌加密,序列化等,AddAuthentication 便是其提供的统一的注册认证服务的扩展方法:

public static AuthenticationBuilder AddAuthentication(this IServiceCollection services)
{
    services.AddAuthenticationCore();
    services.AddDataProtection();
    services.AddWebEncoders();
    services.TryAddSingleton<ISystemClock, SystemClock>();
    return new AuthenticationBuilder(services);
}

public static AuthenticationBuilder AddAuthentication(this IServiceCollection services, Action<AuthenticationOptions> configureOptions) 
{
    var builder = services.AddAuthentication();
    services.Configure(configureOptions);
    return builder;
}

如上,它首先会调用上一章中介绍的AddAuthenticationCore方法,然后注册了DataProtectionWebEncoders两个服务。而对 AuthenticationOptions 我们之前在IAuthenticationSchemeProvider也介绍过,它用来配置Scheme。

AddScheme

在上面的 AddAuthentication 中返回的是一个AuthenticationBuilder类型,所有认证Handler的注册都是以它的扩展形式来实现的,它同时也提供了AddScheme扩展方法,使我们可以更加方便的来配置Scheme:在这里的AddScheme 扩展方法只是封装了对AuthenticationOptionsAddScheme的调用,如上面示例中的AddCookie便是调用该扩展方法来实现的。

AddRemoteScheme

看到 Remote 我们应该就可以猜到它是一种远程验证方式

UseAuthentication

在上面,注册认证中间件时,我们只需调用一个UseAuthentication扩展方法,因为它会执行我们注册的所有认证Handler:

public static IApplicationBuilder UseAuthentication(this IApplicationBuilder app)
{
    return app.UseMiddleware<AuthenticationMiddleware>();
}
public class AuthenticationMiddleware
{
    private readonly RequestDelegate _next;
    public IAuthenticationSchemeProvider Schemes { get; set; }

    public async Task Invoke(HttpContext context)
    {
        context.Features.Set<IAuthenticationFeature>(new AuthenticationFeature
        {
            OriginalPath = context.Request.Path,
            OriginalPathBase = context.Request.PathBase
        });

        var handlers = context.RequestServices.GetRequiredService<IAuthenticationHandlerProvider>();
        foreach (var scheme in await Schemes.GetRequestHandlerSchemesAsync())
        {
            var handler = await handlers.GetHandlerAsync(context, scheme.Name) as IAuthenticationRequestHandler;
            if (handler != null && await handler.HandleRequestAsync())
            {
                return;
            }
        }

        var defaultAuthenticate = await Schemes.GetDefaultAuthenticateSchemeAsync();
        if (defaultAuthenticate != null)
        {
            var result = await context.AuthenticateAsync(defaultAuthenticate.Name);
            if (result?.Principal != null)
            {
                context.User = result.Principal;
            }
        }

        await _next(context);
    }
}

很简单,但是很强大,不管我们是使用Cookie认证,还是Bearer认证,等等,都只需要这一个中间件,因为它会解析所有的Handler来执行。

不过,在这里,这会先判断是否具体实现了IAuthenticationRequestHandler的Hander,优先来执行,这个是什么鬼?

查了一下,发现IAuthenticationRequestHandler是在HttpAbstractions中定义的,只是在运行原理解剖[5]:Authentication中没有介绍到它:

public interface IAuthenticationRequestHandler : IAuthenticationHandler
{
    Task<bool> HandleRequestAsync();
}

它多了一个HandleRequestAsync方法,那么它存在的意义是什么呢?其实在Cookie认证中并没有用到它,它通常在远程认证(如:OAuth, OIDC等)中使用,下文再来介绍。

继续分析上面代码,通过调用Schemes.GetDefaultAuthenticateSchemeAsync来获取到认证的Scheme,也就是上文提到的问题,我们必须指定默认的Scheme。

最后,调用AuthenticateAsync方法进行认证,认证成功后,为HttpContext.User赋值,至于如何解析身份令牌生成ClaimsPrincipal对象,则交给相应的Handler来处理。

认证Handler

上文中多次提到认证Handler,它由统一的AuthenticationMiddleware来调用,负责具体的认证实现,并分为本地认证与远程认证两种方式。

在本地验证中,身份令牌的发放与认证通常是由同一个服务器来完成,这也是我们比较熟悉的场景,对于Cookie, JwtBearer等认证来说,都属于是本地验证。而当我们使用OAuth, OIDC等验证方式时,身份令牌的发放则是由独立的服务或是第三方(QQ, Weibo 等)认证来提供,此时在我们的应用程序中获取身份令牌时需要请求远程服务器,因此称之为远程验证。

AuthenticationHandler

AuthenticationHandler是所有认证Handler的抽象基类,对于本地认证直接实现该类即可,定义如下:

public abstract class AuthenticationHandler<TOptions> : IAuthenticationHandler where TOptions : AuthenticationSchemeOptions, new()
{
    ...

    public async Task InitializeAsync(AuthenticationScheme scheme, HttpContext context)
    {
        ...

        await InitializeEventsAsync();
        await InitializeHandlerAsync();
    }

    protected virtual async Task InitializeEventsAsync() { }
    protected virtual Task<object> CreateEventsAsync() => Task.FromResult(new object());
    protected virtual Task InitializeHandlerAsync() => Task.CompletedTask;

    public async Task<AuthenticateResult> AuthenticateAsync()
    {
        var result = await HandleAuthenticateOnceAsync();

        ...
    }

    protected Task<AuthenticateResult> HandleAuthenticateOnceAsync()
    {
        if (_authenticateTask == null)
        {
            _authenticateTask = HandleAuthenticateAsync();
        }
        return _authenticateTask;
    }

    protected abstract Task<AuthenticateResult> HandleAuthenticateAsync();


    protected virtual Task HandleForbiddenAsync(AuthenticationProperties properties)
    {
        Response.StatusCode = 403;
        return Task.CompletedTask;
    }

    protected virtual Task HandleChallengeAsync(AuthenticationProperties properties)
    {
        Response.StatusCode = 401;
        return Task.CompletedTask;
    }

    ...
}

如上,它定义一个抽象方法HandleAuthenticateAsync,并使用HandleAuthenticateOnceAsync方法来保证其在每次认证只执行一次。而HandleAuthenticateAsync是认证的核心,交给具体的认证Handler负责实现。而对于 ChallengeAsync, ForbidAsync 等方法也提供了默认的实现。

而对于HandleAuthenticateAsync的实现,大致的逻辑就是从请求中获取上面发放的身份令牌,然后解析成AuthenticationTicket,并经过一系列的验证,最终返回ClaimsPrincipal对象。

RemoteAuthenticationHandler

RemoteAuthenticationHandler 便是所有远程认证的抽象基类了,它继承自AuthenticationHandler,并实现了IAuthenticationRequestHandler接口:

在上面介绍的AuthenticationMiddleware中,提到它会先执行实现了IAuthenticationRequestHandler 接口的Handler(远程认证),之后(若未完成认证)再执行本地认证Handler。

RemoteAuthenticationHandler中核心的认证逻辑便是 HandleRequestAsync 方法,它主要包含2个步骤:

  1. 首先执行一个抽象方法HandleRemoteAuthenticateAsync,由具体的Handler来实现,该方法返回的HandleRequestResult对象包含验证的结果(跳过,失败,成功等),在成功时会包含一个ticket对象。

  2. 若上一步验证成功,则根据返回的ticket,获取到ClaimsPrincipal对象,并调用其它认证Handler的Context.SignInAsync方法。

也就是说,远程Hander会在用户未登录时,指引用户跳转到认证服务器,登录成功后,解析认证服务器传回的凭证,最终依赖于本地Handler来保存身份令牌。当用户再次访问则无需经过远程Handler,直接交给本地Handler来处理。

由此也可以知道,远程认证中本身并不具备SignIn的能力,所以必须通过指定其它SignInScheme交给本地认证来完成 SignIn

对于其父类的HandleAuthenticateAsync抽象方法则定义了一个默认实现:“直接转交给本地验证来处理”。当我们需要定义自己的远程认证方式时,通常只需实现 HandleRemoteAuthenticateAsync 即可,而不用再去处理 HandleAuthenticateAsync 。

总结

基于声明的认证并不是微软所特有的,它在国外被广泛的使用,如微软的ADFS,Google,Facebook,Twitter等等。在基于声明的认证中,对认证和授权进行了明确的区分,认证用来颁发一个用户的身份标识,其包含这个用户的基本信息,而对于这个身份的颁发则由我们信任的第三方机构来(STS)颁发(当然,你也可以自己来颁发)。而授权,则是通过获取身份标识中的信息,来判断该用户能做什么,不能做什么。

本文对 ASP.NET Core 中认证系统的整个流程做了一个简要的介绍,可能会比较苦涩难懂,不过没关系,大致有个印象就好,下一章则详细介绍一下最常用的本地认证方式:Cookie认证,后续也会详细介绍 OIDC 的用法与实现,到时再回头来看本文或许会豁然开朗。

免责声明:文章转载自《ASP.NET Core 认证与授权[1]:初识认证 (笔记)》仅用于学习参考。如对内容有疑问,请及时联系本站处理。

上篇Web开发学习之路--Eclipse+Tomcat+mysql之初体验QModelIndex/Role/Model介紹下篇

宿迁高防,2C2G15M,22元/月;香港BGP,2C5G5M,25元/月 雨云优惠码:MjYwNzM=

相关文章

Android程序版本更新--通知栏更新下载安装

Android应用检查版本更新后,在通知栏下载,更新下载进度,下载完成自动安装,效果图如下: 检查当前版本号 AndroidManifest文件中的versionCode用来标识版本,在服务器放一个新版本的apk,versioncode大于当前版本,下面代码用来获取versioncode的值 PackageInfo packageInfo = conte...

android中实现本地广播

上一篇文章实现了自定义广播:android中实现自定义广播 自定义广播允许被其他应用使用,有些情况下只允许广播在本应用范围内使用,可以用本地广播的方式实现 下面是实现的代码部分,MainActivity.java: packagecom.example.chenrui.app1; importandroid.content.BroadcastReceiv...

Android 线程操作之AsyncTask

AsyncTask和Handler对比1 ) AsyncTask实现的原理,和适用的优缺点AsyncTask,是android提供的轻量级的异步类,可以直接继承AsyncTask,在类中实现异步操作,并提供接口反馈当前异步执行的程度(可以通过接口实现UI进度更新),最后反馈执行的结果给UI主线程.使用的优点:l 简单,快捷l 过程可控使用的缺点:l 在使用...

使用Cookie实现账号共享

本文简要介绍如何通过共享cookie完成账号共享 (共享cookie的起因是部分基于微信小程序的平台并不支持直接的账号密码登陆,需要扫码,无法直接通过共享账号密码完成账号共享;除此之外,cookie共享账号还可以用在诸如短期共享账号而不泄露密码、不被服务器查封等场景下) 工具:Chrome(即谷歌浏览器)、Chrome插件:EditThisCookie...

SpringMvc流程

最近看《Spring源码深度理解》,看到了SpringMvc请求流程,记录下: 这张Spring流程图我借鉴了网上各位前辈的分析,加上自己的理解绘制的,如有侵权勿怪,如果各位觉得有帮助,也欢迎保存 :) 总结下我对SpringWebMvc流程:   Step1.请求被前端控制器DispatcherServlet接收;   Step2.前端控制器Dispa...

服务器端Session和客户端Session(和Cookie区别)

Session其实分为客户端Session和服务器端Session。 当用户首次与Web服务器建立连接的时候,服务器会给用户分发一个 SessionID作为标识。SessionID是一个由24个字符组成的随机字符串。用户每次提交页面,浏览器都会把这个SessionID包含在 HTTP头中提交给Web服务器,这样Web服务器就能区分当前请求页面的是哪一个客户...