我之前也碰到过一模一样的情况，先给你明确：这种EwAoA8l6BAAU格式的令牌不是Base64编码的JWT——它是Azure AD的不透明访问令牌（Opaque Access Token），专门用于Azure内部服务的身份校验，所以直接用Base64解码肯定拿不到有效内容。下面拆解原因和具体解决办法：

为什么会出现这种令牌？ #

• 资源受众不匹配：当你的token请求目标是Azure AD自身的服务（比如部分旧版Microsoft Graph端点、Azure管理API等）时，Azure AD会返回这种不透明令牌，因为这些令牌是给Azure内部系统验证用的，不需要客户端解析内容。
• 请求参数配置错误：如果请求token时指定的resource（v1.0端点）或aud（v2.0端点）参数对应的资源不支持JWT格式的access token，或者scope配置不符合目标资源要求，也会触发这种情况。

解决方法 #

1. 确保请求正确的目标资源 #

如果你的目的是调用自己的API或第三方支持JWT的服务，需要：

• 在token请求中指定正确的resource（v1.0）或目标API的应用ID（v2.0作为aud参数）作为受众。
• 确保目标API在Azure AD中注册时已「暴露API」，并且客户端请求的scope是该API的自定义scope（比如api://{api-client-id}/access_as_user）。

2. 切换到Azure AD v2.0端点 #

v2.0端点默认对大多数自定义资源返回JWT格式的access token，尝试将token请求地址改为：

https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token

同时调整请求参数为v2.0格式（比如用scope代替resource，值为目标API的scope加上offline_access等）。

3. 验证不透明令牌的内容 #

如果确实需要确认这种令牌的有效性和内容，不能直接解码，而是调用Azure AD的令牌 introspect 端点：

• 发送POST请求到https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/introspect
• 请求参数：
  • token：你的不透明访问令牌
  • token_type_hint：access_token
  • client_id：你的客户端应用ID
  • client_secret：你的客户端应用密钥（如果是机密客户端）
• 响应会返回令牌的详细信息，包括过期时间、受众、权限等。

4. 检查应用权限配置 #

确保客户端应用已被授予目标资源的正确权限（委派权限或应用权限），并且完成了管理员同意（如果是应用权限或需要管理员同意的委派权限）。

总结 #

这种EwAoA8l6BAAU格式的令牌不是Base64编码的JWT，属于Azure的内部不透明令牌。通过调整token请求的资源参数、使用v2.0端点，一般就能获取到常规的JWT格式access token；如果需要验证不透明令牌，用introspect端点即可。

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