OAuth术语已经困扰我很长时间了。是有人建议的OAuth授权还是身份验证？
如果我错了，请纠正我，但我一直将授权视为允许某人访问资源的行为，但OAuth似乎没有任何实现实际上允许用户访问给定资源的实现。所有讨论的OAuth实现都是为用户提供令牌（已签名且有时是加密的）。然后，此令牌随每次调用传递给后端服务端点，在该端点中检查令牌的有效性，这与OAuth无关。
我是否认为OAuth身份验证（每篇文章都说不是）要求用户提供凭据，从而证明用户应该/应该没有访问权限？
因此，似乎OAuth不是授权NOR身份验证，因为这些必须由其他进程执行。那到底是什么呢？它是传递令牌的过程吗？真的没有具体含义的绒毛字吗？
不听起来神秘和迷信（鬼魂和妖精）就很难问这个问题，所以我希望回答这个问题也不是一件容易的事。输入您自担风险。
Answers:
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和密码，指纹，虹膜识别等
授权是将主题与请求的权限以及请求该权限的客户端应用程序相关联的过程。访问令牌表示关联。