OAuth2 中的“资源所有者密码凭据”是否安全？

Question

所以，我正在开发一个API使用slim/slim和 League league/oauth2-server来管理OAuth2连接。 OAuth2 将很有用，因为我需要在服务之间使用客户端凭据授权。

然后，我也在用React Native开发一个混合应用程序。 此应用程序将要求用户使用电子邮件和密码登录或连接其他服务（如 Facebook、Google、Twitter 等）。

而且我对在这种情况下使用什么 OAuth2 流程感到困惑。 在 web 中有很多文章说资源所有者密码凭据不再安全，我们应该使用PKCE 的身份验证代码。

但是我无法发现或理解如何在第一方应用程序中使用 PKCE 应用身份验证代码，因为所有关于您的文档都需要使用浏览器来获取redirect_uri中的身份验证代码。

我想象的流程是这样的：

1. 用户打开应用程序，然后插入您的凭据username和password ；
2. 此屏幕将连接到 API /request_token URI 发送{ 'grant_type': 'password', 'username': username, 'password': password, 'client_id': CLIENT_ID } ，考虑到它是一个公共应用程序，我们不能发送client_secret ;
3. API 验证凭据并返回一些数据，例如{ "access_token": access_token, "token_type": "JWT", "expires_in": LIFE_SPAN } ，这里我们将使用JWT来生成基于 public/token 的access_token public/private key
4. 身份验证完成后，应用程序将在access_token处于活动状态时存储它，并且在它过期时将流向refresh_token 。

我的问题：它安全吗？ 斯科特·布雷迪（Scott Brady）写了一些“激进”的文章，说它永远不安全。

应用程序如何做这些事情？ 例如，当我使用 Instagram 应用程序时，他们拥有该应用程序和 API，我在用户体验流程中不需要浏览器。 现代应用程序是否使用“资源所有者密码凭据”或“使用 PKCE 的身份验证代码”？ 在使用“带有PKCE的身份验证代码”时，有一种方法可以避免在流程中插入浏览器吗？

[编辑]可能的解决方案

正如 Gary Archer 所说，“建议使用 PKCE 进行身份验证代码流 - 以及通过系统浏览器登录”，但我们并不是在谈论授予访问用户数据或第三方应用程序的权限。

作为设计师，我不同意在同一 API 所有者拥有的第一方应用程序中登录需要浏览器，这不是我们正在寻找的用户体验。 我们看到的所有应用程序，例如 Instagram、Facebook、优步……我们只需输入您的用户名和密码，就可以访问您的帐户。

我要做的是创建一个自定义版本的身份验证代码，PKCE 删除required_uri 。

[编辑：2]新流程

经过大量搜索，我找到了一些我认为很有趣的答案。 如上所述，我从流中删除了redirect_url 。 看：

1. 当用户提供您的凭据时，流程从登录屏幕开始；

2. 客户端生成一个code_verifier然后将code_verifier散列到code_challenge并使用以下参数将其发送到授权服务器：

   • response_type=code ：表示您的服务器希望收到授权码。
   • client_id=xxxx ：客户端 ID。
   • client_integrity=xxxx ：第一方应用的应用完整性检查。
   • code_challenge=xxxx ：如前所述生成的代码质询。
   • code_challenge_method=S256 ：plain 或 S256，取决于质询是普通验证器字符串还是字符串的 SHA256 hash。 如果省略此参数，则服务器将假定为plain。
   • username=xxxx ：用户名进行身份验证。
   • password=xxxx ：密码的散列版本。
   • state=xxxx ：由您的应用程序生成的随机字符串（CSRF 保护）。

3. 授权服务器将验证用户身份验证，存储code_challenge并返回带有client_token的authorization_code代码；

4. 客户端收到aauthorization_code和client_token后，保存client_token并立即使用以下参数将 authentication_code 发送回authorization_code服务器：

   • grant_type=authorization_code ：表示此令牌请求的授权类型。
   • code=xxxx ：客户端将发送它获得的授权码。
   • client_id=xxxx ：客户端 ID。
   • code_verifier=xxxx ：客户端在授权请求之前最初生成的 PKCE 请求的代码验证器。

5. 授权服务器将验证所有数据，如果一切正常，将返回access_token ；

6. 客户端将使用access_token设置授权 header 并始终将client_token发送到每个请求，只有两个值都正确才会被接受；
7. 如果access_token过期，则客户端将请求刷新access_token并获取新的。

现在，我将把这个逻辑复制到 PHP 语言中。 如果一切顺利，我希望它是正确的，我会带着明确的答案回来。

[编辑]澄清

我正在使用OAuth2与您的第三方帐户（Google、Facebook 等）进行用户连接。 但用户也可以登录到我数据库中的本地帐户。 对于这种情况，用户根本不需要授予任何东西。 因此，将用户发送到浏览器让您登录是没有意义的。

