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

在RFC6749部分中，有四个角色：资源所有者、资源服务器、客户端和授权服务器

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

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

---

谢谢

在资源所有者和客户机/资源服务器角色重合的情况下，OAuth 2.0从安全角度看可能变得不那么相关，因为OAuth的主要目标之一是不向客户机公开用户的主要凭据变得毫无意义。这也是所谓的资源所有者密码凭据授予被认为是遗留/不推荐的流的原因

但是，出于以下几个原因，遵循OAuth 2.0模式仍然有意义：

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

---

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

---

除此之外，OAuth是不必要的。如果没有第三方应用程序开发人员，只需使用会话cookie即可。它是存储在用户端的随机字符串。服务器端会有你想要的任何东西。看看PHP会话是如何在服务器端使用和存储的。您可以从php.ini自动定义它们的寿命和刷新时间。
谢谢！只是想讨论一下。我真的很感谢你的反馈！