如果您是专业开发人员或刚开始的人，则可能遇到了Oauth 2.0。您可能已经试图了解更多有关它的信息，但发现理解有些棘手。没关系，因为Oauth 2.0可能有点像一个拼图，其中包含各种涉及技术术语和过程的拼图，这些术语和流程似乎不知所措

在这篇文章中，我将尝试浏览OAuth 2.0的核心概念，该概念将为您提供坚实的基础。我们将重点关注构成本授权协议基础的基本构建块。

在开始之前，重要的是要记住OAuth 2.0是规格，并且不提供任何具体实现。请记住，让我们开始。

在OAuth 2.0规范中，有4个主要参与者或角色。

• 资源所有者 - 是用户试图访问资源

• 客户端 - 客户端可以是浏览器，移动应用程序，桌面应用程序或任何其他应用程序。

• 资源服务器 - 仅仅是托管受保护资源（API）的应用程序的后端。用户可以使用访问令牌（例如HTTP）通过客户端通过客户端访问后端上的资源。

• 授权服务器 - 成功身份验证后向客户端访问令牌的服务器。使用访问令牌，用户可以通过客户端访问资源服务器上的受保护资源。

授权赠款

授权授予是一种凭证，可允许该客户端授权从授权服务器获取访问令牌。有几种赠款类型，但我们将讨论以下类型，因为这些是建议使用的类型。

1. 授权代码
2. 客户凭证
3. 刷新令牌

授权代码

用户通过授权服务器成功身份验证自身后，授权服务器将客户端发送授权代码。授权代码是一个钥匙或秘密。客户现在可以使用此授权代码进行邮政请求，并返回访问令牌。提出请求时，客户本身应使用授权服务器进行身份验证。

以上显示了Authoziraztion代码的授予类型的典型流程。

点要记住：

• 当用户未登录并尝试在特定URL上执行操作时，将用户重定向到登录，并将相同的URL传递给授权。

例如，用户试图在url reddit.com/r/java/post10 上对Reddit上的帖子发表评论。将用户重定向到登录页面，并将相同的URL传递给授权服务器。输入用户凭据并完成流量以获取访问令牌后，用户再次重定向到 reddit.com/r/java/post10 url。

• 登录页面不是由客户端（前端应用程序）提供的，而是由授权服务器本身提供的。

例如，当您登录到Reddit并选择要登录的Google时。选择Google帐户的登录页面由Google提供，而不是Reddit。其他OAuth 2.0登录提供商（如GitHub，Facebook，Apple等）也是如此。

• 用户的登录凭据永远不会与客户端共享。登录凭据由授权服务器直接处理。

• 成功的用户身份验证后，授权服务器发送客户端授权代码。客户端只能使用一次授权代码来获取访问令牌。客户的请求是否成功都没关系，一旦授权服务器消耗了授权代码，它就无法再使用了。

• 当客户端提出获得访问令牌的邮政请求时，客户本身必须使用Authentication Server进行身份验证，并使用某种身份验证机制（如http baisc）。

• 授权服务器同时管理用户凭据和客户端凭据。用户凭据通常是用户名和密码。客户凭据是客户端和秘密。

使用PKCE的授权代码

PKCE代表“代码交换的证明密钥”。对于将客户端凭据存储在应用程序本身中的本地客户端应用程序，它是OAuth 2.0的扩展。当客户凭证驻留在移动应用程序（例如移动应用程序）的代码库中时，可能会损害它。在Web应用程序中，客户端凭证足够安全，因为服务器上存在代码无法访问公众。但是，建议即使在Web应用程序中也使用PCKE，因为您的应用程序永远无法安全。

在处理PKCE时需要知道的两件事是验证者和挑战。验证者可以是随机的字符串，也可以是代码，挑战者是验证者的哈希值

verifier = "random string code"
challenge = hash(verifier)

让我们看看涉及的步骤

• 当用户重定向到登录页面时，客户端应用程序会生成验证者和挑战。

• 挑战将发送到授权服务器以及用于身份验证请求的用户凭据。

• 在成功身份验证并获取授权代码后，客户端提出了获取访问令牌的请求，而不是与请求一起发送客户端凭据，客户客户端将验证者发送到授权服务器。

• 现在已经有挑战的授权服务器可以通过使用哈希函数匹配的验证器与挑战相同。
  

//Authorization Server has the challenge already 
tempChallenge = hash(verifier)
if(tempChallenge.equals(challenge))
//If it is equal, client validation is successful and access token is genereated

要记住的要点：

• 验证者永远不会离开客户，因此它永远不会接触到公众。

• 函数的哈希函数和算法仅由客户端和授权服务器知道。

客户凭证

在没有用户的情况下，客户端代表其行为，可以要求访问资源服务器上的资源。例如，在微服务，监视工具和编排工具（例如Kubernetes）中的服务可以从资源服务器请求访问资源。由于这里没有用户，因此他们像客户端一样行事，并且需要客户凭据才能由授权服务器验证以获取令牌。只有这样，这些客户端才能使用令牌。

刷新令牌

我们已经看到了用户经过身份验证后获得访问令牌的流程。访问令牌始终在规定的时间之后到期，然后用户必须登录才能再次获取访问令牌。而不是再次登录用户，而是使用刷新令牌来获取访问令牌。该客户端的配置为使访问令牌过期后，它会使用访问令牌来获得新的访问令牌和刷新令牌。这发生在没有用户知道的情况下。

这些是您可以使用任何流行的OAuth 2.0提供商（例如OpenID Connect（OIDC）或KeyCloak）创建自己的OAuth 2.0授权机制的基本构建块。还有许多其他提供商可用，如果您了解了我们在这篇文章中讨论过的基本知识的基本原理，则可以轻松地与他们一起工作。

在下一篇文章中，我们将使用Spring Boot以OIDC作为实现提供商实现OAuth 2.0，并查看我们需要知道的一些端点，以验证和生成不同的令牌。因此，请务必在此帖子上关注并留下类似。