我想知道在这种情况下，对于本地帐户，我们是否可以使用资源所有者密码凭据或者更安全的 PKCE 身份验证代码（我们已经得出结论，这是一种更好的方法）。 但是带有 PKCE 的身份验证代码需要redirect_uri ，我是否需要使用此重定向将用户登录到不需要授予访问权限的本地帐户？

Answer 1

建议使用 PKCE 验证代码流程 - 以及通过系统浏览器登录。 还推荐使用 AppAuth 模式。 https://curity.io/resources/develop/sso/sso-for-mobile-apps-with-openid-connect/

但是，实施起来既棘手又耗时 - 所以你需要考虑一下 - 有时使用更便宜的选项就足够了。 取决于暴露数据的敏感性。

如果它有帮助，这里有一些关于我的 Android 演示应用程序的注释，它还关注可用性 - 并链接到您可以运行的代码示例： https://authguidance.com/2019/09/13/android-code-sample -概述/

Answer 2

首先，不要仅仅因为您需要在您的应用程序中采用它而发明 OAuth 授权。 这将使维护变得复杂。

在您的场景中，您需要提供社交登录（例如：- 通过 Google、facebook 登录）。 这当然是必须支持的所需功能。 但这并不限制您通过自定义注册过程获取最终用户凭据。 这有很多原因，例如不是每个人都使用社交媒体或谷歌帐户。 有时人们更喜欢注册而不是分享其他服务的用户标识符（是的，这是社交登录的另一端）。

所以 go 提前，提供社交登录。 首次通过外部身份服务器（例如：谷歌）登录时存储用户标识符。 而且，使用密码和 email 进行良好的旧注册步骤。

Answer 3

让我们 go 然后。 经过大量研究，我发现了一些我将应用并且可能正常工作的方法。 因此，首先，这是挑战：

• 您绝不能相信在客户端运行的客户端。 有很多担忧，您的应用程序可能被反编译，修改，用户设备可能带有恶意软件或连接可能会受到中间人攻击（MITM）的影响......
• API服务器，即使使用 OAuth2，也只能识别谁在访问资源，但不能识别正在访问的内容。 因此，任何敏感信息都是危险的，任何东西都可以窃取和使用它。
• 资源所有者密码凭证是 OAuth2 协议的一部分，用于授权资源所有者访问您的资源。 所以，它不会成为身份验证过程的一部分，如果你这样对待它，你会毁掉它；
• 通过使用 ROPC 授权类型，无法知道资源所有者是否真的在发出该请求，是什么让网络钓鱼攻击变得“容易”。 提醒“你知道谁而不是什么”。 最后，这种授权使任何假设用户身份的事情变得容易。
• 这种授权类型也违背了 OAuth2 的要求，因为 OAuth 试图避免使用密码来访问资源。 这就是为什么很多人说不要使用它的原因；
• 为了加强，重要的是要强调 ROPC 不是对用户进行身份验证，而只是授权他访问资源服务器。
• 是的，ROPC 允许刷新令牌，但有两个问题：首先，客户端每次需要重新提供凭据才能获取新令牌； 其次，如果使用长期访问代码，那么事情会变得更加危险。

为了防止恶意事物任意使用用户凭据，有访问令牌。 它们替换密码并且需要在短时间内刷新。 这就是为什么它们比 HTTP 基本身份验证要好得多的原因。

这就是为什么建议在现代应用程序中使用带有 PKCE 的身份验证代码，它提供了使用 OAuth2 协议的所有功能和优势。 但是，这里出现了一个漫长的讨论，甚至是开发者社区的问题：

要获得身份验证代码，某些用户需要在浏览器中登录，授予访问权限，重定向回客户端，很快，客户端将收到一个代码以交换访问令牌。

此方案运行良好，需要用于第三方应用程序。 但是，如果它是第一方应用程序呢？ 当您拥有包含用户数据的数据库并拥有“受信任”应用程序时，重定向用户没有任何意义。 正确的？

此刻，我的问题是：如何在不重定向用户的情况下使用 AuthCode (PKCE) 流？ 而且，再次强调，谈论 OAuth2 协议与“授予客户端访问资源服务器”（授权，而不是身份验证）始终相同，这一点很重要。

所以真正的问题是：为什么授权码需要重定向？ 然后，我得到了以下答案：

此流程需要知道客户端凭据和用户共识才能返回授权代码。

这就是我编辑错误的原因。 OAuth2 协议不需要更改（对不起，我有不同的想法）。 出于这个原因，OAuth2 需要的是在您的层之上的授权中介。 因此，授权码不会返回给客户端，而是返回给授权中介，最终将其返回给客户端。 说得通？

