Angular应用通过client credential flow获取Azure AD access token是否安全可行？

一、前端使用Client Credential流的方案安全性与正确性评估 #

该方案完全错误，存在极高的安全风险，绝对不能落地
原因如下：

• Client Credential（客户端凭证）流是Azure AD专门设计给受信任的服务端客户端使用的授权流程，适用场景是后端服务、定时任务等不会公开代码和凭证的可信环境，从来没有支持浏览器端前端使用的设计
• Angular应用运行在用户侧浏览器中，所有打包后的代码、配置项都是公开可读取的，无论你把client_secret存放在环境变量、打包代码还是任何前端存储位置，用户都可以通过调试工具轻松获取。client_secret是应用级的最高权限凭证，泄露后任何人都可以直接用它向Dev AD请求访问后端API的token，直接绕过所有权限校验规则
• 你遇到的CORS问题本身就是Azure AD的安全机制：Azure AD的token端点默认不会为Client Credential流开放CORS权限，本质就是从协议层面阻止浏览器端使用该高风险流程，不是配置可以解决的问题。

二、正确落地方案（对应客户给出的补充说明） #

客户提到的「使用MSAL库请求token时可将身份提供商作为参数传入」，就是解决当前场景的标准方案，落地流程如下：

• 首先在Dev AD的应用注册中完成信任配置：要么将前端应用的支持账户类型设置为「多组织账户」，允许Client AD租户的用户身份被Dev AD信任；要么直接将Client AD配置为Dev AD的外部联合身份提供商
• 调整Angular项目中的MSAL配置：调用acquireTokenSilent方法请求后端API对应的token时，将authority参数设置为Client AD的端点，scope参数设置为Dev AD侧后端API暴露的权限（格式示例：api://{Dev_AD后端应用ID}/access_as_user）
• 该方案下用户只需要完成一次Client AD的登录，无需额外交互就可以直接拿到Dev AD签发的、可访问后端API的access token，完全不需要用到client_secret，符合安全要求。
• 后端无需调整原有token校验逻辑，保持校验Dev AD签发token的逻辑即可正常工作。

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