bug: OneLogin SSO issuer validation conflicts with sign-in discovery URL

快速结论：这个报错出现在 Langfuse Cloud 组织级 SSO 选择 Provider = OneLogin 时：保存校验通过所需的 issuer 与 NextAuth 登录流程拼接 discovered URL 所需的 issuer 不一致，导致“能保存的配置登不进去、能登录的配置存不下”。排查重点是 OneLogin issuer 取值，以及保存校验与 NextAuth 的 wellKnown 是否使用同一个 discovery URL。

适用环境：Langfuse Cloud（组织级 SSO，已验证域名）；身份提供方为 OneLogin OIDC 应用；涉及 Langfuse Web 应用服务端的 NextAuth / OIDC discovery。Issue 指出代码基于 langfuse/langfuse main 分支 8c26de8，next-auth ^4.24.14（锁文件解析为 4.24.15）。未提供操作系统、Python、CUDA、显卡信息，不涉及应用 SDK 或集成。

最快修复方案：暂无确认的一步修复方案。Issue 中只有待实现的修复计划，尚未验证发布。

注意事项：Issue 提出的方案是：先把 OneLogin issuer 解析成统一值，同时用于保存校验和 NextAuth 的 wellKnown；去掉一个末尾斜杠后，以 /oidc/2 结尾的值原样作为 issuer，其他值追加 /oidc/2。该方案仅处于提案阶段，实际行为以修复合并后的版本为准。另外，修改现有 SSO 配置的 issuer 前，需要考虑历史上已保存值的兼容性，Issue 中用一条 SQL 判断是否存在两种方案 discovery URL 不一致的配置。

问题场景

在 Langfuse Cloud 的组织 SSO 设置中，为已验证域名新增 SSO 配置，Provider 选择 OneLogin，填写 client ID、client secret 和 issuer，然后尝试用该域名下的邮箱完成 SSO 登录。触发问题的是 Langfuse Web 应用中的保存校验（validateSsoConfig）与 NextAuth v4 OneLogin provider 的 discovery URL 拼接逻辑。使用 OneLogin 的完整 OIDC issuer 时保存成功但登录失败；只填租户 URL 时保存失败。

报错原文

bug: OneLogin SSO issuer validation conflicts with sign-in discovery URL

https://<tenant>.onelogin.com/oidc/2/oidc/2/.well-known/openid-configuration → 404

https://<tenant>.onelogin.com/.well-known/openid-configuration → 400

原因分析

Issue 中的核心原因是保存校验和登录流程对 issuer 的解释不一致，导致没有任何一个 issuer 值能同时满足两步：

保存时，validateSsoConfig 请求 <issuer>/.well-known/openid-configuration，并要求返回的 issuer 与配置值一致。OneLogin 只有在配置 https://<tenant>.onelogin.com/oidc/2 时才能通过。
登录时，已保存的 issuer 被原样传给 NextAuth v4 的 OneLogin provider，后者把 wellKnown 拼成 ${issuer}/oidc/2/.well-known/openid-configuration。若 issuer 已是完整 OIDC issuer，就会请求 .../oidc/2/oidc/2/.well-known/openid-configuration，返回 404。
若只填租户 URL https://<tenant>.onelogin.com，登录时拼出的 discovery URL 是对的，但保存校验请求 https://<tenant>.onelogin.com/.well-known/openid-configuration 返回 400，配置无法保存。

Issue 还确认，仓库中对 next-auth@4.24.15 的补丁只修改 core/lib/oauth/client.js 中的 HTTP 选项，不影响 OneLogin provider 构建 wellKnown 的方式。可能原因还包括历史保存的 issuer 值（例如在 #13507 加入 discovery 校验之前保存的租户 URL）与新校验逻辑之间的差异，这需要按 Issue 中的 SQL 进一步确认。

环境排查

确认使用的是否为 Langfuse Cloud，以及组织是否已配置并验证域名。
确认 SSO 配置的 Provider 是否为 OneLogin。
确认当前保存的 issuer 值：是 https://<tenant>.onelogin.com，还是 https://<tenant>.onelogin.com/oidc/2，或带末尾斜杠的其他形式。
手工请求以下三个地址，核对返回状态码与返回的 issuer：
- https://<tenant>.onelogin.com/oidc/2/.well-known/openid-configuration
- https://<tenant>.onelogin.com/.well-known/openid-configuration
- https://<tenant>.onelogin.com/oidc/2/oidc/2/.well-known/openid-configuration
确认部署的 Langfuse 或自托管版本中 next-auth 的版本，以及是否存在影响 OneLogin wellKnown 拼接的补丁。
自托管场景需确认是否沿用相同的 validateSsoConfig 与 NextAuth provider 代码路径；Issue 仅报告 Langfuse Cloud，未给出自托管验证结论。

解决步骤

先在 OneLogin 租户上确认实际发布的 issuer。Issue 的 HTTP 检查显示 https://<tenant>.onelogin.com/oidc/2/.well-known/openid-configuration 返回 200，且 issuer 为 https://<tenant>.onelogin.com/oidc/2。
在 Langfuse 组织中检查当前 SSO 配置的 issuer，并对照上方三个 discovery URL，判断当前属于 Case A（完整 issuer 能保存但登录 404）还是 Case B（租户 URL 保存时 400）。
若可以改动代码，可优先尝试 Issue 中提出的统一解析方案：保存校验和 NextAuth 的 wellKnown 使用同一个解析后的 OneLogin issuer；去掉一个末尾斜杠后，以 /oidc/2 结尾的值原样使用，其他值追加 /oidc/2。
在执行上述改造前，可按 Issue 提供的查询检查是否存在 discovery URL 会因该方案而变化的现有配置：
```
SELECT domain, auth_config->>'issuer' AS issuer
FROM sso_configs
WHERE auth_provider = 'onelogin'
  AND regexp_replace(auth_config->>'issuer', '/$', '') NOT LIKE '%/oidc/2';
```
如果查询返回空，Issue 提出可以把修复缩小为仅将 wellKnown 设为“去掉一个末尾斜杠的 issuer + /.well-known/openid-configuration”，保存校验保持不变；如果返回有行，则需按完整方案处理兼容性。
修改后重新保存 OneLogin SSO 配置，并用已验证域名下的邮箱发起 SSO 登录，观察 NextAuth 实际请求的 discovery URL 是否为预期地址。

验证方法

确认 SSO 配置能够保存，并且从登录页发起 OneLogin SSO 时 NextAuth 请求的 discovery URL 返回 200，而不是 oidc/2/oidc/2/... 的 404 或租户根路径的 400；随后能正常完成 OneLogin 认证并返回 Langfuse Cloud。由于 Issue 的修复尚处于提案阶段，上述验证需在包含该修复的版本或自建补丁上执行。