如果客户端与资源所有者相同，OAuth 2.0 是否多余/不必要？

Question

在 RFC 6749 的 1.1 部分，有四种角色：资源所有者、资源服务器、客户端和授权服务器。

如果客户端和资源所有者是同一实体，OAuth 是否会变得多余或不必要？

例如，我有一个封闭的 API 和一个面向前端的 Web 服务器。 （面向前端的 Web 服务器既是客户端又是资源所有者。）我正在尝试决定是否切换到 OAuth 2 身份验证，而不是使用当前的用户名/密码身份验证方法。如果 API 对第三方应用程序仍然关闭，那么迁移到 OAuth 2 是否有任何额外的安全性？ （也就是说，任何第三方都无法访问 API。）

谢谢！

Answer 1

在资源所有者和客户端/资源服务器角色重合的情况下，从安全角度来看，OAuth 2.0 的相关性可能会降低，因为 OAuth 的主要目标之一是不向客户端公开用户的主要凭据成为没有实际意义。这也是为什么所谓的 Resource Owner Password Credentials 授予被认为是遗留/弃用流程的原因。

但是，出于多种原因，遵循 OAuth 2.0 模式可能仍然有意义：

• 通过库存库利用标准化协议的能力和 无需依赖自定义代码的框架
• 事实上，在您的情况下，资源服务器仍然严格遵守 OAuth 2.0，处理呈现访问令牌的客户端，无论客户端/资源所有者关系/实现是什么；这将更容易在未来的场景中允许第三方客户端访问
• 事实上，您将用户凭据的验证集中在客户端和授权服务器之间的单个路径上，因此您的每个资源服务器都不需要单独检查用户凭据，可能会处理不同的身份验证机制
• 也许最重要的是安全方面：一旦用户使用他的主要凭据通过客户端进行身份验证，授权服务器就可以发出刷新令牌和访问令牌；当旧的访问令牌过期时，客户端可以将刷新令牌存储并使用到新的访问令牌；如果客户端想要在不需要显式用户交互和身份验证的情况下长时间访问 API，这可以让客户端从存储主要用户凭据中解放出来，并且使生成的系统不易受到用户凭据泄漏/丢失的影响，因为用户凭据 (密码）不存储在客户端中

Answer 2

如果您有以下问题，那么您应该使用 OAuth；

假设您是 Gmail 之类的网络邮件提供商。您的一些用户正在使用第三方应用程序，该应用程序登录到您的用户帐户并自动为您回复某些电子邮件。或者您是 Facebook 之类的社交网络网站，您的一些用户使用第三方应用程序分析您的朋友网络并为您打印 2D 图表。在这种情况下，您的用户会泄露他们的用户名和密码。在他们泄露用户名和密码后，他们将如何阻止某个第三方应用访问他们的帐户？只需更改他们的密码。现在你有另一个问题；其他第三方应用程序将无法访问用户的帐户。然后用户必须将他的密码重新提供给他信任的其他应用程序。现在这也是个问题，因为它对用户不友好。 OAuth 只是您的用户提供给第三方应用程序开发人员的临时密码。他可以随时撤销它而无需更改自己的密码。

除此之外 OAuth 是不必要的。如果您不打算聘请第三方应用程序开发人员，只需使用会话 cookie。它是存储在用户端的随机字符串。并且在服务器端将拥有您想要的任何东西。看看 PHP 会话是如何在服务器端使用和存储的。您可以从 php.ini 中自动定义它们的生命周期和刷新时间。