基于Angular与.NET WebAPI的SAML身份认证流程咨询

一、角色定义 #

• Azure AD 是 IdP（身份提供商）：作为信任的第三方，负责存储用户身份数据、处理身份验证逻辑，是用户身份的来源方。
• 你的.NET后端API是SP（服务提供商）：因为它是需要验证用户身份、提供受保护业务资源的服务方，在SAML协议中承担发起认证请求、验证IdP返回的SAML断言的核心角色。

二、交互流程验证与修正 #

你梳理的流程核心逻辑是对的，但有几个关键细节需要调整，同时补充标准SAML流程的规范：

• 步骤2修正：UI调用SP的登录端点后，SP不会直接向IdP发送请求，而是返回一个重定向响应给浏览器（UI），让浏览器跳转到Azure AD的登录页面——这是因为IdP需要直接和用户交互，收集账号密码、MFA等验证信息。
• 步骤4说明：IdP验证用户身份通过后，会通过浏览器重定向到SP预先配置的ACS（断言消费服务）端点，这个端点和步骤2的登录端点是不同的，是专门用来接收并处理SAML响应的接口。
• 后续流程补充：SP在ACS端点完成SAML响应的解析与验证（包括签名合法性、断言内容有效性、受众匹配等），验证通过后生成自身的身份凭证（比如JWT Token）返回给UI；UI携带该凭证访问后端受保护API，最后跳转到已认证页面。

三、关于UI直接调用IdP的疑问 #

不建议让UI直接向IdP发送SAML请求，原因有两点：

1. 安全风险：SAML请求需要SP使用私钥签名以确保合法性，前端无法安全存储私钥，极易导致密钥泄露。
2. 验证缺失：前端没有能力完成SAML响应的完整安全验证（比如签名校验、断言有效期检查等），会引入身份伪造的风险。

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