Auth0、Keycloak和Spring授权服务器，哪个更适合你的身份验证需求？

基于我最近设计新系统的经验，我经常遇到一个这样的问题，即哪个工具更适合用作IAM（身份和访问管理系统）：一个像Okta或Auth0这样的托管服务，一个像Keycloak这样的现成但可自托管的解决方案，亦或是基于 Spring 授权服务器这样的框架的自定义实现？

从根本上说，这个问题本身就错了。我们应该根据工具的实际需求和完成任务可用的资源来做出选择。

例如，像 Auth0 这样的产品只需将其集成到目标系统中。相比之下，Keycloak 是一个现成的软件包（有时甚至以 SaaS 形式提供），不仅需要配置，还需要托管、监控等维护工作。而 Spring Authorization Server 也是一个 Spring 框架的一部分。这些解决方案都使用了 OAuth 2.0 和 OpenID 协议。

因此，这个问题可以重新思考和重新表述。例如，与生态系统中已有的两个现成的解决方案相比，Spring认证服务器是否会成为一个更原生的_身份访问管理工具？或者，基于Spring认证服务器开发一个具有最小功能的自定义工具所需的开发工作，与配置Keycloak或Auth0服务相比会增加多少？

为了至少部分地回答这些问题，我建议设立3个试点，每个试点只实现3种方法中的一种最基本的形式，并且要求每种方法的搭建时间不能超过30分钟。

首先，我们将实现一个基于Spring Boot的应用程序作为客户端，该应用程序需要通过一个OAuth2服务器进行身份验证。

首先，我们需要 spring-security-oauth2-client 依赖。因为我们在使用 Spring Boot，我们将使用相应的 Spring Boot Starter.

    <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-oauth2-client</artifactId>
    </dependency>

这将使我们能够仅通过定义必要的OAuth 2.0客户端参数就与OAuth 2.0服务器集成，具体参数请参见Spring Security文档。

spring:
  security:
  oauth2:
    client:
      registration:
        auth0:
          client-id: ${OKTA_CLIENT_ID:okta-client-id}
          client-secret: ${OKTA_CLIENT_SECRET:okta-client-secret}
          scope: openid,profile,groups
      provider:
        auth0:
          issuer-uri: https://${OKTA_DOMAIN}.us.auth0.com/

我们也需要准备两个页面 index.html 和 secure.html，同时设置相应权限，使 index.html 成为一个公开页面，作为根资源的可用页面，而 secure.html 是一个仅供认证用户访问的受保护资源。

为了使用特定的OAuth 2.0提供程序，我们将使用相应的应用配置文件。在我们的例子中，这包括auth0、keycloak和spring。

您可以在我GitHub仓库的找到一个OAuth 2.0客户端应用程序配置示例。

使用每种工具的总结：

• 在平台上注册并创建一个OAuth 2.0客户端非常简单，只需几步即可完成。
• 如果你对Auth0管理面板不熟悉，配置可能会有些棘手。
• 免费版本功能有限，甚至无法测试基于角色的访问权限，更不用说为测试和生产环境创建多个环境了。
• 客户端的配置非常直接简单。

• Keycloak 基于 Docker 镜像可以轻松部署，部署过程几乎没有遇到任何困难。
• 可以在一个实例中创建多个 Realm。
• Realm 和客户端的配置简单且直观。
• 通过管理面板进行配置有很大的空间。
• 与 Auth0 相比，Keycloak 相对于 Auth0 的一个关键区别在于通过提供的 SPI 提供了扩展其功能的广泛能力。
• 客户端配置同样简单。

• Spring授权服务器是创建另一个实现OAuth 2.0（2.1）服务器功能的Spring应用的基础。
• 对于许多Spring开发者而言，使用该框架是熟悉的。从应用程序结构、依赖关系和组件角度来看，这不应该给普通开发者带来任何麻烦。
• 没有一个可以直接使用的启动包作为“开箱即用”的解决方案。Spring授权服务器本质上是一组构建块，你需要从中构建自己的独特解决方案。这需要大量的开发工作，因此可行性的问题至关重要。
• 最小配置缺乏注册和管理用户、他们的权限、组或OAuth客户端的能力。虽然提供了“开箱即用”的JDBC实现可能提供一些帮助，但显然这无法满足最基本的需求。
• 与Keycloak不同，没有预定义的SPI集，但是Spring框架本身提供了实现任何可以想象的需求的绝对自由。
• 初始配置立即导致难以诊断的错误。堆栈跟踪不会被记录，并且没有错误页面来显示错误。
• 客户端配置也存在挑战。我自己也未能在限定的30分钟内配置一个无密钥的公共客户端。

注：原文为标题形式，翻译后的中文也保留了标题形式，因此句末不加标点符号。根据此原则，最终翻译应为：

尽管我非常喜欢Spring框架，但必须得出结论，基于Spring授权服务器的方案是所列选项中工作量最大的，而且它可能很少成为最佳选择。然而，我仍然认为这个方案有巨大的潜力，我打算在后续的文章里继续探讨。