Azure active directory 我是否应该明确不使用带有MSAL身份验证的标准URL？

所有MSAL文档都希望我在对本地设备进行身份验证时使用前缀，例如

msalGUID://

然后是一个奇怪的url

urn:ietf:wg:oauth:2.0:oob

，默认情况下显示在

因为我列出的每个URL本质上都是进入我的应用程序的后门，所以我想了解每个选项的安全优势

• 为什么要使用有文档记录的

  msalGUID://

  方案
• 我不应该使用iOS通用链接/完全限定URL吗

• urn:ietf:wg:oauth:2.0:oob和
  https://login.live.com/oauth20_desktop.srf

• 对于w.r.t.与Microsoft Authenticator的交互，我应该知道什么，这可能取决于此

背景 在考虑应用程序将使用的重定向URI时，有一些攻击向量和可用性案例

首先，您的应用程序是否将从未沙盒到您的应用程序的授权代理登录用户。如果您使用的是MSAL，那么答案几乎总是肯定的（除非您明确选择使用应用内WebView）

案例考虑 如果是这样，那么您需要考虑两种情况：重定向URI的意外冲突（可用性问题）和恶意应用程序故意试图拦截被重定向回您的应用程序的用户（安全问题）

案例1：天真的应用程序 为了解决前者，MSAL选择了

msal://auth

因为它对每个应用程序注册都是唯一的。这种格式中存在大量的随机性（这在

urn:ietf:wg:oauth:2.0:oob

中丢失），这防止了设备上的多个应用程序监听同一URI并“意外”得到响应的情况。对于用户来说，这是非常令人沮丧的，会影响他们使用应用程序的体验。要总结解决此问题的最佳实践，请使用高度随机的URI，以避免与其他应用程序发生意外冲突

案例2：恶意应用 为了解决后者，MSAL实现了协议来消除这个攻击向量。为了扩展该场景，它与上述场景类似，只是该应用程序有意捕获响应并打算代表您交换授权代码。使用PKCE，只有启动请求的应用程序才能交换身份验证代码

总结答案 要快速回答你的问题， 1.如上所述。 2.如果您熟悉通用链接以及如何设置必要的步骤，这可能是验证您的应用注册是否仅由您使用的一个好选项。 3.这些应用程序适用于使用应用程序内网络视图的应用程序，在这些应用程序中，它不会离开应用程序，因此具有更强的安全保证。

---

4.MSAL当前未集成到身份验证程序中以完成身份验证请求。当它这样做时，应用程序可能需要完成与重定向URI相关的增强注册，类似于