我在 .NET 6 Web 应用程序(带有授权代码流的 OAuth 2)中遇到身份验证配置问题。我决定通过 Azure 应用程序注册来实现身份验证。添加必要的平台、重定向 URL、确定范围后,一切都变得非常顺利。我的.NET应用程序中的业务逻辑需要连接到Azure DevOps平台API,因此我想使用相同的Azure应用程序注册表来配置DevOps API授权,因此我添加了Azure DevOps的API权限。我的目的是在我的应用程序中使用相同的 Bearer 进行授权,然后在登录用户的上下文中在 Azure DevOps API 中使用相同的 Bearer 进行授权,因此我大肆地添加了两个范围:
api://tenantid/custom_scope_name // my custom scope
499b84ac-1321-427f-aa17-267ca6975798/user_impersonation // const azure devops scope
之后,我遇到了以下错误:
AADSTS28003:使用提供的授权代码请求访问 token 时,为输入参数范围提供的值不能为空。请指定有效范围。
我发现 Microsoft 不允许为多个资源指定范围,因此我开始寻找如何解决该问题。我遇到了两种潜在的“解决方法”,尽管我还不清楚它们的可靠性。
首先,我可以获得 Azure DevOps 范围的访问 token 并在我的应用程序中禁用受众验证。这种方法可行,但似乎不是推荐的解决方案。
其次,我可以获得自定义应用程序范围的访问 token ,在我的应用程序中对其进行授权,并向我的应用程序发送刷新 token 。通过这种方法,我可以使用收到的刷新 token 获取 Azure DevOps API 范围的访问 token 。
有人可以建议如何实现这种情况以保持代码的高质量和安全性吗?
最佳答案
Azure AD 不会让您同时获取应用程序和 Azure DevOps 的 token 。以下是一些解决方法:
<小时/>1。 获取 Azure DevOps token 并跳过安全检查
- 好:易于实现。
- 不好:有一点风险,因为它会跳过安全检查。
2. 对多个 token 使用一个刷新 token
- 好:更安全。将刷新 token 视为“可重复使用的通行证”,无需再次询问用户即可获得新的访问权限。
- 不好:设置需要更多时间,而且您必须保证刷新 token 的安全。
3. 代表流程 (OBO)
如果您的应用想要为用户与 Azure DevOps 对话,此方法很方便。
- 好:专为这种情况而设计,并且安全。
- 不好:第一次设置可能有点棘手。
步骤:
- 用户登录您的应用。
- 您的应用获得一个 token 。
- 您的应用使用该 token 为 Azure DevOps 获取不同的 token 。
4。 获得两个 token ,一个接一个
基本上,您要求用户登录两次:第一次登录您的应用程序,然后登录 Azure DevOps。
- 好:将事物分开。
- 不好:对于用户来说可能有点乏味,因为他们可能会被请求两次许可。
步骤:
- 用户登录您的应用。
- 然后,他们登录 Azure DevOps。
- 使用正确的 token 执行正确的任务。
建议:我建议使用代表流程 (OBO),这是第三个选项。如果您的应用程序经常代表用户与 Azure DevOps 进行通信,那么它非常适合。但所有选项都可行,因此请选择适合您需求的选项。
关于c# - 如何通过Azure应用程序注册实现多资源授权?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/76879467/