我希望在一个调用自己的REST API的移动的应用程序中使用Azure Active Directory（AD）对用户进行身份验证，并尽可能简化此过程。
看起来文档中记录的方法（here或此处）是
1.向AD注册API应用程序，将某些作用域公开为委派权限
1.注册移动的应用，将这些作用域作为API权限添加到此应用
1.根据这些范围在API应用程序中做出授权决策
**问题：**现在，由于我觉得应用的前端和后端部分应该属于同一个“黑盒子”，而且应用中没有细粒度的用户角色来证明使用多个作用域的合理性或要求用户同意使用它们，我想知道是否有一种推荐的（安全的）方法可以只注册一个应用而不是两个？
**我的尝试：**在类似的场景中使用Okta时，我只有一个应用程序（clientId），后端配置基本上验证了JWT令牌颁发者、域和默认受众字符串（据我所知）。我尝试检查通过授权代码流从AD获取的令牌，以了解他们的受众是什么，以及是否可以复制-这是我得到的结果：
- 众所周知的Microsoft Graph GUID（用于访问令牌）-此GUID验证起来并不“正确”，因为几乎任何AD用户都可以为MS Graph提供访问令牌，并且只有分配的用户才应该能够使用我的应用程序
- 应用程序的客户端ID（用于ID令牌）-但docs says这些不应用于授权，因此不确定将它们作为承载令牌传递给API是否是个好主意
2条答案
按热度按时间qoefvg9y1#
OAuth技术中的标准做法是仅为移动的应用注册客户端。Azure在涉及与resource indicators spec相关的API时具有一些供应商特定的行为。当没有API注册时，移动应用将接收JWT头部中具有
nonce字段的JWT访问令牌。这些令牌旨在发送到Graph，并且如果您试图在自己的API中验证它们，验证将会失败。如果你像我一样想保持接近标准，一个选择是添加单个逻辑应用注册，以表示你的API集。你可能会设计
api.mycompany.com的受众，尽管Azure会给予你像cb398b43-96e8-48e6-8e8e-b168d5816c0e这样的技术价值。然后你可以公开范围，并在客户端应用程序中使用它们。这相当容易管理。几年前我的blog post中的一些信息可能有助于澄清这一点。rur96b6h2#
现在，由于我觉得我的应用的前端和后端部分应该属于同一个“黑盒子”，加上应用中没有细粒度的用户角色来证明使用多个作用域的合理性或要求用户同意使用它们，我想知道是否有一个推荐的（和安全的）方法来只注册一个应用而不是两个？
您只能创建一个应用程序注册;事实上，较新的应用程序注册模型就是为此设计的。在API仅由应用程序本身使用的情况下，我会注册一个作用域，类似于MobileApp. Access。您的API应验证此作用域是否存在，以防止未经授权的应用程序调用它。
除了验证作用域之外，您还需要验证用户权限，并根据用户身份筛选数据，具体取决于您的用例。
您的问题似乎暗示您可能混淆了作用域和用户角色。作用域是授予应用程序的权限。也称为委派权限;它们允许应用代表登录用户执行某些操作。