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