如何使@OpenIdAuthenticationMechanismDefinition支持Bearer Token头认证？

@OpenIdAuthenticationMechanismDefinition 完全支持从Authorization Header获取Bearer Token，默认配置下它优先触发交互式认证流程（即重定向到Keycloak），只需调整注解参数即可切换为非交互式的Bearer Token认证模式：

• 指定认证类型为Bearer模式
  在注解中设置 type = OpenIdAuthenticationMechanismType.TYPE_BEARER，让机制优先尝试从请求头提取Bearer Token，而非跳转授权页面。

• 配置必要的OIDC元数据
  需要明确授权服务器的 issuer 地址、客户端ID、密钥以及JWKS证书地址，示例代码如下：

  @OpenIdAuthenticationMechanismDefinition(
      type = OpenIdAuthenticationMechanismType.TYPE_BEARER,
      issuer = "https://your-keycloak-server/auth/realms/your-realm",
      clientId = "your-client-id",
      clientSecret = "your-client-secret",
      jwksUri = "https://your-keycloak-server/auth/realms/your-realm/protocol/openid-connect/certs"
  )
  @ApplicationScoped
  public class OpenIdSecurityConfig {
  }
  

• 配合Jakarta Security的权限控制
  在REST端点上使用@RolesAllowed注解配置角色约束，和web.xml的security-constraint作用一致：

  @Path("/secured")
  @RolesAllowed("user")
  public class SecuredResource {
      @GET
      public Response getProtectedContent() {
          return Response.ok("Authenticated content").build();
      }
  }
  

注意事项 #

• 确保使用的WildFly版本为27及以上，该版本对Jakarta EE 10的Jakarta Security 3规范支持更完善。
• 避免同时混用web.xml的OIDC配置和@OpenIdAuthenticationMechanismDefinition注解，防止配置冲突。
• 之前web.xml的OIDC配置基于WildFly集成的Keycloak适配器，而@OpenIdAuthenticationMechanismDefinition是Jakarta Security标准API，两者底层实现不同，但均支持Bearer Token认证能力。

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