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

Question

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

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

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

谢谢！

Answer 1

如果资源所有者和客户端/资源服务器角色重合，从安全角度来看OAuth 2.0可能变得不那么相关，因为OAuth的主要目标之一是不将用户的主要凭据暴露给客户端没有实际意义。这也是所谓的资源所有者密码凭证授权被认为是遗留/弃用流程的原因。

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

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

Answer 2

如果遇到以下问题，则应使用OAuth；

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

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