我是否应该明确地不将标准URL用于MSAL身份验证？

Question

所有MSAL文档都希望我在返回本地设备时使用诸如msalGUID:///之类的前缀。

然后在MSAL portal.

中默认显示一个奇数网址urn:ietf:wg:oauth:2.0:oob

由于我列出的每个URL本质上都是应用程序的后门，所以我想了解每个选项的安全性。

• 我为什么要使用已记录的msalGUID://方案？
• 我不应该使用iOS通用链接/标准网址吗？
• urn:ietf:wg:oauth:2.0:oob和https://login.live.com/oauth20_desktop.srf有什么好处？
• 我应该注意些什么与Microsoft Authenticator的交互，这可能取决于此吗？

Answer 1

背景

在考虑您的应用将使用的重定向URI时，有一些攻击媒介和可用性案例在起作用。

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

需要考虑的情况

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

案例1：朴素的应用

为解决前者，MSAL选择了msal<ClientID>://auth，因为它对于每个应用程序注册都是唯一的。这种格式的随机性很高（urn:ietf:wg:oauth:2.0:oob会丢失），这可以防止设备上的多个应用程序侦听相同URI并“意外”获得响应的情况。对于用户而言，这非常令人沮丧，并且会影响他们使用其应用程序的体验。要总结解决此问题的最佳做法，请使用高度随机的URI，以避免与其他应用程序意外冲突。

情况2：恶意应用

为解决后者，MSAL实现了Proof Key for Code Exchange (PKCE)协议以消除此攻击媒介。为了扩展该方案，它与上述方案类似，不同之处在于该应用程序有意捕获了响应并打算代表您交换授权代码。使用PKCE，只有发起请求的应用程序才能交换身份验证代码。

总结答案

要快速回答您的子弹， 1.涵盖以上。 2.如果您熟悉通用链接以及如何设置必要的步骤，这可能是验证您的应用程序注册仅由您使用的一个不错的选择。 3.这些适用于使用应用程序内WebViews的应用程序，在这些应用程序中，与不离开应用程序这一事实有关的安全性得到更强的保证。 4. MSAL当前未集成到Authenticator中以完成身份验证请求。如果确实如此，则可能要求应用程序完成与类似于ADAL's requirements的重定向URI相关的增强注册。