第一：
如果你能记住这个看似微妙的信息，这将需要你很长的路要走。

• OAuth*
  *是一个 * 授权 * 框架
  *Notan Authentication framework.

OAuth为您获取访问令牌，该令牌赠款您访问某些受保护资源的权限。这些资源由某个用户拥有。该令牌证明该用户/所有者已 * 授权 * 您的应用访问这些资源。
但是，OIDC 是一个身份验证框架**。
事实上，它是专门构建的，因为OAuth不是一个身份验证框架。而且，OIDC 是构建在OAuth 2.0之上的。
如果您的应用正在执行身份验证，您还需要确保使用OIDC（你可以在没有OIDC的情况下使用OAuth，但你不能在没有OAuth的情况下使用OIDC）。OIDC引入了一个过程，它可以在OAuth流上提供有关该用户/所有者的信息。具体来说，ID令牌和/userinfo端点可以用于识别用户，通过授权服务器（在本例中为Spotify）进行身份验证的服务器。
第二：
第一步的细节很重要。
现在的best practice是对授权代码流（您已经在使用）的补充，PKCE是对原始OAuth规范的后期“升级”。最初用于公共客户端（SPA，本地应用程序），它对私有客户端（具有服务器组件的Web应用程序）的某些攻击也很有用。
对于机密客户端，建议使用PKCE [RFC 7636]，因为它提供了强大的保护，防止滥用和注入授权代码，如第4.5.3.1节所述，并且作为副作用，即使在存在强大攻击者的情况下也可以防止CSRF，如第4.7.1节所述。
第2.1.1节（并参考其他相关章节）授权代码授予类型
这里有一点要介绍，提供了几行代码来集成，但是它应该让您给予一个关于要查找哪些资源的想法。
一些快速链接：
Spotify's docs on Authz Code with PKCE的
Spotify的操作指南，带PKCE和获取用户信息的Authz Code分步实现
Spotify在这里实际上有点作弊，并没有严格按照预期使用OAuth和OIDC。他们使用OAuth来获得用户的授权以访问.关于该用户的信息。这在技术上不同于知道认证和授权访问的用户的身份。但是，这似乎是他们这样做的方式。OAuth/OIDC很难，它的实现会有所不同，即使是在一些最大的公司。
为了更深的潜水。
将OAuth混淆为身份验证框架是常见的，有几个原因，但这里有一些 * 我 * 看到最多的：

• 人们经常错误地将其称为用于身份验证（就像您提供的SO链接中的用户那样）
• 在OAuth流程中需要进行身份验证
  *OIDC是一个认证框架，构建在OAuth 2.0之上。

第二个问题可能会让你感到困惑，即使你已经多次阅读规范并理解了OAuth 2.0流程中的步骤。需要理解的基本问题是，使用OAuth，你的应用（客户端）要求用户授权其访问用户拥有的一些受保护的资源。为了做到这一点，而不仅仅是从一开始就存在巨大的安全漏洞，我们希望实际获得这些资源的实际用户/所有者的授权。为此，用户在授权服务器上进行身份验证。但是，这完全在OAuth本身之外。只是OAuth的一种依赖。当您获得访问令牌时，您实际上并不知道谁是经过身份验证并给予访问权限的用户。您相信授权服务器完成了它的工作。
对于身份验证，您需要知道授权的用户是谁，而不仅仅是真实的用户。这看起来很微妙，但它是一个大问题。OIDC就是为了解决这个问题而构建的。OIDC本质上为您的应用提供了一种方法，让您知道授权访问的是谁，而不仅仅是授权访问的是什么。