OAuth2.0 Spring Security下Keycloak外部资源服务器对接防护问询

很多人第一次接触这套配置都会有个误解：以为知道issuer-uri就能随便把自己的资源服务器接进来用你的Keycloak当认证源。实际上完全不是——Spring资源服务器的自动配置流程，全程都是只读拉取Keycloak暴露的公开元数据：比如拉取.well-known/openid-configuration接口拿到公钥地址，再拉取公钥用来校验后续传入的JWT合法性。
这些元数据本来就是设计为公开可访问的（不然合法的前端、资源服务器根本没法完成JWT校验），整个过程没有涉及任何向Keycloak申请权限、注册客户端、获取签发token能力的交互。外部主体就算拿到了issuer-uri，最多也就拿到公钥和元数据，根本没法“使用你的认证服务器”——真正的滥用风险，从来都不在Spring的自动配置上，而在Keycloak本身的权限配置疏漏。

所有方案都是针对真实的滥用风险点设计的，没有多余的复杂配置：

• 从根源锁死Keycloak的客户端创建权限
  彻底关闭Keycloak的公共客户端注册能力，禁止普通用户、未授权的外部主体自助创建客户端、自助获取token。所有需要接入认证体系的客户端、资源服务器标识，必须由管理员手动审核、手动创建，不开放自助接入通道。这是避免认证服务器被滥用的最核心动作——如果Keycloak本身谁都能进去建客户端发token，再严格的资源服务器配置都挡不住滥用。
• 给资源服务器强制加受众（aud）白名单校验
  Spring Security默认的JWT校验逻辑，仅会校验token的issuer是否和配置的issuer-uri匹配，不会强制校验JWT的aud（受众）字段。你需要在资源服务器配置中明确指定允许的受众列表，示例配置如下：

  spring:
    security:
      oauth2:
        resourceserver:
          jwt:
            issuer-uri: <your-keycloak-uri/realms/your-realm>
            audiences:
              - your-official-api-identifier
  

  配置生效后，所有传入的JWT必须携带匹配该列表的aud字段才能通过校验。外部主体就算能在你的Keycloak里偷偷创建客户端签发token，只要他们的token不携带你预设的、专属的受众标识，根本过不了资源服务器的校验，自然没法把自己的应用接入你的认证体系。
• 给Keycloak的元数据端点加网络访问控制
  Keycloak的OIDC元数据端点（也就是issuer-uri对应的.well-known/openid-configuration、公钥获取端点）不需要暴露给全互联网可访问，可以通过防火墙、反向代理配置IP白名单，只允许你自己部署的资源服务器、前端应用的出口IP能拉取这些元数据。外部主体连元数据都拿不到，自然没法完成对应的自动配置流程。
• 收紧Keycloak内置公共客户端的权限
  检查Keycloak默认开放的公共客户端（比如内置的account客户端），关闭其不必要的scope权限，禁止这些公共客户端签发携带你专属资源受众的token。

外部主体就算真的按照你的issuer-uri搭了个一模一样的资源服务器，只要他们拿不到能通过aud校验的合法JWT，这套配置就是个完全空转的壳，既调不到你的业务接口，也消耗不了你Keycloak的任何签发资源，根本谈不上“滥用认证服务器”。真正需要防的，是攻击者利用Keycloak开放的自助注册能力拿到token，去扫你暴露在公网的业务接口——上面提到的aud白名单机制，刚好也是防这类接口扫描的最有效手段。

内容的提问来源于stack exchange，提问作者vgm