我正在尝试了解 Azure Active Directory 的 OAuth 访问令牌请求/响应流中涉及的各个步骤。
我创建了一个高级流程图来说明我认为正在发生的事情。
场景：Web 应用想要使用 Azure AD 登录用户，获得用户阅读他/她电子邮件的权限，并尝试阅读用户的电子邮件。
我不太清楚的事情：
read 对电子邮件的访问权限（在步骤 3 和 4 中授予），为什么我们需要再次验证传入范围？如果应用程序发送一个为计算电子邮件而颁发的访问令牌，我们不能使用该范围来阅读吗？因为我们知道该应用有权读取电子邮件，所以使用为不同目的颁发的访问令牌（验证 appid）有什么危害？【问题讨论】：
标签： authentication oauth-2.0 azure-active-directory
首先恭喜您取得了不错的发现。
现在开始关注你在...
虽然您已经足够封闭，但为了更清楚，Resource 和 Scope 是相同的。如您所知，azure 活动目录有两个版本 V1.0 和版本 V.20
Resource在 V1.0 中已在 V2.0 中替换为Scope两者 定义用户访问域。
现在让我们深入了解令牌实际包含的内容
根据您的问题，有很多 OAuth 2.0 protocol supports in azure active directory 所以每个协议都有不同的解决方法。我给你解释两个。
Azure Active Directory v2.0 和OAuth 2.0 resource owner password credential
ROPC 令牌示例 POSTMAN
让我们看一个使用 ROPC 协议的令牌示例。请参阅下面的屏幕截图 =>
如果您查看https://jwt.io/ 的令牌声明，您会得到答案
请看下面的屏幕截图：
在这个协议中我们有
appId 、 UserId 、 Resource/Scope 以及图片上标记的更多信息。
但所有其他令牌协议不包含相同的信息。您也可以查看OpenID Connect 协议令牌声明。
OAuth 设计用于应用程序 X 需要访问由应用程序 Y 控制并属于用户 A 的资源（例如，“我的信息”或“我的电子邮件地址”或“我的日历”）的情况——用户 A 可能想要授予访问应用程序 Y 上的这些资源，但他不想向应用程序 X 提供他的实际用户名/密码凭据。因此，访问令牌用作应用程序 Y 上资源的替代凭证。访问令牌可以独立于用户名/密码凭证而被撤销，并且理想情况下，其范围很窄，只允许访问特定资源。
使用 OAuth 2 进行身份验证会使模型以可能存在风险的方式过载。查看上面的示例，并想象它被用于身份验证。如果应用程序 X 使用该访问令牌进行身份验证，那么它会获取一个授予对应用程序 Y 上资源的访问权限的令牌，并使用它来授予对自己资源的访问权限。也许这有点让人费解，因为重要的是我们知道通过 OAuth 2 授予访问令牌的行为意味着用户已成功通过身份验证。
问题是访问令牌没有说明最终用户验证了哪个应用程序。那么，如果应用程序 Z 也有用户 A 在应用程序 Y 上的资源的访问令牌，会发生什么情况呢？如果应用程序 Z 可以让应用程序 X 使用此访问令牌，那么它就可以访问用户 A 在应用程序 X 上的资源。这很糟糕。用户 A 可能信任应用程序 Z 访问他在应用程序 Y 上的资源，但用户 A 肯定从未同意应用程序 Z 访问他在应用程序 X 上的资源。有关更多说明，您可以参考 here
另一个原因
根据我的经验，但我不太确定我们是否经常更新我们的应用程序权限和访问范围，如果它不总是检查，我们也将无法访问我们的最新凭据。你也可以参考一些好的线程here
【讨论】：