它将如何工作？ 那么，将需要 4 个不同的“核心”：

1. 身份验证服务器：将负责验证用户凭据和客户端身份。 主要目的是证明“谁是用户，连接什么以获得身份验证”；
2. 授权中介（OAuth2 之上的一层）：将验证客户端的唯一身份，以确保客户端/用户“知道”并且可以获得访问令牌；
3. 授权服务器：作为 OAuth2 实现的一部分，没有任何改变。 将授权客户端获取您的授权码、访问令牌和刷新令牌；
4. 资源服务器：将允许通过访问令牌访问资源。

然后，我们可以考虑的安全技术：

1. API 密钥：每个应用程序（客户端）都将拥有您自己的 API 密钥，其权限范围与这些密钥相关联。 通过使用它，您可以收集有关 API 使用情况的基本统计信息。 大多数 API 服务使用统计信息来强制每个应用程序的速率限制，以提供不同的服务层或拒绝可疑的高频调用模式；
2. 相互 SSL 身份验证：通过使用这种技术，客户端和服务器交换并验证彼此的公钥。 验证密钥后，客户端和服务器会协商共享密钥、消息验证码 (MAC) 和加密算法；
3. HMAC : API 密钥将分为 ID 和共享密钥。 然后，和以前一样，ID 与每个 HTTP 请求一起传递，但共享密钥用于对传输中的信息进行签名、验证和/或加密。 客户端和服务器将使用 HMAC SHA-256 等算法交换共享密钥；
4. 保护代码应用程序：使用代码混淆器将使从应用程序中定位和提取敏感数据变得更加困难，例如秘密共享、api 密钥、公钥......
5. 处理用户凭据：提供一种简单的方法来用户登录并证明您的身份。 插入有效凭据后，服务器可以返回用户令牌 (JWT) 并以此模拟用户 session。

让我们看一下流程：

• 第一部分：认证用户和客户端；

  1. 用户将输入您的凭据并被要求使用您的电子邮件或手机号码证明您的身份，之后客户端将发送用户凭据（例如{ email, mobile_number, hash ( password ), verification_method } ）到 Authentication Server 路由/login ；
  2. Authentication Server 将验证用户凭据并发送一次性密码给用户确认您的身份（电子邮件或手机号码由用户选择）；
  3. 然后，用户将收到的 OTP 插入，客户端将发送回 Authentication Server 路由/login-otp包括验证方法（例如{ otp, verification_method } ）；
  4. 最后，Authentication Server 将返回一个{ hash ( shared_secret ) }以便尽快使用。

• 第二部分：授权API访问；

  1. 当接收shared_secret客户端将安全地存储在移动应用程序中时，它将使用 PKCE 调用/auth请求授权码{ response_type, client_id, scope, state, code_challenge, code_challenge_method } ，授权服务器将验证凭据没有重定向；
  2. 稍后，客户端会将收到的代码交换为访问/token { payload: { grant_type, code, client_id, code_verifier }, timestamp, hash ( some_user_data + timestamp + shared_secret ) }访问令牌，但它需要发送一些额外的数据：
  3. Authorization Mediator 将收到此请求并验证尝试生成与用户生成的相同的 hash。 并将所有数据重定向到授权服务器，该服务器将验证client_id 、 code和code_verifier以访问令牌响应；
  4. 这个新的access_token将返回到 Authorization Mediator，然后返回给客户端，授予对 API 资源的访问权限。

• 第三部分：访问资源服务器；

  1. 客户端每次需要发送一个调用到 API /api包含Authorization header 和一些带有{ timestamp, hash ( some_user_data + timestamp + shared_secret ) }
  2. Authorization Mediator 将验证shared_secret哈希，调用资源服务器验证access_token并返回数据。

• 第四部分：刷新访问令牌；

  1. After access token expires, Client will send a call to /refresh-token containing the Authorization header and some extradata with { payload: { grant_type, refresh_token, client_id, scope }, timestamp, hash ( some_user_data + timestamp + shared_secret ) } ;
  2. Authorization Mediator 将验证shared_secret哈希，调用 Authorization Server 并返回一个新的新令牌访问。

此流程的视觉图像：

我不认为这是一个完美的策略，但它用 PKCE 替换了 Resource Owner Password Credentials to Authentication Code 并提供了一些额外的安全技术。 它比单一且简单的身份验证方法要好得多，它保留了 OAuth2 协议，并且更难以破坏用户数据。

一些参考和支持：

流行的应用程序如何验证从他们的移动应用程序到他们的服务器的用户请求？

为什么您的移动应用程序需要 API 密钥？

移动 API 安全技术

用于移动应用程序的安全而简单的身份验证系统：基于共享密钥的 Hash 身份验证