直接使用access_token时Keycloak授权失败(403-Forbidden)
排查Keycloak保护Servlet返回403 Forbidden的问题
看起来你已经走完了基础配置流程,但还是遇到了权限拒绝的问题,咱们从几个核心方向一步步排查:
1. 检查客户端角色与用户权限分配
这是403问题的最常见原因,Keycloak的权限控制核心是角色匹配:
- 登录Keycloak控制台,进入
demo领域的dummy客户端,切换到Roles标签,确认你需要的角色(比如dummy-access)已经创建 - 切换到Users标签,找到
demo用户,进入Role Mappings,确保该用户已经被分配了dummy客户端下的对应角色(注意是客户端专属角色,不是领域角色) - 如果你给Servlet加了
@RolesAllowed("admin")这类注解,必须确保用户拥有对应的角色才能通过验证
2. 验证Access Token的内容是否符合要求
你能通过密码模式拿到token,但要确认这个token包含了正确的权限信息:
- 把拿到的
access_token复制到JWT解析工具(比如本地打开jwt.io页面),重点查看以下字段:aud:受众必须包含dummy客户端的ID,否则Keycloak适配器会判定这个token不属于当前应用resource_access.dummy.roles:这里必须包含你给用户分配的客户端角色,这是适配器判断权限的核心依据scope:确保包含dummy或openid等必要范围,部分配置下缺少scope会导致权限验证失败
3. 检查Keycloak适配器的配置细节
确认keycloak.json和Tomcat的适配器配置没有遗漏:
keycloak.json里的resource必须和Keycloak控制台里的dummy客户端ID完全一致- 如果你的应用是纯后端服务(仅用Bearer token访问),确保
bearer-only设置为true,避免适配器尝试重定向到登录页面 - 检查Tomcat的
conf/context.xml,是否添加了Keycloak Realm的配置,示例如下:<Realm className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/> - 别忘了把Keycloak的Tomcat适配器jar包放到Tomcat的
lib目录下,并且重启Tomcat让配置生效
4. 确认Web应用的安全约束配置
检查web.xml里的安全规则是否和角色匹配:
- 确保
<security-constraint>里的<role-name>和token中的角色一致,示例:<security-constraint> <web-resource-collection> <web-resource-name>Dummy Servlet</web-resource-name> <url-pattern>/dummy</url-pattern> </web-resource-collection> <auth-constraint> <role-name>dummy-user</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>demo</realm-name> </login-config> <security-role> <role-name>dummy-user</role-name> </security-role> - 如果用了注解式权限控制,要确保Tomcat开启了注解支持,或者在
web.xml里声明了对应的角色
5. 检查Keycloak客户端的跨域与访问设置
如果请求涉及跨域或端口不匹配,可能会导致验证失败:
- 在Keycloak的
dummy客户端设置里,Valid Redirect URIs和Web Origins要包含http://localhost:8081/*(本地测试可直接填*) - 确认客户端的Access Type设置正确:后端服务用Bearer token的话,选
confidential或bearer-only;前端应用可选择public
先从这几个方向排查,尤其是角色分配和token内容,这两个是403问题的高频原因。如果还是解决不了,可以把token解析后的关键字段(隐去敏感信息)和keycloak.json的核心配置贴出来,方便进一步分析。
内容的提问来源于stack exchange,提问作者Edwin
相关产品推荐
相关产品推荐

