这个错误是Azure AD认证环节最常见的问题之一，核心原因就是你请求里的redirect_uri和应用注册时配置的重定向URI完全不匹配。结合你的情况，我给你一步步的排查和解决建议：

1. 先排查请求里的redirect_uri参数（最可能的坑） #

看你提供的认证URL示例：

https://login.microsoftonline.com//oauth2/v2.0/authorize?response_type=code&client_id=&redirect_uri= https://server/.../deeplink&scope=Files.ReadWrite.All

注意到redirect_uri=后面多了一个空格！这个空格会被自动编码成%20，导致实际传递给Azure AD的重定向URI变成%20https://server/.../deeplink，而你在Azure里配置的肯定是不带空格的https://server/.../deeplink，这直接就造成了不匹配。先把这个空格删掉，改成redirect_uri=https://server/.../deeplink，这大概率能直接解决问题。

2. 验证Azure AD应用注册的重定向URI #

如果删掉空格还是报错，就去企业租户的Azure门户里检查应用的配置：

• 登录Azure门户（用你的企业账号），搜索“应用注册”，找到ID为2d674cb8-8a33-4bfa-860a-33490fb73ca9的应用
• 进入应用后，切换到身份验证选项卡
• 在“重定向URI”列表里，确认是否存在和你请求里完全一致的URI：
  • 注意大小写：比如HTTPS和https、路径里的大小写必须完全匹配
  • 注意末尾斜杠：如果配置的是https://server/.../deeplink/，而请求里是https://server/.../deeplink（没有斜杠），也会不匹配
  • 注意完整路径：包括子目录、端口（如果有的话）都要完全一致

3. 修正配置或请求 #

• 如果请求里的redirect_uri是正确的业务地址，就在Azure的重定向URI列表里添加这个地址（注意选择对应的平台类型，比如Web应用就选“Web”类型）
• 如果是请求里的URI写错了，就修正代码里的redirect_uri参数，和Azure里配置的保持完全一致

4. 额外注意点 #

• 如果你用的是多租户应用，要确保企业租户已经同意了这个应用的权限（不过这个一般会引发权限类错误，不是回复URL不匹配的问题）
• 应用注册的“支持的账户类型”要包含你的企业租户，比如选择“任何组织目录中的账户”或者“此组织目录中的账户”

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