通过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服务，而是通过授权服务器来交换令牌。

授权服务器返回一个临时访问令牌（使用该令牌直到到期）。 然后，客户端在与资源服务器进行通信时使用此访问令牌，这意味着每个有效期仅在网络上共享一次客户端