根据这里（https://oauth.net/articles/authentication/）和我遇到的许多其他事情。 OAuth不是为了处理最终用户身份验证。阅读上面的文章和其他人在搜索时从很多角度一次提供了很多信息，很难看透这一切。好的...
这是否意味着......
A）协议本身并不打算处理身份验证，因此，OAuth客户端应用应该检查“谁”可以根据OAuth提供商授权用户？
如果只有用户可以授权第三方应用，那么从OAuth提供商本身接收授权证明身份证明不是这样吗？ （如果是这种情况，那么OAuth可以从Google和Facebook这样的地方访问令牌作为身份验证吗？）
B） OAuth客户端应用无法信任使用OAuth验证用户，因此必须提供另一种声音身份验证机制吗？
如果是这种情况，那么我点击“使用[提供商]登录”（并且没有其他补充身份验证方案）的每个站点都会出现身份验证错误？
在我看来，如果只使用可信和特定的OAuth提供程序，那么此流程可以推断身份验证
然后，应用程序从提供程序请求并接收令牌，并在必要时将用户添加到应用程序数据库。
将令牌放入安全cookie或JWT并返回给用户，以便在后续访问时显示。
答案 0 :(得分：2)
OAuth2访问令牌的目的是将一些访问权限（范围）从用户委派给客户端应用程序。因此，应用程序将用户重定向到身份验证提供程序（OAuth2服务器），该身份验证提供程序对用户进行身份验证并询问用户（同意步骤）是否要将某些访问权限（应用程序请求的作用域）委派给应用程序。 / p>
如果客户端应用程序收到访问令牌，它可以在OAuth2 introspection endpoint获取其元数据 - 例如用户的用户名（资源所有者）。这样，OAuth2就可以用于身份验证。但访问令牌的主要目的是委派一些权利。例如，如果第三方应用程序想要将其数据保存到用户的Google云端硬盘，它需要一个由Google发布的访问令牌，其范围允许其访问Google云端硬盘。
如果您只想在客户端应用程序中使用OAuth2进行身份验证（以获取用户身份），您可以使用OpenId Connect（OAuth2扩展名）及其ID令牌，该令牌采用JWT格式并包含信息关于身份验证提供程序身份验证的用户。这更适合于＆＃34;登录...＆＃34;功能。