Azure AD JWT令牌缺失roles声明致新客户401：是Bug还是设计？

这种情况基本是设计使然，而非Azure AD的Bug，咱们来拆解下原因和解决思路：

核心背景：应用权限与roles声明的关联 #

当你的应用以「无需用户显式同意」的模式（也就是应用权限模式）调用Exchange Online API时，Azure AD要求令牌中必须包含roles声明——这个声明是用来证明你的应用已经获得了租户管理员授予的对应API权限。而这个roles声明只有在管理员完成应用权限的同意操作后，才会被包含在JWT令牌里。

新老客户差异的原因 #

• 老客户部署正常，大概率是因为当时租户管理员已经完成了应用权限的同意流程，或者早期的部署流程中自动触发了同意，所以令牌里能正常拿到roles声明。
• 新客户出现401，几乎都是因为权限同意环节缺失：
  • 可能你在新租户的应用注册中只添加了应用权限，但没有触发「管理员同意」操作（比如没在Azure门户点击「授予管理员同意」按钮，也没通过admin consent端点完成同意）。
  • 也有可能是权限类型选错了：如果误加了「委派权限」，令牌里会是scp声明而非roles，但你的场景是无需用户同意，必须用「应用权限」才行。

验证与解决步骤 #

1. 检查权限配置与同意状态
   登录新客户的Azure AD门户，找到你的应用注册，进入「API权限」页面：
   • 确认添加的是应用权限（而非委派权限），比如Calendars.ReadWrite.All这类针对Exchange Online的应用权限。
   • 确认权限状态显示「已授予[租户名称]管理员同意」，如果没有，让租户管理员点击「授予管理员同意」完成操作。
2. 验证JWT令牌的正确性
   解码新客户场景下获取的JWT令牌（用本地的JWT解码工具即可）：
   • 检查aud声明是否为Exchange Online的资源ID：00000002-0000-0ff1-ce00-000000000000，确保令牌是发给Exchange Online的。
   • 确认除了roles，其他核心声明（比如iss、exp）都正常。
3. 优化部署流程
   为了避免后续新客户再出现这个问题，可以在你的应用部署流程中集成管理员同意的引导，比如提示租户管理员通过特定链接完成同意，或者在应用初始化时自动触发admin consent的请求。

总结 #

Azure AD的这个设计是为了保障租户的权限安全——只有租户管理员明确同意应用的权限请求，应用才能获得带有roles声明的令牌，进而合法访问Exchange Online资源。所以新客户的问题完全是权限同意环节的疏漏，而非平台Bug。

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