您是否在运行一个带有会话的web应用程序（例如，用于保存用户首选项、购物车）？您允许用户使用诸如Google和Apple之类的身份提供者登录，还是使用Auth0之类的解决方案？这些场景有什么共同点？它们都依赖cookies来实现其功能。您需要知道的是，浏览器cookie行为的变化正在不断出现，可能会破坏您的用户体验。截至2020年2月，googlechrome已经开始推出一个可能与您的web应用程序不兼容的更改，大多数其他浏览器也会效仿。有什么变化？简而言之：浏览器正在改变对第三方cookie的默认处理方式。具体来说，该更改与cookies上的SameSite属性有关：默认情况下，以前的浏览器行为允许在第三方上下文中发送没有SameSite属性的cookies，但是正在实现的更改将使cookies的默认行为受到更大的限制。如果你不太清楚这意味着什么，这篇文章绝对适合你！可能会受到什么影响？以下是最有可能受更改影响的场景列表：使用saml2.0或OpenID Connect等协议与身份提供者集成。从第三方域嵌入web应用程序内容。从第三方域查询API。注意：这不是一个详尽的列表。让我们更详细地了解其中的一些场景，特别是在新的浏览器行为下可能出现的问题。使用标识提供程序登录Web应用程序当用户使用一系列的认证来进行身份验证时，用户将用一个ID来进行认证。身份验证的证明由发送回应用程序的ID令牌表示，如下图的步骤（D）所示。在此之前：之后：在上图中的步骤（D）中，web应用程序执行ID令牌验证，它需要在会话中存储信息。如果没有对今天的实现进行任何更新，承载会话或身份验证请求绑定信息（图中为nonce）的cookie将不再附加到POST，从而导致响应验证检查失败，最终用户无法登录应用程序。显然，它还有更多的细节、条件和细微差别。我们将继续深入研究技术细节。了解现代世界中处理身份验证的实际标准。下载免费电子书$（'.oidc手册按钮a'）。单击（功能（e）{metricsLib.track('博客：点击：oidc手册广告"）；});谷歌为什么要推动这些变革？简而言之，提供一个更安全的默认功能模式，并为将来更好的隐私控制开辟了可能。如今，在默认配置下的cookie是许多web应用程序CSRF漏洞背后的原因。此类漏洞是指将HTTP表单从攻击者的上下文提交到应用程序，该应用程序使用附加的POST request cookie作为识别最终用户会话的机制，并执行恶意操作，例如向攻击者执行转账。浏览器更新会将cookies的默认配置从不太安全的模型更改为在安全性和可用性之间达成合理平衡的模型。应用这些更改后，上面的攻击将不起作用，因为HTTP表单POST是从不同的来源完成的，默认情况下不会附加cookie，并且操作将由于缺少身份验证而失败。这一变化允许开发者在默认情况下受到保护，但仍然允许应用程序在需要时选择不太安全的模式。这些变化是什么时候发生的？这些更改不会一次发生—这取决于更改何时到达用户的浏览器。具体日期将取决于他们使用的浏览器供应商、版本和发布渠道。截至2020年2月，主要浏览器采用了以下变化：ChromeV80（发布于2020年2月4日）已经开始对一小部分用户进行修改。随着时间的推移，卷展将增加。Chromium项目站点正在跟踪状态更新，并且在这里和这里跟踪了原始特性卷展栏。Firefox实现了开发者偏好标志背后的变化，并在Firefox中启用了每晚一次的功能。每夜发现的问题都会被记录在错误记录单中。当前没有默认启用它的目标版本。Edge已经实现了实验性特性标志背后的变化，并宣布他们将在82版的Dev和Canary频道中开始试验这些特性。默认情况下，没有给出启用该功能的预计到达时间。萨法里还没有表示会被收养。可以使用CanIUse跟踪对所有其他浏览器的支持。怎么办？联系您的技术合作伙伴、提供商和服务运营商，易淘客，询问他们是否准备好接受这种变化。这适用于您可能正在使用的服务以及您正在使用的sdk。如果您是Auth0的客户，那么请确保我们已经在执行必要的步骤来促进此更改。一些更改将自动发生，在Auth0这一边，而不需要对您的任何操作。根据web应用用于实现登录和/或授权的特定SDK和底层授权，您可能需要更新到能够处理新浏览器行为的SDK的更新版本。定期检查和更新您的SDK，并在它们的自述文件和变更日志以及Auth0仪表板通知中留意任何需要的操作。这到底是什么变化？世界上没有一个web开发人员会遇到cookies。Cookies作为一种HTTP状态管理机制，早在1997年就被IETF标准化了。自那时以来，这一机制一直在发展（2000年、2011年），最新更新自2016年以来一直处于草案状态。通过无限量的在线材料，开发人员被告知，默认情况下，cookies将附加到所有对他们的web服务的请求中，并且浏览器会处理好这一点。当涉及到一个名为SameSite的cookie属性时，这只是部分正确的。自从这个属性在2017年的草案更新中被引入以来，它的默认值并没有破坏现有的web服务。它仍然将cookies附加到范围内的所有请求。这就是现在的变化。SameSite到底是什么？SameSite是一个cookie属性，定义如下：SameSite属性限制了cookie的范围，因此只有当这些请求是同一个站点时，才会将cookie附加到请求中，如本文档第5.2节中的算法所定义的那样。您可能已经熟悉的其他cookie属性包括：HttpOnly：使浏览器仅将cookie附加到HTTP请求，而不使用javascript的文档.cookie接口。安全：使浏览器仅将cookies附加到安全上下文，即HTTP over TLS（https）。Max Age/Expires：控制浏览器终止浏览会话/时cookies是绑定到浏览会话还是丢弃，还是"persistent"/持久浏览会话终止/。省略使用浏览器的javascript API设置的cookies，这些选项由服务器提供，其HTTP响应作为set Cookie头的一部分。浏览器在收到响应后，将解析这些响应并维护其cookiejar。下面是常规服务器端Set Cookie头的工作原理。这是一个新的互动。最终用户请求一个他从未访问过的页面。服务器希望更改下次呈现的方式，因此它设置了一个"可见"cookie。set cookie头的灰色部分是实际的cookie key+value；红色部分是浏览器内部存储在cookie jar中的所有cookie属性，以便以后决定是否在请求中包含cookie key+value对。现在，让我们在同一个浏览会话中再次发出该请求。正在向同一个服务器发出请求，由于cookie属性不禁止发送"seen"cookie，用云服务器，因此它会自动作为cookie头包含在请求中。服务器现在可以根据收到这样一个cookie的事实做出不同的响应。在这个示例中，path=/和httponly上面的Set Cookie header是Cookie属性，就像SameSite一样，SameSite今天[在不兼容方面很重要，我们将在后面讨论]有三个定义的值：SameSite=严格SameSite=Strict值背后的意图是严格模式下的CSRF缓解/保护；否则，人工智能网络，只有当请求页面的来源（不是RFC6454定义的来源）与其正在访问的某个资源相同时，才会发送合格的cookie。这意味着，当用户从另一个站点导航链接时（例如，通过指向您的链接），您的cookies不会被附加，因此任何以前建立的基于cookie的会话都不会被加载。直到用户导航到页面原点中的链接，浏览器才会附加cookies。下面是一个场景，在这种情况下，严格的cookie不会被附加。用户已在网站然后单击a/resource链接。如果这是来自同一来源的XHR请求，它也将被附加。下面是两种情况，其中SameSite=Strict cookies被阻止附加。用户当前没有浏览网站然后单击链接或以某种方式提交表单。如果这些是XHR请求，它们也不会被附加。请注意，浏览器没有发送cookie头，大数据如何处理，消防物联网，因为请求与SameSite=Strict cookie的条件不匹配。SameSite=Lax公司SameSite=Lax设置具有与Strict完全相同的语义，但将顶级重定向排除在限制之外，以允许常规的"浏览"行为。这意味着一块饼干仍然不是