将内部身份提供商PingID集成到ASP.NET Core Identity Server与Angular应用

1. 内部PingID集成架构方案 #

针对Identity Server无法直接访问内网PingID的问题，有两种可行的架构调整方案：

方案一：客户端侧认证+令牌交换 #

• 流程调整：
  1. 用户在Identity Server登录界面选择PingID登录选项；
  2. Identity Server返回跳转指令给Angular应用，引导其直接发起PingID的授权码流请求（Angular运行在内网用户设备上，可直接访问PingID）；
  3. Angular完成PingID认证后获取授权码，调用Identity Server的自定义令牌交换端点；
  4. Identity Server通过部署在双网互通节点的内网代理服务，将授权码发送至PingID令牌端点换取身份令牌，验证用户合法性；
  5. 验证通过后，Identity Server生成自身的访问/ID令牌返回给Angular，后续保持原有API访问流程不变。

方案二：内网反向代理打通网络 #

• 部署一个反向代理服务在Identity Server网络与PingID内网的互通节点，配置Identity Server通过代理地址访问PingID的令牌、JWKS等核心端点；
• 按照常规OpenID Connect外部提供商的配置方式，将PingID的端点地址替换为代理地址，原有登录流程无需大幅修改，用户体验与Okta、Azure AD集成完全一致。

2. oidc-client.js客户端认证的可行性与整合方式 #

完全可行，oidc-client.js是Angular生态中成熟的OIDC客户端库，可直接对接PingID的授权码流，整合方式如下：

• 在Angular应用中配置两个OIDC客户端实例：一个对接现有Identity Server，一个对接PingID；
• 当用户触发PingID登录时，Angular切换至PingID的OIDC客户端，发起认证请求并处理回调；
• 成功获取PingID的授权码或ID Token后，调用Identity Server的令牌交换端点（可基于OpenIddict的Token Exchange扩展实现），将PingID的身份凭证转换为Identity Server的令牌；
• 后续Angular使用Identity Server的令牌访问Web API，保持原有权限验证逻辑不受影响；
• 注意事项：需在PingID后台配置Angular应用为信任客户端，回调地址指向Angular应用；同时确保Identity Server能通过代理获取PingID的JWKS密钥，用于验证PingID令牌的有效性。

3. OpenIddict相关机制与WebProviders的价值 #

• OpenIddict本身没有专门解决跨网络访问内部IDP的机制，但它的OpenIddict.AspNetCore.WebProviders扩展可以简化标准OIDC提供商的集成流程，比如自动处理端点发现、令牌验证、用户信息获取等重复逻辑；
• 针对当前场景，WebProviders无法直接解决Identity Server与PingID的网络连通问题，必须先通过代理或客户端侧流转方案打通网络，再用WebProviders简化PingID的集成配置；
• 是否值得研究：如果后续需要集成更多标准OIDC/SAML提供商，WebProviders能大幅减少开发工作量，提升集成效率，因此值得投入时间研究。

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