VPN SSO 会自动让用户登录内部应用吗？

通过身份提供方认证的 VPN 网关只证明一件事：提供方为某个用户向网关做了担保。它并不会把内网 wiki、监控面板或构建服务器的凭据交给该用户。这些服务通过各自的联邦身份让用户登录，并施加各自的授权，隧道只决定哪些数据包能到达它们。

三个会话，三个独立的判断

请把这些状态分开看，因为各自的过期时间不同。VPN 会话是网关对身份的接受，以及它授予的网络访问。身份提供方的浏览器会话是浏览器仍为该提供方保留、并可按其策略复用的状态。应用会话则属于某个验证了发给它的响应的服务。

把这些状态混为一谈，就会问错问题，通常是问隧道为什么不在所有地方都让用户登录。换个问法：哪个应用没有联邦身份条目，哪个拒绝该用户，哪个缺少路由。一次打开内网应用的登录提示仍可能跳回提供方，因为第二次重定向是针对另一个受众的新授权请求。

把网关作为独立应用接入

在提供方把 VPN 注册为已批准的应用，给它独立的标识符、重定向 URI 和用户分配。然后再决定这次登录授予哪些网络授权，因为这属于 VPN 策略，而不是提供方的功能。只应访问监控子网的用户应得到不同的网关策略，而不是不同的密码。

隧道的认证响应不是可复用的凭据。OIDC ID 令牌带有受众声明，指明它是为哪个客户端签发的；SAML 承载断言则把受众限制在接收它的服务提供方。接受第一个服务响应的第二个服务属于配置错误，把令牌复制到另一个应用也不是集成。

逐个注册内部应用，再设置浏览器上下文

每个服务都需要受支持的 SAML 或 OIDC 值：签发方、客户端标识符、回调或断言消费方 URL、必需的声明以及分配。可达性还要另算，因为身份检查从不提供路由或 DNS 应答。

1. 创建应用条目，并确认实体 ID 或客户端 ID 与应用发送的内容一致。
2. 注册精确的回调 URL，包括协议和端口；稍有偏差，用户认证后就会失败。
3. 分配用户或组，然后确认必需的声明被释放。
4. 除私有应用外，还要放行身份提供方的端点，否则重定向无法完成。

浏览器上下文决定是否复用已有的提供方会话。打开系统浏览器的原生客户端可以共享该状态，而自带 cookie 容器的嵌入式视图通常不能。新开浏览器、隐私窗口和第二个配置文件都从零开始，这是正常现象，而不是 SSO 配置损坏。

跑一遍流程，读出它停在哪一步

用浏览器的网络面板复现，并观察重定向链。有用的走查是一次看一跳：网关到提供方，提供方带着代码或断言回到应用，应用再到提供方的令牌端点，最后签发应用会话。链路停在哪一跳，就说明要修哪个组件。

两条命令行检查就能解决常见的疑问，而且都可以在管理主机上安全执行：

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

当元数据列出你从未注册过的端点时，说明应用指向了另一个租户或签发方。当对应用的第一个请求以 302 跳向意外的主机时，该看的是应用的联邦配置，而不是 VPN 配置文件。

从是谁发起的入手修正提示

第二次密码提示并不一定是缺陷。应用可能要求更高的保证级别，或者 提供方可能强制最大会话时长并要求重新挑战。为了少一次提示而删掉这些要求，会削弱有意设置的控制，所以先弄清是哪个组件发起的，再改策略。

然后再决定改进什么。如果提示来自应用，就修正它的联邦条目。如果按策略来自提供方，就记录该要求。如果登录成功后仍访问不到应用，那可疑的是隧道路由，因为 身份与数据包投递是在不同环节失败的，从用户的位置看却很像。