基于OIDC与SAML(Azure AD)的Duende IdentityServer SSO后续实现疑问

当前方案正确性 #

你的架构方向完全正确——以Duende Identity Server（IdS）作为企业统一SSO身份网关，内部MVC应用（BoatsApp、CarsApp）通过OIDC对接IdS实现内部SSO，同时通过Sustainsys.Saml2让IdS对接Azure AD作为外部身份源。这种身份代理（Identity Broker）模式是企业统一SSO的标准实践，既保证了内部应用身份逻辑的一致性，又能灵活对接外部身份系统。

缺失的核心环节 #

你已经完成了SAML身份验证的基础流程（获取并验证SAML断言、拿到Azure AD的Claims），但缺少从“SAML身份验证完成”到“向内部应用颁发OIDC JWT Token”的关键衔接，具体包括：

• Claims转换与标准化：Azure AD返回的SAML Claims格式和OIDC标准Claims不匹配，需要将其映射为sub、name、email等OIDC规范字段，否则内部应用无法识别用户身份信息。
• 授权流程衔接：在ExternalLogin/Callback处理完SAML响应后，需要让IdS继续处理returnUrl指向的/connect/authorize/callback请求，完成OIDC授权流程并生成JWT Token。
• 用户会话建立：IdS需要为通过SAML验证的用户建立本地身份会话，这样后续用户访问其他内部应用时无需重复走SAML登录流程。
• 身份关联（可选）：如果企业需要本地用户数据（比如自定义权限），还需将Azure AD的SAML身份标识与IdS的本地用户账号绑定；若不需要本地用户，可直接用Azure AD的用户标识作为OIDC的sub Claim。

实现目标的最优方式 #

1. 保持内部应用的OIDC对接不变：不要修改BoatsApp、CarsApp的身份验证逻辑，让IdS全权处理所有外部身份源的适配，内部应用仅与IdS通过OIDC交互，确保架构的一致性和可维护性。
2. 标准化Claims映射：在Sustainsys.Saml2的配置中添加Claims转换规则，或者在IdS的IProfileService实现中统一处理Claims的映射与补充，将Azure AD返回的SAML Claims转换为OIDC标准格式。
3. 完善回调流程逻辑：
   • 验证SAML响应并提取Claims后，调用IdS的SignInManager创建用户身份会话；
   • 直接重定向到returnUrl指定的OIDC授权回调地址，IdS会自动完成授权流程，向客户端应用返回id_token和access_token。
4. 可选：实现用户关联功能：如果需要本地用户数据，在IdS中添加用户关联页面，允许首次通过SAML登录的用户绑定本地账号，后续登录自动关联身份。

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