我正在开发一个基于OAuth 2.0 on Rails的身份验证系统。
我使用Devise gem来处理用户会话和登录,Doorkeeper gem来管理OAuth 2.0工作流。除了用户名和密码登录外,我还具有社交和企业登录功能。它由OmniAuth gem处理。具体来说,对于Google登录,我使用了omniauth-google-oauth2 gem,而对于企业登录,我们为Azure实现了基于SAML的身份验证。
我们遇到的问题与基于SAML的工作流有关。当我们从客户端调用“/oauth/authorize”端点时,它会正确地重定向到登录页面,并且“session ['user_redirect_to']”变量也被正确设置。登录过程完成后,它应该根据“/oauth/authorize”端点中提供的回调URL将用户重定向回客户端。
这个流程对于用户名/密码登录和Google登录都是完美的。但是,当触发SAML回调时,会话将丢失,并且“session ['user_redirect_to']”变量变为空。因此,应用程序无法将用户重定向回所提供的回调URL。
我可以通过将user_redirect_to
作为状态参数传递给saml请求来使它工作,并且在回调中,我可以从param中获取回调url并将其设置回会话。但我知道它不安全,应该有一个更清洁的解决方案可用。
我知道这有点乱,但如果你需要更多的细节,请告诉我
1条答案
按热度按时间ippsafx71#
SAML的工作原理是,其他站点(IDP)将POST回您的应用程序。在较新的Rails版本中,默认的Cookie SameSite策略将是严格的,或者至少是宽松的,如“无”或之前被省略。
在所有当前浏览器中,这将使会话无效(当请求POST到我们的域时,不会发送Cookie),
但有一个明确的缓解措施,这里逐字逐句由Chromium Team:
问:什么是Lax + POST缓解措施?
这是一个特定的例外,用于说明某些单点登录实现中的现有cookie使用情况,其中跨站点POST请求需要CSRF令牌。这只是一个暂时的解决方案,将来会被删除。它没有添加任何新的行为,而是在某些场景中不应用新的SameSite=Lax默认值。具体来说,最多2分钟的cookie将在顶级跨站点POST请求中发送。但是,如果您依赖此行为,则应使用SameSite=None更新这些Cookie;保护属性以确保它们在将来继续运行。
因此,我们需要:
1.确保使用会话存储,并显式设置Secure:真
1.请确保您仍对该请求使用SameSite None:
1.请确保不要在初始化器中覆盖cookie相同的站点策略: