很多新手对于将IdentityServer4迁移到3.x版本时应该注意的问题都不是很清楚,为了帮助大家解决这个问题,下面小编会详细讲解一下。需要的人可以从中学习,希望你能有所收获。
升级基本问题
对于身份中的上下文[IdentityDbContext],需要下载以下附加包:
【微软。【身份.实体框架工作中心】
对于以下客户端OIDC配置,您需要下载以下软件包
【微软。【认证.开放连接】
对于客户端身份验证和授权配置,授权中间件需要配置如下(身份验证和授权没有顺序)
我们知道在此之前,dotnet CLI中已经包含了迁移的命名,现在已经修改为通过单独的包进行,所以需要下载下面的提示包,否则会抛出下面的异常。
命令行工具的版本可能与的当前版本不一致。NET核心。使用以下命令更新它
本地环境中可能没有任何问题,但是在生产环境中,可能会引发以下错误。我们会看起来很傻吗?
针对上面抛出的异常,关于Cookie的故事将在一个很长的段落中解释。
Cookie安全策略问题
当cookie在大约20年前被设计出来并重新设计时,跨站点请求伪造(CSRF)攻击和跟踪用户并不是什么大事。
根据cookie规范,如果为特定的域设置了cookie,那么来自浏览器的每一个请求都会发送到该域,无论我们是否直接导航到该域,如果浏览器只从该域加载资源(即图像),向其发送POST请求或者将一部分嵌入iframe,
但是,还有一种情况,我们不希望浏览器自动将用户会话cookie发送到服务器,因为这将允许任何网站在用户的上下文中执行请求服务器的脚本。
为了避免这种情况,SameSite cookie规范是在2016年起草的,它使我们能够更好地控制何时应该发送和不应该发送cookie。设置cookie后,我们现在可以在浏览器添加cookie时显式指定每个cookie。为此,它引入了当浏览器位于我们自己的域中时来自同一站点的cookie的概念,以及当浏览器导航到另一个域但向我们的域发送请求时跨站点cookie的概念。
为了向后兼容,同一站点中cookies的默认设置不会改变以前的行为。如果我们添加这个新函数,我们需要显式地将cookies设置为SameSite=Lax或SameSite=Strict,以使它们更加安全,这已经在。NET框架和所有常见的浏览器。Lax表示在初始导航时会向服务器发送cookies,Strict表示只有当我们已经在这个域中时(即初始导航后会发送第二个请求)。
但这一新功能并没有被广泛采用(根据Chrome 2019年3月的遥测数据,全球Chrome处理的所有cookie中,只有0.1%使用SameSite标识。为了推广这项新功能,谷歌决定改变世界上最常用浏览器的默认设置:
Chrome 80将需要新指定的设置SameSite=None来保持处理cookie的旧方式,如果我们按照旧规范中的建议省略SameSite字段,它将把cookie与SameSite=La结合起来。
x一起设置。
请注意:
仅当cookie也被标记为Secure并且需要HTTPS连接时,设置SameSite = None才有效,
这里关于更多SameSite的信息就不再阐述。
如果我们有一个单页Web应用程序(SPA),该Web应用程序通过另一个域上托管的身份提供程序(例如IdentityServer 4中的Idp)进行身份验证,并且该应用程序使用所谓的令牌刷新,则将会受到影响,登录IdP时,它将为我们的用户设置一个会话cookie,并且该cookie来自IdP域,
在身份验证流程结束时,来自不同域的应用程序将收到某种访问令牌,这些令牌通常生命周期并不长,当该令牌过期时,应用程序将无法再访问资源服务器(API),如果用户每次都必须再次登录,可想用户体验之差,
为防止这种情况,我们可以使用刷新令牌,在这种情况下,应用程序将创建一个用户不可见的iframe,然后在该iframe中再次启动身份验证过程, IdP的网站已加载到iframe中,并且如果浏览器通过IdP发送会话cookie,则会识别用户并发出新令牌,现在,iframe位于应用程序域中托管的SPA中,其内容来自IdP域,这将被视为跨站点请求,
因此,如果Cookie明确指出SameSite = None,则Chrome 80只会将该Cookie从iframe发送到IdP,否则,令牌刷新将在Chrome 80中出现中断的情况。
也还有其他可能潜在的问题,如果我们在Web应用程序或网站中嵌入了来自另一个域的元素(例如视频),并且这些元素需要Cookie才能正常运行(例如自动播放设置),那么这些也会需要设置SameSite策略,如果我们的应用程序需要从浏览器请求依赖Cookie身份验证的第三方API,则同样适用,我们只能更改自己服务器从而设置cookie行为。
通过上述对Cookie的讲解,我们可以显式设置SameSite安全策略从而保证到底发不发送Cookie,所以我猜测在.NET Core 3.x中是不是更改了Cookie的安全策略,如果客户端的为Strict的话,那就会导致上述异常的发生,比如如下:
看完上述内容是否对您有帮助呢?如果还想对相关知识有进一步的了解或阅读更多相关文章,请关注行业资讯频道,感谢您对的支持。
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/113488.html