Open IDC认证初始化阶段存储GET请求参数供后续使用的方案咨询

解决方案总览 #

针对你描述的场景，有两种成熟的落地方式，分别适配不同的技术栈版本和业务需求：

方案1：使用mod_auth_openidc原生参数透传能力（推荐，无需改业务代码） #

首先纠正一个常见认知误区：OAuth2 规范并没有禁止redirect_uri携带固定查询参数，只是要求redirect_uri必须和IDP侧预注册的地址完全匹配，因此你无法通过动态修改redirect_uri拼接person参数的方式实现透传，这个判断是对的。

mod_auth_openidc 2.4.0及以上版本已经内置了GET参数透传能力，你只需要在Apache的配置文件中添加如下指令即可：

# 多个透传参数用空格分隔
OIDCStatePassThroughParams person

配置生效后，模块会自动将请求中携带的person参数编码进OIDC认证请求的state字段，待用户完成登录跳转回redirect_uri时，模块会自动把person参数追加到回调地址的查询字符串中，你的业务应用可以直接从请求参数中读取对应值，无需手动处理state的编解码逻辑。

如果你的mod_auth_openidc版本低于2.4.0，可以通过自定义请求头+state注入的方式实现：

1. 用重写规则把需要透传的参数写入Apache环境变量

RewriteEngine On
RewriteCond %{QUERY_STRING} person=([^&]+)
RewriteRule ^/launch - [E=OIDC_CUSTOM_PARAM:person=%1]

2. 配置模块将环境变量内容编码进state

OIDCStateInputHeaders OIDC_CUSTOM_PARAM

3. 回调后从Apache传递给应用的OIDC_CLAIM_state头中解析出自定义内容即可。

方案2：应用层会话存储（适配复杂逻辑场景） #

如果你需要透传的参数较多、内容较长，或者有额外的校验逻辑，更适合用应用层会话存储的方案，需要做如下配置调整：

1. 修改mod_auth_openidc的默认拦截策略，允许未认证的请求透传到业务应用：

OIDCUnAuthAction pass

2. 业务应用接收到未认证用户的/launch?person=xxx请求时，首先给用户分配会话Cookie，将person参数存入当前用户的会话中
3. 应用返回302重定向到触发OIDC认证的路径（可自定义为/protected这类单独的路径，只有访问该路径时mod_auth_openidc才会拦截触发认证）
4. 用户完成登录跳转回业务应用后，应用直接从当前用户的会话中读取之前存储的person参数即可。

注意事项 #

• 为什么默认配置下应用代码拿不到请求？mod_auth_openidc默认运行在Apache请求处理的认证阶段，早于应用层代码执行，未认证请求会被模块直接拦截跳转到IDP，不会传递给应用，因此必须修改OIDCUnAuthAction配置才能让匿名请求到达应用层。
• state参数有长度限制，单条state建议不要超过256字符，透传内容过多时优先选会话存储方案。

内容的提问来源于stack exchange，提问作者marc