2

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

然后是MSAL 门户urn:ietf:wg:oauth:2.0:oob中默认显示的古怪 url。

由于我列出的每个 URL 本质上都有一个进入我的应用程序的后门，因此我想了解每个选项的安全优势。

  • 为什么我应该使用记录在案的msalGUID://方案？
  • 我不应该使用 iOS 通用链接/完全限定 URL 吗？
  • urn:ietf:wg:oauth:2.0:oob和有什么好处https://login.live.com/oauth20_desktop.srf？
  • 我应该注意与 Microsoft Authenticator 的 wrt 交互，这可能取决于此？
4

1 回答 1

2

背景

在考虑您的应用程序将使用的重定向 URI 时，有一些攻击向量和可用性案例会发挥作用。

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

需要考虑的案例

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

案例 1：天真的应用

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

案例 2：恶意应用

为了解决后者，MSAL 实施了代码交换证明密钥 (PKCE)协议来消除这种攻击向量。扩展该场景，它与上述场景类似，只是应用程序已故意捕获响应并打算代表您交换授权码。使用 PKCE，只有发起请求的应用程序才能交换身份验证码。

总结答案

为了快速回答你的子弹，

  1. 上面覆盖。
  2. 如果您熟悉通用链接以及如何设置必要的步骤，这可能是验证您的应用注册是否仅供您使用的不错选择。
  3. 这些适用于使用应用内 WebViews 的应用程序，其中有更强的安全保证，因为它不会离开应用程序。
  4. MSAL 当前未集成到身份验证器中以完成身份验证请求。当它这样做时，应用程序可能需要完成与重定向 URI 相关的增强注册，类似于ADAL 的要求。
于 2018-10-03T17:07:32.347 回答