Keycloak大令牌问题、懒角色评估及客户端角色配置咨询

问题1 角色全量返回原因、合规性及模式名称 #

• 全量角色返回原因：Keycloak v11默认会给所有客户端自动绑定内置的client roles范围，对应的默认映射器逻辑是将用户所属的全部客户端角色统一注入到JWT的resource_access声明中，只要你发起认证请求时携带了默认的scope参数，就会返回全量角色数据。
• 裁剪角色的合规性：仅返回当前请求客户端对应的专属角色完全不违反OIDC规范。OIDC核心规范仅对ID令牌的iss/sub/aud/exp/iat等核心身份声明做了强制要求，角色属于自定义业务声明，规范完全不限制自定义声明的返回策略，按需裁剪属于完全合规的实现。
• 模式名称：这种实现属于最小权限令牌实践下的客户端角色细粒度映射模式，也有社区将其称为「令牌声明裁剪」模式。

问题2 权限懒评估的OIDC标准模式 #

存在成熟的标准实现方案，常用的有两种：

• 第一种是使用**RFC 7662 定义的令牌内省（Token Introspection）**机制：你可以将JWT仅保留基础身份信息，完全不包含任何角色/权限声明，微服务收到访问请求后，先调用Keycloak的内省端点/auth/realms/{你的域}/protocol/openid-connect/token/introspect，在校验令牌有效性的同时，查询用户对应当前微服务的角色权限，完成授权校验。
• 第二种是使用UMA（用户管理访问）授权模式：属于OIDC扩展的授权框架，你可以给每个微服务开启Keycloak的资源服务器能力，用户认证后仅获取包含身份信息的轻量化令牌，访问资源时由微服务的Keycloak策略执行器自动向Keycloak的权限端点发起查询，判断用户是否具备对应资源的访问权限，完全实现权限的按需懒加载。

Keycloak v11对上述两种标准模式都提供了原生支持，无需二次开发即可完成配置。

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