无需重定向至IdP页面的SSO实现可行方案探讨

一、关于自定义IdP通过POST转发账号密码的方案 #

这个方案技术上存在实现可能，但严重违反SAML的安全设计原则，且绝大多数正规IdP不会开放此类接口：

• SAML核心是基于断言的信任传递，IdP绝不会暴露接收明文账号密码的POST接口——这会彻底破坏SAML「无需共享密码给服务提供商」的安全基础。
• 即便ThirdApp的IdP私下提供了密码验证API，MyApp需要存储并传输用户的明文/明文等价密码，会导致密码泄露风险，同时让MyApp承担合规风险（如GDPR、等保要求）。
• 这种模式本质是把MyApp变成密码代理，完全失去SSO的意义，反而引入额外安全隐患。

二、OAuth 2.0架构下的可行方案 #

如果ThirdApp支持OAuth 2.0协议，以下两种方案可实现「展示自有登录页」的需求：

方案1：资源所有者密码凭证授权模式 #

• 流程：
  1. 用户访问MyApp中需要ThirdApp资源的页面，MyApp展示自有登录页。
  2. 用户输入账号密码后，MyApp作为OAuth客户端，直接向ThirdApp的授权服务器发送POST请求，携带grant_type=password、username、password、client_id、client_secret等参数。
  3. ThirdApp授权服务器验证通过后，返回access_token、refresh_token等凭证。
  4. MyApp使用access_token访问ThirdApp的资源接口。
• 注意：该模式仅适用于MyApp与ThirdApp属于同一信任域（如同公司内部系统）的场景，OAuth 2.1已将此模式标记为不推荐，仅用于遗留系统。

方案2：授权码模式+可信客户端静默授权 #

• 流程：
  1. MyApp提前在ThirdApp的授权服务器注册为可信客户端，并获得跳过用户登录页的权限（需ThirdApp支持配置）。
  2. 用户访问MyApp中需要ThirdApp资源的页面，MyApp展示自有登录页，验证用户身份（如使用自身账号体系）。
  3. 验证通过后，MyApp后台直接向ThirdApp授权服务器发起授权码请求（无需前端跳转），携带client_id、client_secret、redirect_uri、scope等参数，由于是可信客户端，授权服务器直接返回授权码。
  4. MyApp用授权码换取access_token，随后访问ThirdApp资源。
• 优势：符合OAuth 2.1的安全规范，无需传输用户密码，MyApp仅需管理自身账号体系，同时获得ThirdApp的访问凭证。

补充：混合模式（自有账号体系+账号绑定） #

如果ThirdApp不支持上述两种模式，还可以让MyApp先完成自有账号登录，再通过账号绑定提前获取ThirdApp的授权凭证：

• 用户首次使用时，MyApp引导用户跳转至ThirdApp的授权页完成授权，之后将ThirdApp的refresh_token与用户的MyApp账号绑定存储。
• 后续用户登录MyApp时，直接使用绑定的refresh_token换取新的access_token，无需再跳转ThirdApp登录页。

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