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

Question

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

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

我有一个移动应用程序(在两个平台上都是 native 的)，目前正在使用自定义身份验证系统。

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

所以我首先查看 OpenID connect 网站并重新阅读 RFC6749 ，经过几次谷歌搜索后，我意识到这是一个常见问题，我发现 RFC8252 (适用于 native 客户端的 OAuth2)，还有客户端动态注册 ( RFC7591 ) 和 PKCE ( RFC7636 )。

我对这样一个事实感到摸不着头脑:不再可能在客户端/第三方( native 应用程序)上存储任何类型的“ secret ”，因为它可能会受到损害。

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

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

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

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

Answer 1

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

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

不再可能在客户端/第三方( native 应用程序)上存储任何类型的“ secret ”，因为它可能会受到损害

正确。从 OAuth 2.0 规范的角度来看，这些称为 public clients 。不建议他们拥有与之关联的客户端 secret 。相反，授权代码、应用程序 ID 和重定向 URL 用于验证身份提供者中的 token 请求。这使得授权码成为一个有值(value)的 secret 。!

使用 Apple 通用链接和 Android 应用链接将域(例如 app.example.com)关联到我的移动应用。

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

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

第一季度

将授权代码流与 PKCE 结合使用是 OAuth 规范推荐的标准最佳实践。这对于 OpenID Connect 也有效(因此它是基于 OAuth 2.0 构建的)

需要注意的一件事是，如果您认为 PKCE secret 可以被利用，那么这实际上意味着设备已受到损害。考虑从操作系统内存中提取 secret 。这意味着系统受到损害(病毒/键盘记录器或我们所说的任何东西)。在这种情况下，最终用户和您的应用程序有更多需要担心的事情。

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

第二季度

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

第三季度

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