我是OAuth和OpenId的新手，在阅读了多个页面和信息之后，我仍然一点都不自信。
我的目标是创建一个与我的BE通信的iOS应用程序。我需要iOS应用来验证用户身份以访问其资源。
阅读有关OAuth的解决方案似乎很简单。只需使用Authorization Code Flow with PKCE即可使应用具有Access Token。这样，我就可以授权我的iOS应用访问用户数据。当iOS应用使用访问令牌调用https://example.org/user时，资源服务（我的BE服务器）可以获取访问令牌并调用自省API以知道访问令牌绑定到哪个用户，并返回正确的用户。数据。由于授权首先需要进行身份验证，因此拥有访问令牌将意味着（或至少已）对用户进行身份验证。
使我感到困惑的第一件事：根据OAuth规范，OAuth不是身份验证协议，但该协议仍使用用户的凭据对用户进行身份验证。 为什么OAuth为什么要求用户提供凭据，而不是依赖其他协议/流进行用户身份验证？这样的协议只会向OAuth确认身份验证成功。
第一个问题使我开始阅读有关Open ID Connect规范和ID令牌的信息。此令牌将由iOS应用接收。 iOS App应该如何处理？我已经可以通过调用/user端点获取用户信息。 此ID令牌将如何成为优势？
答案 0 :(得分：0)
tldr
访问令牌（OAuth 2.0）-针对受OAuth保护的授权 端点。
ID令牌（OIDC）-通过客户端应用程序进行身份验证。
OAuth不是身份验证协议，但该协议仍包含使用用户凭据对用户进行身份验证的步骤
正确，OAuth不是身份验证协议。它是用于授权的，这意味着要标识有正确的访问授权才能访问受保护的资源（受保护的资源？例如：API，后端存储的照片）。
那么为什么您会看到最终用户登录对话框？嗯，这就是授权服务器的工作。它验证最终用户知道的身份，然后向客户端发出访问令牌（简单地说，client ==最终用户使用的应用程序）。因此，是的，正在发生身份验证，但这不适用于您的客户端应用程序或受保护的端点。可以将其定义为伪认证。
OpenID Connect-用于验证客户端应用程序
在原始RFC（RFC-6749）中，OAuth 2.0被定义为框架。 OpenID Connect是基于此框架的扩展。它提供什么？正如您所发现的，它引入了ID令牌。 ID令牌由授权服务器发行，供您的客户端应用程序使用。它包含JWT格式的最终用户身份信息。通过验证此令牌的完整性，您的客户端应用程序可以验证最终用户。和访问令牌？在那里可以用来保护端点。它没有说到最终用户到客户端。