将Keycloak隐藏在API网关后的可行性与实现方案咨询

一、把Keycloak藏在API网关后的方案合理吗？ #

完全合理，这是后端服务隐藏的常规架构设计，主要为了统一请求入口、对外屏蔽技术栈细节，还能降低Keycloak直接暴露在外被攻击的风险。但要注意几个关键点：

• 网关得正确转发OAuth流程里的跳转请求，比如Google OAuth的回调地址要指向网关，再由网关转发给Keycloak
• 要处理好Cookie、Token这类数据的传递，避免认证流程中途中断
• 网关要配置好跨域规则，确保UI的请求能正常到达

二、大厂怎么处理登录注册流程？ #

Facebook、LinkedIn、Stack Overflow这类大厂基本不会直接用Keycloak这种开源组件，都是自研核心认证服务，但架构逻辑和你设想的一致：

• 所有认证请求统一走API网关入口，网关负责路由、限流、基础安全校验
• 内部有专门的认证服务处理账号密码校验、第三方OAuth对接（比如和Google、Facebook的登录集成）
• 第三方OAuth的回调地址直接指向网关，再由网关转发给内部认证服务完成后续流程
• 最终返回的Token（比如JWT）要么由网关统一处理，要么直接转发给UI

他们自研的核心原因是：业务复杂度高（多平台、多账号体系、定制化规则多）、性能要求极高，且需要深度整合内部其他系统，开源组件无法完全满足这些需求。

三、该自研认证服务还是给Keycloak加代理？ #

优先选「API网关+Keycloak转发/代理」方案 #

如果你的业务没有特别复杂的定制需求，别轻易自研，理由很实在：

• Keycloak已经把账号密码管理、OAuth2/OpenID流程、权限控制这些核心功能做成熟了，自研等于重复造轮子，还容易踩安全漏洞
• 具体实现步骤：
  • 在API网关配置路由规则，将UI发起的登录/注册/OAuth相关请求转发到Keycloak对应接口
    • 比如UI请求/api/auth/login，网关转发到Keycloak的Token接口http://keycloak-internal/realms/{你的领域}/protocol/openid-connect/token，用password授权类型完成账号密码登录
    • 触发Google OAuth时，UI请求/api/auth/oauth/google，网关重定向到Keycloak的授权端点，Keycloak再跳转到Google登录页；Google回调时指向网关的回调端点，网关再转发给Keycloak的回调接口，最后把Token返回给UI
  • 网关要做好请求头、参数的透传，UI发过来的参数原样转递给Keycloak，Keycloak的响应也原样返回给UI
  • 给Keycloak的客户端配置允许网关的请求：把Valid Redirect URIs设为网关的回调地址，Web Origins设为UI的域名
• 注意事项：
  • 把Keycloak的访问权限锁死，只允许网关的内部IP访问，禁止外部直接连接
  • 网关要留存请求日志和监控，方便排查认证流程中的问题

什么时候该自研？ #

只有出现以下情况时，再考虑自研认证服务：

• 业务有高度定制化的认证规则，比如多租户的复杂权限、特殊的账号关联逻辑
• 需要和内部已有系统深度整合，比如企业内部的LDAP、CRM账号同步
• 对性能有极致要求，比如百万级并发登录，Keycloak的性能无法满足

四、补充几个关键流程的实现细节 #

• 账号密码登录：通过网关转发Keycloak的token接口，UI将用户名密码发给网关，网关转递给Keycloak，拿到Token后返回给UI
• 第三方OAuth登录：UI请求网关的OAuth触发端点，网关重定向到Keycloak授权端点，Keycloak跳转到第三方登录页；第三方回调到网关，网关转发给Keycloak的回调接口，最终Token由网关返回给UI
• 注册流程：转发Keycloak的用户创建接口（需要用有管理权限的客户端调用），UI将注册信息发给网关，网关转递给Keycloak完成用户创建

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