微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

授权代码流 - 来自多个选项卡的并发请求

如何解决授权代码流 - 来自多个选项卡的并发请求

OAuth2 身份验证代码流中基于 cookie 的会话的性质和 状态 参数处理暴露了一个问题,当新的浏览器会话以多个选项卡启动时,尝试同时打开“安全服务器”上的多个链接(我们的 Oauth2 机密客户端)。

当浏览器启动时,它会丢弃所有以前的会话 cookie。在崩溃恢复的情况下,浏览器或用户可以从书签文件夹或历史记录中一次打开多个选项卡。

在这种情况下,所有选项卡都会同时向安全服务器发送未经身份验证的请求。每个请求都将启动一个新会话和一个新的身份验证代码流,带有新的 state 参数,将保存在此会话中。

所有安全服务器重定向到身份提供者的响应都将带有一个具有相同名称但不同值的会话 cookie。它们会在浏览器中相互覆盖,浏览器只保留最后一个作为会话 ID。

每个选项卡将沿着授权代码流继续向下到身份提供商登录页面并返回到安全服务器,带有不同的状态参数,但具有相同的会话 cookie(由最后一个选项卡设置)。>

那些状态 参数保存在现在丢失的会话中并且无法验证。 状态禁止参数验证失败,并发出403错误

结果是除最后一个以外的所有标签都以403页面结束。

是否有任何已知的做法来处理这个问题?

谢谢

解决方法

有趣的问题,在大多数情况下,这将是开始工作的挑战,并且需要以下方面的支持:

  • 客户端 OAuth 库
  • 授权服务器

兼容库

oidc-client-js 库演示了所需的技术,通过每个重定向的状态存储。正如您所说,最后一个人将获胜,最终用户不会出现任何错误。

这是客户端 Web UI 比服务器端 Web 堆栈(例如 ASP.Net / Spring Boot)触发的重定向具有更大控制权的可用性领域之一。

行为可视化

运行我的 Online OAuth SPA 并触发 2 个重定向,但不要登录。然后浏览到这个网址,在重定向状态下查看浏览器的本地存储工具:

enter image description here

最后一个获胜者将更新用户存储,其数据用于后续续订重定向和令牌验证(请注意,我的 SPA 将实际令牌存储在内存中而不是此用户存储中):

enter image description here

不合规的授权服务器

不幸的是,我的在线授权服务器 (AWS Cognito) 不喜欢像这样接收 2 次登录并且第二次登录失败。

enter image description here

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。