如何为自带登录表单的SPA配置Keycloak及Quarkus后端相关疑问

一、自定义登录表单的替代方案（避免使用Direct Grant） #

Direct Grant（资源所有者密码凭证流）不推荐在公开客户端（SPA对应的前端客户端）使用的核心原因是：公开客户端无身份校验凭证，攻击者拿到client_id即可发起暴力破解账号密码的攻击，安全风险极高。
你期望的前端提交登录凭证→后端代理认证→返回JWT的流程完全可以实现，是目前兼顾自定义登录页需求和安全性的主流方案，操作逻辑如下：

• 保留你当前的两个客户端配置：SPA对应public类型的客户端仅用来后续传递JWT，不做认证请求；Quarkus后端对应的confidential类型客户端backend-service用来发起认证请求
• 前端自定义登录页收集用户名、密码后，通过HTTPS提交到你自己的Quarkus后端接口
• 后端拿到账号密码后，以confidential客户端的身份向Keycloak发起资源所有者密码流请求，请求时需要携带client_id、client_secret以及前端传递的用户名、密码
• Keycloak认证通过后返回access_token、refresh_token，后端可直接将令牌返回给前端，前端后续请求携带JWT访问受保护资源即可

二、Quarkus OIDC配置秘钥注释后仍正常运行的原因 #

你当前的配置可以正常运行，是因为Quarkus的OIDC模块在作为**资源服务器（仅校验传入请求的JWT合法性）**时，不需要和Keycloak进行客户端身份认证：

• Quarkus启动时会从你配置的quarkus.oidc.auth-server-url对应的Keycloak Realm地址拉取JWKS公钥列表，后续收到前端带的JWT时，直接用本地缓存的公钥校验JWT的签名、过期时间、受众等信息即可完成鉴权，这个过程不需要用到client_secret。

client_secret的实际作用 #

只有当你的Quarkus后端需要作为OAuth2客户端主动向Keycloak发起受保护的请求时，才需要配置client_secret，常见场景包括：

• 代理前端登录请求，向Keycloak申请令牌
• 调用Keycloak的Admin API对用户、权限进行管理
• 使用refresh_token向Keycloak换取新的access_token
• 对接授权码流等需要客户端身份校验的流程

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