OAuth术语已经困扰了我很长时间。有些人会认为OAuth是授权，还是认证呢？
如果我错了，请纠正我。我一直认为授权是允许某人访问资源的行为，但是OAuth似乎没有任何实现可以真正允许用户访问给定的资源。所有的OAuth实现都只涉及提供用户一个令牌（已签名且有时加密）。然后，在对后端服务端点进行每个调用时，传递此令牌以检查其有效性，这也不是OAuth的关注点。
OAuth是认证吗？（每篇文章都说它不是），我理解认证需要用户提供凭据，从而证明用户应该/不应该访问？
因此，似乎OAuth既不是授权也不是认证，因为这些必须由其他过程执行。那么它到底是什么呢？它是一个通信令牌的过程吗？还是一个真正没有特定含义的虚词？
在这个主题上提问很难不让人听起来像是神秘和迷信的（鬼怪之类的），因此我希望回答这个问题也不会是一件简单的事情。进入需自担风险。
OAuth 2.0 是一个授权规范，但不是身份验证规范。RFC 6749 的3.1. 授权端点明确如下:
授权端点用于与资源所有者交互并获取授权票据。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如，用户名和密码登录、会话 cookie 等）超出了此规范的范围。
身份验证涉及“谁是谁”。授权涉及“谁给谁授予什么权限”。授权流程包含身份验证作为第一步。这是人们经常感到困惑的原因。
有许多库和服务使用 OAuth 2.0 进行身份验证。它通常被称为“社交登录”，这使人们更加困惑。如果您看到“OAuth身份验证”（而不是“OAuth授权”），那么它是使用OAuth进行身份验证的解决方案。
OpenID 1.0 和 OpenID 2.0 是旧的身份验证规范。制定规范的人希望人们使用 OpenID 进行身份验证。然而，一些人开始使用 OAuth 2.0 进行身份验证（而不是授权），OAuth身份验证迅速流行起来。
从OpenID的角度来看，基于OAuth的身份验证不够安全，但他们不得不承认人们更喜欢OAuth身份验证。因此，OpenID决定在OAuth 2.0之上定义新的规范OpenID Connect。
是的，这让人们更加困惑了。
OAuth 2.0 是一个框架，允许服务的用户授权第三方应用访问其托管在该服务中的数据，而无需向应用程序透露其凭据（ID和密码）。
OpenID Connect 是建立在 OAuth 2.0 框架之上的一种框架，允许第三方应用程序获取由服务管理的用户身份信息。
（抱歉，这些定义是摘自我们公司“概述”页面）
身份验证 是确定最终用户主体（=唯一标识符）的过程。确定主体的方式有很多种，如 ID & 密码、指纹、虹膜识别等。
授权 是将主体与所请求的权限及请求该权限的客户端应用程序相关联的过程。访问令牌表示关联。
OAuth是一种授权协议，它不是设计用于认证。在OAuth流程中有一个步骤，身份服务器会认证资源所有者的身份，但这发生的方式并不属于OAuth协议的范畴。因此，OAuth不关心认证。
OAuth通过向第三方（服务提供商）发放访问令牌来执行授权，该第三方可以通过呈现令牌来授权对资源的访问。
假设有一个要求，服务提供商想要代表资源所有者访问由身份服务器保护的资源。因此，资源所有者将首先进行身份验证，然后将授予服务提供商访问特定资源的权限。随后，身份服务器将为服务提供商发出访问令牌。以后，服务提供商可以使用该令牌访问资源。
在此过程中，OAuth不关心谁携带访问令牌或试图访问资源。它验证访问令牌并允许第三方访问资源。
