能否在OIDC/OAuth2.0身份提供商前添加代理实现自定义登录流程？

你提出的透传Okta配置、让A直接和C完成认证交互的方案完全合规，不会违反OIDC/OAuth2安全协议，不需要从零搭建完整的认证服务器，仅需要实现最小化的代理逻辑即可落地。

方案1：PlayFramework侧实现轻量OIDC代理（推荐，改造量最小） #

你只需要在现有Play服务中新增3个核心OIDC接口，所有核心校验逻辑全部透传Okta，仅在你侧完成登录页渲染和账号映射即可：

• /.well-known/openid-configuration接口：直接请求Okta对应OIDC发现接口，将返回结果中的所有Okta域名替换为你的C服务域名后原样返回给A即可
• /authorize授权接口：A跳转至该接口后，你正常渲染自有登录页，用户提交站点侧的混淆账号密码后，你在后端完成站点账号到Okta真实账号的映射，调用Okta的资源所有者密码凭证流（ROPC）完成身份校验，拿到Okta返回的授权码后按OIDC规范返回给A
• /token令牌接口：收到A的令牌交换请求后，直接将请求透传至Okta的令牌接口，将返回结果原样返回给A即可
• 可选/userinfo接口：如果A需要拉取用户信息，同理透传Okta返回结果即可，也可以在该层自定义字段映射适配你的业务规则

这种方案的代码改造量极小，完全复用你现有对接Okta的登录逻辑，不需要引入额外依赖。

方案2：反向代理层实现路径转发（零代码改造） #

如果你不想改动现有Play服务的代码，可以在C服务的前置反向代理（Nginx、APISIX等）中配置转发规则：

• 所有OIDC标准路径（/.well-known/*、/oauth2/*、/userinfo等）直接代理转发到Okta对应地址
• 仅将/authorize授权路径转发到你的Play服务登录页，登录完成后调用Okta接口获取授权码返回给A即可

• 不要在你侧自行签发、篡改任何OIDC令牌，所有令牌的签名、校验、过期逻辑全部依赖Okta，即可完全符合安全规范
• 如果A侧有OIDC issuer校验限制，你可以将发现接口返回的issuer字段保留为Okta的原始值，或联系A的提供方将你的C服务域名添加至可信issuer白名单即可，绝大多数第三方OIDC客户端都支持该配置
• 该方案天然解决你提到的账号映射问题，所有站点侧混淆账号到Okta真实账号的转换都在你自有服务层完成，不会触发Okta侧的登录标识不匹配问题

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