如何在OIDC中实现类SAML的IDP发起式联邦SSO流程？

算力阿峰

2026-5-29

OIDC替代SAML IDP发起式SSO的实践疑问解答

现有SAML IDP发起式SSO流程

目前你们的系统在同一服务器部署SPA和REST API，采用SAML的IDP发起式联邦SSO，流程如下：

假设客户侧IDP是Okta这类OIDC兼容服务，你对角色的理解是：

但查阅资料后产生了这些疑问：

资料显示SPA需先向Authorization Server获取access token，再用该令牌调用Resource Server的userInfo API，这似乎说明我方服务器并非Resource Server，客户侧IDP需同时承担Authorization Server和Resource Server角色？
如此一来，我方服务器在OIDC流程中处于什么位置？
Okta与我方服务器间的信任如何建立？
能否在OIDC中实现与SAML的IDP发起式联邦SSO等效的流程？

咱们先把角色和流程的关键点掰扯清楚：

你的基础角色理解是对的，但关于userInfo API的误解需要澄清：

我方的REST API服务器确实是Resource Server，而Okta的userInfo API只是OIDC标准里用来获取用户基本信息的端点，和你的API服务器是两回事。SPA拿到access token后，一方面可以调用Okta的userInfo API拿到用户信息（比如姓名、邮箱），另一方面更关键的是，要用这个access token来调用你的REST API服务器——这时候你的服务器作为Resource Server，需要验证这个token的合法性，确认用户身份后开放权限。

你的服务器其实承担了两个核心角色的部分职责：

SPA的宿主：因为SPA部署在你的服务器上；
Resource Server：提供业务REST API，负责验证access token并授权访问；
另外，你还需要在SPA中嵌入OIDC客户端逻辑（或在服务器做一层代理），用来处理和Okta的认证交互、获取token等操作。

信任关系的建立逻辑和SAML类似，通过双方配置完成：

你需要在Okta中注册你的SPA作为一个OIDC Client，获取Client ID、Okta的授权端点、token端点、JWKS端点等配置信息（SPA属于公开客户端，无需Client Secret）；
你的Resource Server需要配置Okta的JWKS端点，用来获取公钥，验证access token的签名——Okta签发的token用私钥签名，你的服务器用公钥验证签名，就能确认token是Okta合法签发的；
同时，你要和客户约定好audience（受众）参数（即你的API服务器的唯一标识），Okta签发的access token里的aud字段必须匹配这个标识，确保token是专属给你的服务的。

完全可以实现！OIDC里对应的流程叫IDP Initiated Login Flow，和SAML的逻辑高度匹配，具体步骤如下：

与客户集成时，在Okta中配置你的SPA作为应用，获取Okta的IDP发起登录URL；
客户在Okta的应用列表中添加你的应用，配置好跳转规则；
用户在Okta控制台点击你的应用图标，Okta会直接跳转到你的SPA回调地址（类似SAML的ACS URL），同时携带授权码；
你的SPA接收授权码，向Okta的token端点换取access token和ID token；
你的Resource Server验证access token的合法性，同时可以用ID token里的sub字段（类似SAML的NameID）识别用户，之后开放API访问权限；

另外补充：因为SPA是公开客户端，建议采用Authorization Code Flow with PKCE来获取token，这是OIDC针对公开客户端的安全最佳实践，能有效避免token被窃取。

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