跳转到主要内容

category

概述


广告商经常使用第三方cookie来跟踪多个网站上的用户行为,从而建立用户在线活动的详细档案。这引起了人们对隐私的严重担忧,因为许多用户对未经其明确同意而不断被监控和分析的想法感到不舒服。阻止第三方cookie是防止此类跟踪的一种方式。

从13.1版本开始,Safari默认会阻止第三方cookie,从而中断某些流中的Okta功能。Firefox和其他浏览器也在推出类似的更改。

谷歌Chrome计划在2024年第一季度为1%的用户禁用第三方cookie,然后在2024第三季度增加到100%的用户。点击此处阅读更多关于谷歌计划的信息:取消Chrome用户的第三方cookie。


 
应用于


第三方Cookie

原因


如果您使用Okta-hosted登录页面,并且您的应用程序未从浏览器调用会话API,则此问题不会影响您的组织。拥有自己登录功能的客户可能会受到影响。

当自托管应用程序依赖于HTTP请求中包含的Okta会话Cookie对Okta进行调用时,浏览器会阻止Cookie到达Okta,因为向Okta发出的请求是在第三方上下文中。受影响的特定功能是会话管理,以及OAuth 2.0隐式流和PKCE流中的令牌续订。

潜在影响是什么?


第三方cookie屏蔽可能会影响以下Okta用例:

客户构建的应用程序中的会话管理


如果托管登录页面并使用Okta登录小工具的自托管实例来登录用户,或者依靠用户浏览器中运行的JavaScript来调用Okta来处理会话管理,则浏览器对第三方cookie的阻止可能会破坏功能。

伴随对Okta API端点(如/sessions/me和/users/me)的XHR调用的Okta会话Cookie被浏览器阻止,因为它们被发送到与用户所在的域不同的域。Okta会话cookie永远无法接通Okta,Okta无法完成请求。

结果是Okta向用户返回403个Forbidden错误,或者您的应用程序重复地将用户引导回登录页面。

具体来说,这个问题会影响Okta Auth JavaScript SDK的某些方法。Okta登录小工具在内部使用受影响的Okta Auth JavaScript SDK方法。任何直接对Okta会话API进行XHR调用的客户开发代码也会受到影响。有关更多详细信息,请参阅登录小工具使用的第三方Cookie。
 

使用OAuth 2.0隐式流的客户构建的单页应用程序中的令牌续订


如果代码使用OAuth 2.0隐式流或PKCE流来处理令牌续订(通常发生在使用隐式流或者PKCE流的SPA的上下文中),则浏览器可以阻止发送Okta会话cookie,因此令牌续订永远不会成功完成。

结果是,ID令牌和访问令牌在没有续订的情况下过期,并且提示用户更频繁地登录,登录频率由令牌过期时间决定。
 

某些页面未显示在Okta中的场景


例如,在隐身模式下尝试访问SAML应用程序的视图设置说明

解决方案


从浏览器的角度来看,通过使Okta组织与应用程序服务器有效地成为同一域的一部分,自定义URL域的使用将Okta会话cookie移动到第一方上下文中。对Okta的调用变为同一网站内的调用,浏览器第三方cookie阻止不再触发。

例如,如果原始Okta组织是companyname.Okta.com,而应用程序服务器是app.companyname.com,则您可以使用自定义URL域功能为您的Okta组织提供一个新的URL,如login.companyname.com

另一个选项是更新流以利用刷新令牌。这允许在不提示用户重新验证的情况下刷新用于访问安全资源的当前令牌。请确保在管理控制台内的应用程序上启用“刷新令牌”授权,并按照上面链接中的示例请求,确保存在成功刷新访问令牌所需的查询参数。还要考虑PKCE流可以利用刷新令牌来执行令牌续订。


相关参考文献

文章链接