通过OAuth 2.0和Okta使用安全的服务器到服务器通信构建Spring Boot应用

“我喜欢编写身份验证和授权代码。” 〜从来没有Java开发人员。 厌倦了一次又一次地建立相同的登录屏幕？ 尝试使用Okta API进行托管身份验证，授权和多因素身份验证。

大多数OAuth 2.0指南都围绕用户的上下文，即使用Google，Github，Okta等登录到应用程序，然后代表该用户执行某些操作。 尽管有用，但这些指南会忽略没有用户且只有一项服务连接到另一项服务的服务器到服务器的通信。 值得庆幸的是，Okta也在此方面为应用程序安全领域提供了帮助。

OAuth 2.0客户端凭据授予类型专门用于不存在用户（CRON作业，计划任务，其他数据工作负载等）的情况。 由于没有最终用户或浏览器需要处理，因此与其他OAuth流相比，此流的显示效果不那么出色，但与以用户为中心的更为复杂的OAuth 2.0授予类型相比，该流更易于理解。 在本教程中，我们将介绍OAuth 2.0客户端凭据授予类型，以及如何在Spring Boot中部署它以实现安全的服务器间通信。

OAuth 2.0客户端凭据授予

客户端凭据授予的目标是允许两台计算机安全地通信。 在这种授予类型中，您有一个客户端（将其视为您的应用程序）向另一个服务（这是您的资源服务器）发出API请求。

为了帮助说明为什么此流程很重要，让我们退后一步，谈谈在OAuth 2.0之前所做的工作。

注意 ：如果您是OAuth专业人士，则可以跳到下面的代码示例，或在GitHub上查看示例。

在OAuth 2.0之前，开发人员处理服务器到服务器身份验证的方式是使用HTTP Basic Auth。 从本质上讲，这归结为开发人员将在每次请求时通过服务器的唯一用户名和密码（通常称为ID和机密）发送。 然后，API服务将通过连接到用户存储（数据库，LDAP等）来验证每个用户名和密码，以验证凭据。

这种方法有一些缺点和暴露点：

• 上图中的每个应用程序都处理用户名和密码
• 可能需要第二个用户名和密码才能连接到用户存储
• 每个请求使用相同的用户名和密码

有多种方法可以帮助减轻这些风险，但这超出了本文的范围。

OAuth 2.0客户端凭据授予被创建来帮助解决HTTP Basic Auth所遇到的问题。 尽管客户端仍使用用户名和密码（称为client_id和client_secret ），但不是将它们根据每个请求直接发送到API服务，而是通过授权服务器将其交换为令牌。

授权服务器返回一个临时访问令牌（使用该令牌