初始化Open IDC auth dance时存储GET请求参数以供以后使用

Posted 2023-02-19

【中文标题】初始化Open IDC auth dance时存储GET请求参数以供以后使用

【英文标题】：Storing GET request parameters when initialising Open IDC auth dance for use after

【发布时间】：2021-11-25 22:39:51

【问题描述】：

我们正在将 Keycloak 作为 IDP 实施，并将使用它来保护某些应用（依赖方）

这些应用程序可能会使用 mod_auth_openidc 之类的东西，它会使用授权码流将用户引导到用户将登录的 keycloak，进行 openidc 舞蹈，并最终返回“redirect_uri”。

我们将使用一组参数调用应用程序，例如： https://some-application/launch?person=12345

redirect_uri 将是 https://some-application/launch，据我了解，Oauth2 规范非常具体，redirect_uri 应该是静态的，并且不包含参数/是动态的。

这意味着登录后请求参数“person=12345”丢失，因为用户只是被重定向回“https://some-application/launch”

在 OIDC 舞会发生之前保持此“person=12345”请求参数的推荐模式/方法是什么？

我已经阅读了有关“状态”参数的信息，但我不清楚我们将如何使用 mod_auth_openidc 将任何内容注入其中，或者我们如何从中读取任何值？ 这更像是一个应用程序框架问题吗？某种控制器/服务器端代码（php/c# 等）会以某种方式将这些值存储在会话中（但我不清楚他们是否有机会在 mod_auth_openidc 启动之前存储这些值？

【问题讨论】：

实际上 mod_auth_openidc 使用 state 参数为您管理这个 - 结合 cookie 存储 - 确实

【参考方案1】：

在重定向之前存储位置并在之后恢复它是应用程序的责任：

单页应用可以像this code of mine 一样通过会话存储来管理这一点，因为它们可以控制之前和之后的行为

服务器端 Web 应用程序可能会为您提供类似的选项，将位置存储在仅限 HTTP 的 cookie 中，然后在之后恢复它，但您需要检查正在使用的特定技术。这是一个众所周知的可用性问题，可能会发生 UI 无法控制的突然重定向，并且深度链接（如您所描述的）可能不起作用。

您需要一个应用程序设计来解决这个问题。出于兴趣，我的recent blog post 提到了这个问题。