为何调用acquire_token_with_username_password获取Azure AD令牌失败？

我之前也踩过这个坑，结合Azure AD现在的应用模型更新，给你梳理下解决方案：

1. 先理清应用类型的变化 #

你提到的2年前的"native应用"，现在Azure AD已经把它归类为**公共客户端应用（移动和桌面）**了，原来的Web应用属于机密客户端应用。这两类应用在ROPC（资源所有者密码凭证）流程下的要求完全不同：

• 公共客户端不需要传入client_secret或client_assertion；
• 机密客户端必须传其中一个，不然就会触发你遇到的错误。

怎么确认和修改你的应用类型：

• 登录Azure门户找到你的应用注册，进入「概述」页面，查看"应用类型"字段；
• 如果当前是Web/单页应用，进入「认证」页面，点击「添加平台」，选择「移动和桌面应用」；
• 在弹出的配置框里，勾选「公共客户端流」下的「允许使用用户名/密码流」，保存后你的应用就会被标记为公共客户端。

2. 方法参数的正确传递方式 #

• 如果应用已经配置为公共客户端，你原来的调用语句token = auth_context.acquire_token_with_username_password(resource, username, password, clientId)是完全没问题的，前提是已经开启了ROPC流；
• 如果你的应用必须是机密客户端（比如是Web应用，没法改成公共客户端），这个方法其实支持传入client_secret参数——可能你没注意到，不同语言的MSAL库参数名略有差异，比如Python的MSAL里可以这么写：

  token = auth_context.acquire_token_with_username_password(
      resource,
      username,
      password,
      clientId,
      client_credential="你的应用注册里的客户端密码"
  )
  

• 至于client_assertion，这是用客户端证书代替密码的更安全方式，一般场景用client_secret就足够，只有对安全性要求极高时才需要配置证书。

3. 额外提醒 #

ROPC流程因为需要直接处理用户密码，安全性其实不高，微软现在更推荐授权码流这类更安全的认证方式。如果你的场景允许，尽量考虑切换到其他流程。另外还要确保应用注册里已经添加了对应resource的API权限，并且完成了管理员同意（如果是租户级权限）。

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