我花了几个小时阅读有关Oauth2协议的内容。根据我的理解，该协议的主要动机是资源所有者不必与第三方（客户端）应用程序共享其凭据，仅与资源服务器共享。
在这篇文章中，我使用了Oauth2 RFC中定义的角色。但是我没有区分资源服务器和授权服务器。我假设它们是相同的，它们是相同的，并将它们称为“资源服务器”。
我可以看到两个不同的事件链。假设两个方案都以资源所有者开始，其目的是让客户端访问受保护资源。
案例1，资源服务器提供的GUI
1.客户端将资源所有者转发到资源服务器的登录页面
2.资源所有者在资源服务器的GUI上提供他/她的凭证
3.成功时，资源服务器将资源所有者转发给客户端，并为用户客户端提供令牌。
案例2，客户提供的GUI
1.客户要求资源所有者将其凭证提供给自己的GUI
2.客户端将提供的凭据发送到资源服务器
3.成功时，客户端获取令牌并访问资源服务器。
我关心的是案例2.如果客户端作为客户端进行身份验证而不是作为资源所有者进行身份验证，那么客户端获取资源服务器上的完全权限有多难？ RFC声明以下内容是使用OAuth2而不是让客户端处理资源所有者凭据的原因：
“第三方应用程序获得对资源的过度广泛访问 所有者的受保护资源，使资源所有者不受任何影响 能够限制持续时间或访问有限的子集 资源“。
RFC进一步声明：
“存储资源需要第三方应用程序 所有者的凭据以供将来使用，通常是密码 明文“。
在案例2中，客户可以很好地保存它。
那么......你能否假设一个实现Oauth2的客户端（在案例2中）比那个没有的客户端更安全？资源服务器是否可以实现防止这些事情的机制？
答案 0 :(得分：0)
考虑案例2：
让我们说资源所有者已经向客户提供了他/她的凭据，正如您所说，客户端必须以明文形式将密码存储在某处。
1）但我们是否可以信任客户，未经您的许可不得访问任何信息？ 2）如果某人攻击客户端数据库并访问可能包含网络密码等敏感信息的所有凭据，该怎么办？，?? ??
为了防止出现这些安全问题，资源所有者直接处理资源服务器并为客户端设置权限，以便只访问它想要的信息，而不是更多。然后服务器向客户端发出一个令牌（如门禁），每当客户端需要一些信息时，它就必须发送令牌。
因此出于安全原因，最好不要向客户提供我们的凭据。
答案 1 :(得分：0)
您可以假设使用正确的OAuth2实现，您的系统比传统的基于用户/通道的系统更安全。
案例1显然更优越，因为没有用户凭证暴露给客户端。
案例2只是一种可能性，许多OAuth2提供商根本不支持它。即使标准不鼓励使用它，它似乎只是作为一个后备，当仍然必须使用普通的旧用户/通过逻辑时出于某种奇怪的原因。由于客户端应用程序可能根本不存储您的凭据，因此这种情况仍然稍微好一些。创建OAuth请求后，可以立即删除指定的凭据，并且只应存储授予的令牌。获得刷新令牌，无需再次请求您的用户/通行证。
请注意，从应用程序中窃取令牌仍然存在安全风险，但窃贼不会拥有您的凭据的完全权限，只会拥有您授予应用程序的访问权限。此外，访问令牌过期，提供者应支持撤销刷新令牌。