如何在不使用公共客户端或BFF模式下用KeyCloak保护授权服务器？

我已配置好一个OAuth2资源服务器，与Ch4mpy的Spring Addons示例类似，使用KeyCloak作为OIDC Provider。目前通过Postman等工具可正常向KeyCloak请求JWT，并基于RBAC访问授权资源。

但在对接前端与后端时遇到瓶颈：系统包含多个B2B、B2C应用及各类前端界面，现有主流方案均不可行：

• 为无密钥存储能力的前端使用public client：安全性不足
• 为每个前端部署一对一BFF：服务器部署成本过高

我计划实现一个具备高权限的confidential client后端，作为所有前端与KeyCloak之间的中间层，但面临以下核心问题：

1. 如何保护该中间层后端，防止未授权请求访问？
2. 中间层作为代理时，认证流程具体如何运作？
3. 如何在该架构中集成Google、Apple这类第三方IDP？

综上，如何在不使用public client或一对一BFF client的情况下，通过KeyCloak实现前端到后端的授权保护？

1. 保护中间层后端 #

将中间层同时配置为OAuth2资源服务器，通过以下措施防护：

• 强制前端请求必须携带HTTP-only会话Cookie，该Cookie由中间层在用户认证完成后签发，绑定用户身份
• 为中间层的授权相关接口（令牌获取、刷新等）配置RBAC，仅允许已认证用户调用
• 启用CSRF防护，避免跨站请求伪造攻击
• 严格配置Cookie属性：设置SameSite（根据前端部署场景选择Lax或Strict）、限制域名范围、标记为HTTP-only禁止JS读取

2. 中间层代理的认证流程 #

采用Authorization Code Flow + PKCE，以中间层作为前端与KeyCloak的代理，流程如下：

1. 前端跳转至中间层的认证入口，中间层生成PKCE挑战参数，随后重定向至KeyCloak授权端点，携带自身的confidential client ID与PKCE参数
2. 用户在KeyCloak完成认证（账号密码或第三方登录）后，KeyCloak重定向回中间层的回调端点
3. 中间层使用自身的client secret结合PKCE验证器，向KeyCloak请求访问令牌、刷新令牌与ID令牌
4. 中间层生成绑定用户身份的HTTP-only会话Cookie，可将必要用户信息（如角色）返回前端或存储于服务器端会话
5. 前端后续请求后端资源时，携带会话Cookie访问中间层，中间层使用持有的访问令牌调用后端资源服务器，并将结果返回前端
6. 访问令牌过期时，中间层自动使用刷新令牌向KeyCloak获取新令牌，前端无感知

3. 集成第三方IDP（Google/Apple Sign-In） #

利用KeyCloak的身份提供者功能完成集成，无需修改中间层逻辑：

• 在KeyCloak控制台添加Google/Apple身份提供者，配置对应平台的客户端ID、密钥等参数
• 开启KeyCloak登录页面的第三方登录选项，允许用户选择第三方账号登录
• 中间层的认证流程保持不变，KeyCloak会处理与第三方IDP的交互，中间层仅需与KeyCloak通信
• 若需自定义第三方登录入口，前端可直接跳转至中间层认证入口，中间层重定向至KeyCloak时携带kc_idp_hint参数，直接触发对应第三方IDP的登录流程

关键注意事项 #

• 中间层需实现令牌生命周期管理：缓存访问令牌减少KeyCloak请求频率，定期清理过期的刷新令牌与会话
• 前端无需存储任何OAuth2令牌，所有令牌由中间层统一保管，降低泄露风险
• 跨域场景下，中间层需配置CORS规则，允许前端域名的请求并支持Cookie携带

内容的提问来源于stack exchange，提问作者J. M. Arnold