亲宝软件园·资讯

展开

从零搭建一个IdentityServer——聊聊Asp.net core中的身份验证与授权

7m鱼 人气:0
  OpenIDConnect是一个身份验证服务,而Oauth2.0是一个授权框架,在前面几篇文章里通过IdentityServer4实现了基于Oauth2.0的客户端证书(Client_Credentials)、用户名密码(Password)的授权流程,同时也实现OpenIDConnect的授权码(Authorization Code)、隐式流程(Implicit)的身份验证。
  ???啥?一会儿是授权一会儿是身份验证,身份验证与授权傻傻分不清楚??本文就来聊一聊Asp.net core中的身份验证与授权。
  本文主要内容有:
  • 身份验证与授权
  • Asp.net core中的身份验证与授权
  • Asp.net core身份验证及授权的基本原理
    • Scheme与身份验证处理器
    • 三个方法Authenticate、Challenge、Forbid
    • 两个中间件AuthenticationMiddleware、AuthorizationMiddleware
    • 三个对象HttpContext、ClaimsIdentity、AuthenticationProperties
  • Signin与身份信息载体
  • 自主登录与外部登录
  • Asp.net core身份验证及授权流程
  • Asp.net core中的授权
  • 小结

身份验证与授权

  以前写过一篇asp.net identity的文章(https://www.cnblogs.com/selimsong/p/7828326.html)已经提到过身份验证与授权的概念,简单来说身份验证就是“是谁”的问题,而授权就是“能不能”的问题,一般来说首先需要知道“是谁”,然后再判断“能不能”。
  这里举个生活中常见的小栗子,锁是门用来保护门内财产的工具,而随着科技发展现在有了指纹锁,指纹锁的特征是它既可以通过指纹来开锁,也可以通过钥匙开锁,对于指纹开锁时首先需要录入指纹并指定一个指纹身份,比如保姆阿姨,首先需要的就是给她录入指纹,然后允许该指纹在上午6点至晚上10点可以开门,那么最终保姆阿姨在开门时,授权识别指纹,通过指纹匹配到或者说知道是保姆,这里就是身份验证,如果陌生人进行指纹匹配那么将匹配不到任何身份,但是能否开门还得根据设定的规则,那就是开门时间是否在规定的时间范围内,满足条件才能开门,这就是授权。
  当然在开门这个问题上还有一个Bug,那就是钥匙,只要拥有钥匙,不管是谁都能开门,获得钥匙就是获得授权。
  在软件系统中通常使用的用户名密码登录实际上就是身份验证功能,用户登录后系统就记住这一状态,后续访问系统时系统就知道“是谁”在访问系统,然后因为已经知道是谁,那么就可以根据具体访问条件来判断用户“能不能”访问资源,这就是授权。

Asp.net core中的身份验证与授权

  首先需要再次明确一下Asp.net core是一个Web框架,它本身就具有一些特性,这其中就包括了身份验证和授权。
  在Asp.net core中的身份验证和授权是通过中间件完成的,而把一个中间件添加到asp.net core的应用程序中一般只需要两个步骤,第一是对相关中间件所需参数及服务进行配置,第二就是将相应的中间件添加到请求管道中即可。
  下图为基于OpenIDConnect客户端程序的身份验证配置:
  
  下图为基于OpenIDConnect客户端程序的身份验证及授权中间件配置:
  
  以上代码并没有额外的配置授权策略,但是可以通过Authorize特性来提供最基础的授权(授权通过身份验证的用户)。另外需要注意的是Authorize特性是需要搭配Authorization中间件来使用的,如下图所示:
  
  另外基于Identity组件的身份验证代码中没有出现AddAuthentication及AddCookie方法,而是通过AddDefaultIdentity就可以完成身份验证,是因为AddDefaultIdentity方法中包含了相关方法调用:
  
  AddDefaultIndeity方法代码:
  完成配置后就可以在应用程序中使用身份验证及授权功能了。
  关于asp.net core官方提供的身份验证方式,我们可以直接看看GitHub上的代码:
  
  从图中可以看到有基于Cookie、Jwt Bearer、Oauth、OpenIdConnect也有基于Facebook、Google、MicrosoftAccount、Twitter的,如果非官方的话应该还能找到基于微信、支付宝等账号的登录开源库。
  总的来说asp.net core的身份验证可以支持现有的大部分常用方式或协议,同时也支持第三方的账户登录。

Asp.net core身份验证及授权的基本原理

Scheme与身份验证处理器

  Scheme和处理器可以简单的理解为一个键值对,处理器是用于实际处理身份验证逻辑的代码,Scheme就是这个处理器的标识,通过Scheme可以直接获取到相应的处理器,然后通过处理器来完成身份验证。
  Scheme是一个重要的概念,因为在asp.net core中它可以添加多个身份验证处理器,在Asp.net版本中,或者准确来讲Owin中我们就提到过一个多重身份验证的概念(ASP.NET没有魔法——ASP.NET Identity 的“多重”身份验证)实际上也就是在一个应用里面添加了多个身份验证处理器,换句话说就是一个应用程序支持多种身份验证(登录)方式。asp.net core中管理多个身份验证处理器的核心就是基于Scheme,还记得本文上面oidc验证添加的服务配置代码吗。
  
  在这段代码中设置了身份验证的默认Scheme以及默认ChallengeScheme,关于Scheme的作用请往下看。
  注:asp.net 与asp.net core中的身份验证机制有共同点也有区别,总体来说asp.net core基于scheme的身份验证管理机制逻辑上和性能上会更好(毕竟是最新的产物)。
  关于身份验证处理器,它实际上就是一个实现IAuthenticationHandler接口的类型,它提供了身份验证所需的具体实现逻辑:
  

三个方法Authenticate、Challenge、Forbid

  这三个方法是asp.net core身份验证/授权中的基础,它们分别代表身份验证、质疑和禁止,每一个身份验证处理器都需要实现这三个方法,下面简单介绍一下这三个方法:
  Authenticate:
  • 身份验证调用和核心逻辑,换句话就是证明“是谁”的方法。
  • 拟人化来说就是检查SFZ同时与持有人是否匹配的过程。
  • 在程序中就是检查cookie、jwt token、id token等是否有效,以及信息载体中标记的用户“是谁”
  Challenge:
  • 可翻译为“怀疑/质疑”,实际上就是身份验证没有成功后调用的方法。
  • 拟人化来说就是“我”不知道你“是谁”,但“我”需要知道,所以“我”会问“你是谁?把你的SFZ给我看一下?”
  • 在程序中一般的过程就是重定向到登录页面,通过登录方式告诉系统“是谁”。对于Api一类没有UI的程序时,就返回401状态码告知未通过身份验证。
  Forbid:
  • 这个方法用于授权,授权失败时调用该方法。
  • 这个方法相对简单,当程序存在UI时,通过UI告知用户无权限禁止访问即可,对于Api一类没有UI的程序时,通过返回403状态码告知无权限。

两个中间件AuthenticationMiddleware、AuthorizationMiddleware

  身份验证中间件(AuthenticationMiddleware),只做三件事:
  1. 处理身份验证请求,如oidc的由身份验证服务器完成id_token生成跳转的/signi-oidc。
  2. 处理默认scheme的身份验证流程。
  3. 如果身份验证通过后将验证结果的主体信息(Principal)放到HttpContext中。
  主要代码如下图(参考:https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Core/src/AuthenticationMiddleware.cs):
  
  授权中间件(AuthorizationMiddleware)主要是通过一系列终结点授权信息获取、执行后根据授权执行结果来决定是challenge、forbidden还是拥有权限可进入资源访问(参考:  https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authorization/Policy/src/AuthorizationMiddleware.cs  https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authorization/Policy/src/AuthorizationMiddlewareResultHandler.cs):
  
  注:如果所访问的资源没有授权相关的限制,那么请求将跳过授权步骤直接往下访问。

三个对象HttpContext、ClaimsIdentity、AuthenticationProperties

  首先我们来看看ClaimsIdentity,它实际上是一组Claim的集合,每个Claim代表用户身份的一个属性的键值对,一组Claim可以表示某一方面的用户信息特性,除此之外它还包含是否通过验证(IsAuthenticated)以及验证方式(AuthenticationType)等信息。
  下图为通过oidc身份验证的ClaimsIdentity信息,HttpConext对象中包含的User是ClaimsPrincipal(声明的主体),一个主体里面包含多个ClaimsIdentity信息:
  
  这里可以这么理解这些对象:
  1. 我们每个人都有SFZ、护照、户口册、驾照等可以证明我们身份的东西,这相当于一个ClaimsPrincipal可以拥有多个ClaimsIdentity。
  2. SFZ上面有姓名、SFZ号等属性,相当于一个ClaimsIdentity包含多个Claim。
  3. 关于Claim它代表一个用户信息属性,并且一些属性名称是有相关定义的,具体参考:https://docs.microsoft.com/en-us/dotnet/api/system.security.claims.claimtypes?view=net-5.0。
  4. 每个SFZ明它的识别方法不一样,比如SFZ可以通过SFZ识别器识别、户口册可以在公安局识别,这个相当于每个ClaimsIdentity中的AuthenticationType。
 
  AuthenticationProperties:它是一个用来存储身份验证会话数据的字典,oidc流程中IdentityServer返回的Id_token及access_token等信息就是存储到AuthenticationProperties中。
 
  HttpContext:Http上下文对象,是整个请求的核心,包含了Http请求及响应的所有内容,但是在身份验证/授权方面,它有另一个角色——身份验证服务代理,通过HttpContext我们可以调用身份验证服务的相关方法,包括身份验证和授权中间件的Challenge等方法调用都是通过HttpContext完成的。
  下图为HttpContext在Authentication命名空间下的拓展方法定义:
  
  下图为IAuthenticationService的方法定义,HttpContext通过容器获取IAuthenticationService的实例进行调用,而IAuthenticationService最终实际上调用的是指定或默认身份验证处理器的相关方法:
  

Signin与身份信息载体

  前面文章详细讲解了身份验证的相关细节,但唯独没说的就是登录。登录到底是做了什么事情?在了解登录之前我们先来了解一个概念“身份信息载体”,其实也就字面意思,承载身份信息的物体,在现实生活中我们的身份信息载体是“SFZ”等等实际物品,而在信息系统中信息载体就是一段数据,这段数据为了能让相关程序或者广大程序所理解,它应该按照具体的协议来创建,信息系统中常用的身份信息载体有Cookie以及Jwt(Json web token)。
  Cookie:
  我们都知道http是一个无状态协议,但是大部分时候我们需要它“有”状态,Cookie作为一项浏览器数据存储技术,它经常用于存储一些状态信息,用于下一次发起请求的时候服务器能够了解当前请求的状态。所以Cookie非常适合作为身份信息载体,当然asp.net core的基于Cookie身份验证是这样做的,将用户信息(ClaimsIdentity)加密后存储到Cookie中,下次从Cookie中获取数据,解密后获得用户信息并完成身份验证。
  Jwt:
  Jwt是一种基于Json的安全信息传输标准,Jwt因为带有数字签名的,可以保证数据完整性,就想我们的SFZ一样不能伪造,所以也很适合作为身份信息载体。
 
  Cookie和Jwt各有特点,可适用于不同的应用场景,如Cookie它本身有域特性,现在的单页应用程序它会存在跨域问题,而Jwt虽然能保证数据完整,但是它本身不是加密的(但是传输过程可以加密,并且生产一般必须加密,如https),所以Jwt中的身份信息很容易泄漏,所以它比较适合更封闭的客户端,如服务端与服务端通讯、手机App等。
 
  现在我们再回来聊登录,登录实际上就是将身份信息写到身份信息载体的过程。基于Cookie的就写Cookie,基于Jwt的就颁发Jwt,但是需要注意的是一般jwt由第三方身份验证服务器颁发,所以应用程序本身是不需要关注的,所以这里主要讲讲基于Cookie的登录。
  下面我们做一个基于Cookie登录的小实验,首先做一个简单的基于Identity的登录功能:
  
  设置断点后,直接访问登录页面进行登录,在登录信息提交后我们可以看到User信息是空的:
  
  登录之后仍然没有用户信息:
  
  但是在ResponseHeader的HeaderSetCookie信息中我们找到了如下信息:
  看到它即将写入cookie中带有它创建的身份信息载体。这个就是登录生成身份信息载体的过程,至于登陆后即可访问保护内容,是因为登录完成后做了跳转,跳转后将携带身份信息发起请求后既可以完成身份验证,从而可以访问受保护内容。
  注:Identity提供的登录功能最终也是通过HttpContext的拓展方法通过IAuthenticationService来完成的,具体可参考相关源码,这里不在赘述。
  https://github.com/dotnet/aspnetcore/blob/main/src/Http/Authentication.Core/src/AuthenticationService.cs
  https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Cookies/src/CookieAuthenticationHandler.cs

自主登录与外部登录

  自主登录指的是应用程序本身提供了用户身份核对(用户名+密码登录),然后拥有用户信息自主权(应用程序保存了与用户相关的信息),最后根据用户信息来生成用户信息载体的登录方式。如Asp.net core Identity提供的就是一种自主登录方式。
  外部登录指的是由第三方程序来对用户身份核对,并提供相关用户信息交由程序本身来生成用户信息载体的,或者直接由第三方程序生成用户信息载体的方式。
  如本系列文章介绍的oidc的身份验证就是由IdentityServer提供用户身份核对并提供用户信息(UserInfo EndPoint),然后交由客户端程序来生成身份信息载体Cookie。
  而如果通过IdentityServer直接通过Oauth2.0流程获得Access Token的方式就相当于由第三方程序生成用户信息载体,客户端直接验证用户信息载体即可完成后续的身份验证。

Asp.net core身份验证及授权流程

  前面内容详细介绍了Asp.net core身份验证相关的一些基础原理,下面就通过一个流程图来介绍一下完整的身份验证和授权流程:
  
  从图中我们可以找到3个主体分别是:浏览器、Asp.net core应用程序以及第三方验证服务。
  整个流程的开始可能是通过访问受保护资源、自主登录系统或者外部登录系统开始,但是登录的目的在于访问受保护资源,下面就简单对访问受保护资源流程进行梳理:
  1. 浏览器发起受保护资源访问请求(没有Cookie).
  2. 服务器对请求进行身份验证,因为没有Cookie返回一个失败结果。
  3. 因为验证结果为失败,所以没有ClamsIdentity信息,赋值到HttpContext.User也为空。
  4. 进行授权判断,因为没有经过身份验证,所以调用质疑操作(Challenge),由默认的ChallengeScheme决定是自主登录还是外部登录。
  5. 如果是自主登录,那么跳转到应用登录页面完成登录,并根据用户信息生成ClaimsIdentity。
  5. 如果是外部登录,那么跳转到第三方登录页面完成登录,并回到自主应用的回调地址对第三方返回的code、id_token及access_token进行处理,并获取用户信息,根据获取的用户信息生成ClaimsIdentity。
  6. 系统将ClaimsIdentity信息生成身份信息载体(Cookie)并重定向回之前访问的资源。
  7. 重定向后携带身份信息载体访问受保护资源,如果用户有权限,那么可访问资源,如果没有权限返回403禁止访问。
 
  小提示:为什么asp.net core identity生成的UI代码中,外部登录执行的核心代码为ChallegeResult + (provider 和returnUrl)?
   

Asp.net core中的授权

  前面详细介绍了Asp.net core中的身份验证,授权仅仅是其中的一环来帮助完成身份验证。那么Asp.net core中提供了哪些授权机制或者说要如何进行授权呢?
  Asp.net core及Identity组件提供了简单的(只要通过身份验证)、基于角色的、基于声明(Claim)的、基于策略的授权机制,具体使用方式参考文档:https://docs.microsoft.com/en-us/aspnet/core/security/authorization/introduction?view=aspnetcore-5.0
  另外还给了一个如何实现数据增删改权限控制的例子:
  https://docs.microsoft.com/en-us/aspnet/core/security/authorization/secure-data?view=aspnetcore-5.0
  上面这个例子告诉我们授权机制不仅仅局限于授权特性和中间件,我们可以把授权机制融入到我们的业务逻辑中。

小结

  本篇文章从Asp.Net core介绍了身份验证和授权的基本概念和原理,通过流程图的方式展现了Asp.net core身份验证和授权的流程,最后简单介绍了授权的相关机制。
  现在我们回到文章开头问的问题为什么IdentityServer4提供的功能中一会儿是身份验证,一会儿是授权??
  这个问题需要根据主体来看,首先我们看Oauth2.0,它的最终结果是一个Jwt的Bearer Token,这相当于给了你一把钥匙,使用这个钥匙你可以打开指定的门,所以它是一个授权。
  然后来看看OIDC的授权码流程,它除了Access Token外实际上关键的是Id_token,证实了用户的身份,这相当于告诉你,用户是保姆阿姨,解决了“是谁”的问题,所以是身份验证。知道了是谁,至于开不开门,那是你(客户端程序)的授权问题。
  最后来看看Asp.net core应用程序,在Asp.net core应用程序中不存在独立的授权,换句话就是没法单独使用授权功能,需要身份验证和授权功能联合使用,比如Oauth给了一把钥匙,但是Asp.net core仍要对钥匙进行验证,看清楚钥匙上贴了张三的名字,但很有可能这把钥匙是李四拿着。
 
参考:
https://docs.microsoft.com/en-us/aspnet/core/security/authentication/?view=aspnetcore-5.0
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/introduction?view=aspnetcore-5.0
以及文章中涉及的相关源代码
本文地址:https://www.cnblogs.com/selimsong/p/14367624.html
从零搭建一个IdentityServer——目录(更新中...)

加载全部内容

相关教程
猜你喜欢
用户评论