这个 OAuth2 Native 应用程序流程可以被认为是安全的吗？

Question

我有一个使用 IdentityServer4 和 ASP.NET Identity 构建的 OpenID Connect 提供程序，运行在假设：login.example.com。

我有一个在假设spa.example.com 上运行的 SPA 应用程序，它已经使用我的 OpenID Connect 提供程序通过 login.example.com 对用户进行身份验证，并授权他们访问 SPA。

我有一个移动应用（两个平台上都是原生的），目前正在使用自定义身份验证系统。

我认为摆脱自定义身份验证系统会很好，而是允许我的用户使用他们在 SPA 上使用的相同帐户登录，即使用我的 OpenID 提供程序。

因此，我首先查看 OpenID 连接网站并重新阅读 RFC6749，经过几次 google 搜索后，我意识到这是一个常见问题，我发现 RFC8252（用于本地客户端的 OAuth2），也是客户端动态注册 (RFC7591) 和 PKCE (RFC7636)。

我挠了挠头，因为它可能会被泄露，所以不再可能在客户端/第三方（本机应用程序）上存储任何类型的“秘密”。

我与一些同事讨论了这个话题，我们得出了以下设置：

1. 使用 Apple Universal Links 和 Android App Links 将域（例如 app.example.com）关联到我的移动应用。
2. 为两个客户端使用 AuthenticationCode 流并强制它们使用 PKCE。
3. 在应用关联域上使用redirect_uri 说：https://app.example.com/openid
4. 让用户在登录后始终同意登录应用程序，因为iOS或Android都不会通过自动重定向将应用程序带回，必须是手动单击通用/应用程序链接的用户每次。

我在两个应用程序上都使用了 AppAuth 库，现在在 test 上一切正常，但我想知道：

1. 您认为这是防止任何具有适当技能的人冒充我的应用程序或通过任何其他方式未经授权访问我的 API 的安全方法吗？目前实现这一目标的最佳做法是什么？
2. 有什么方法可以避免让用户总是“同意”（让他们实际点击通用/应用链接）。
3. 我还注意到 Facebook 将他们的应用程序本身用作一种授权服务器，因此当我在应用程序上点击“使用 facebook 登录”时，我会进入一个 facebook 页面，询问我是否愿意“启动应用程序执行登录”。我想知道如何实现这样的目标，以允许我的用户使用我的应用程序（如果已安装）在手机上登录 SPA，就像 facebook 对他们的应用程序所做的那样。

Answer 1

我认为摆脱自定义身份验证系统会很好，而是允许我的用户使用他们在 SPA 上使用的相同帐户登录，即使用我的 OpenID 提供程序。

这就是 OAuth 2.0 和 OpenID Connect 为您提供的。在不同服务之间使用单一用户身份的能力。所以这是正确的方法。！

不再可能在客户端/第三方（本机应用程序）上存储任何类型的“秘密”，因为它可能会受到损害

正确。从 OAuth 2.0 规范的角度来看，这些称为 public clients。不建议将客户端机密与其关联。相反，授权代码、应用程序 ID 和重定向 URL 用于验证身份提供者中的令牌请求。这使得授权码成为一个有价值的秘密。！

使用 Apple 通用链接和 Android 应用链接将域（例如 app.example.com）与我的移动应用相关联。

不是移动专家。但是，是的，自定义 URL 域是处理 OAuth 和 OpenID Connect 重定向的方式。

PKCE 的使用也是正确的方法。因此，重定向发生在浏览器（用户代理）中，可能存在可以获得授权码的恶意方。 PKCE 通过引入不会暴露给用户代理（浏览器）的秘密来避免这种情况。 Secret 仅用于令牌请求（直接 HTTP 通信），因此是安全的。

第一季度

将授权代码流与 PKCE 结合使用是 OAuth 规范推荐的标准最佳做法。这对 OpenID Connect 也有效（因此它基于 OAuth 2.0）

需要注意的一点是，如果您认为 PKCE 机密可以被利用，那么它的字面意思是设备已被盗用。考虑从操作系统内存中提取秘密。这意味着系统受到损害（病毒/键盘记录器或我们所说的）。在这种情况下，最终用户和您的应用程序需要担心的事情更多。

另外，我相信这是针对商业应用程序的。如果是这种情况，您的客户肯定会有他们设备的安全最佳实践指南。例如安装病毒防护和限制应用程序安装。为了防止上述攻击，我们将不得不依赖此类安全机构。单独的 OAuth 2.0 并不安全。！这就是为什么有最佳实践指南 (RFC68129) 和政策的原因。

第二季度

这点不清楚。同意页面由身份提供者提供。所以这将是该系统的配置。

第三季度

嗯，身份提供者可以在浏览器中维护 SSO 会话。该浏览器上存在登录页面。所以大多数时候，如果应用使用相同的浏览器，用户应该能够在没有登录的情况下使用 SPA。

Answer 2

这里的威胁来自实际在其设备上安装恶意应用程序的人，该恶意应用程序确实可以冒充您的应用程序。 PKCE 可防止其他应用拦截从您的应用发起的合法登录请求，因此标准方法尽可能安全。每次强制用户登录/同意应该有助于让他们注意正在发生的事情。

从 UX PoV 来看，我认为尽量减少使用基于浏览器的登录流程的场合是很有意义的。我会利用平台的安全功能（例如 iOS 上的安全飞地）并在用户以交互方式登录后在其中保留一个刷新令牌，然后他们可以使用他们的 PIN、指纹或面部等登录。