Quarkus OIDC扩展服务校验场景下ID Token验证配置问题咨询

适用场景：使用Quarkus OIDC扩展做服务端权限校验，不触发OIDC授权流程，仅对请求携带的Token做合法性校验的 Bearer-only 模式

自定义请求头中ID Token的校验支持 #

支持，无需自定义拦截器实现。
直接通过配置项指定Token读取的请求头即可，对应配置为quarkus.oidc.token.header，要读取x-id-token头的场景直接添加如下配置：

quarkus.oidc.token.header=x-id-token

如果自定义头中直接传递Token字符串、没有Bearer 前缀，再额外配置quarkus.oidc.token.header-scheme=（赋值为空）即可。配置完成后，扩展会自动对该头内的Token执行完整校验逻辑：包括签名验证、有效期校验、发行方校验、受众校验，和标准Authorization头的Token校验逻辑完全一致。
如果需要同时兼容标准Authorization头和自定义头的Token传递，可以配合多租户能力，按请求路径或者租户标识分别指定不同的Token读取头。

ID Token自定义声明的直接获取 #

可以直接通过SecurityIdentity组件获取，默认不会触发UserInfo端点调用。
只要ID Token校验通过，Token内携带的所有声明（包括标准声明和自定义扩展声明）都会被自动加载到SecurityIdentity的属性集合中，代码中直接注入SecurityIdentity即可读取：

@Inject
SecurityIdentity securityIdentity;

public Object getCustomClaim(String claimName) {
    return securityIdentity.getAttributes().get(claimName);
}

如果习惯用JsonWebToken接口读取声明，也可以直接注入JsonWebToken实例，校验通过后的实例就是解析完成的ID Token对象，直接调用getClaim(String name)方法即可获取对应声明值。
只有显式配置quarkus.oidc.authentication.user-info-required=true时，扩展才会主动调用UserInfo端点拉取用户信息，纯Token校验场景保持该配置默认关闭即可。

ID Token中groups声明的角色映射 #

该需求可以实现。
之前配置quarkus.oidc.roles.source=idtoken不生效，通常是两个原因：

• 使用的Quarkus版本低于2.13，早期版本确实存在idtoken角色源仅对OIDC客户端场景生效的问题，升级到2.13及以上的稳定版本即可修复
• 没有配置角色对应的颁发者，扩展默认会校验角色声明的颁发者和访问令牌颁发者一致，从ID Token提取角色时需要显式指定颁发者和ID Token颁发者匹配

完整配置参考如下：

# 指定角色提取来源为ID Token
quarkus.oidc.roles.source=idtoken
# 指定角色声明的颁发者，和你的OIDC服务端颁发ID Token的iss值一致即可
quarkus.oidc.roles.issuer=${quarkus.oidc.auth-server-url}/realms/你的租户标识
# 如果groups声明不在Token根路径，通过该配置指定JSON路径，比如groups在realm_access.roles路径下就配置对应值
# quarkus.oidc.roles.role-claim-path=realm_access.roles

配置完成后，ID Token中的groups声明会被自动解析为SecurityIdentity中的角色集合，不管是用@RolesAllowed做接口权限校验，还是用@RolesMapping做角色名转换，都可以直接使用。

官方文档场景混杂的问题 #

不是你的理解偏差。
当前Quarkus OIDC扩展的文档没有按部署场景做严格拆分，同一个文档页同时覆盖了三类部署模式的配置说明：纯Token校验的服务端模式、需要引导用户登录的OIDC客户端模式、服务端+客户端混合模式。文档没有给配置项做场景标签，所以会出现服务场景指南里混杂大量授权流程、回调地址、登录页面等客户端专属配置的情况。
你在纯Token校验场景下配置时，只要忽略和登录跳转、回调地址、会话持久化相关的配置项即可，其余Token校验、声明映射、角色提取、多租户、密钥自动轮换相关的配置，都完全适用于纯Token校验的服务场景。

Quarkus OIDC的多租户能力确实是对比SmallRye JWT的核心优势，原生支持按请求路径、域名、请求头、租户标识动态加载不同租户的OIDC配置，不需要自行实现租户解析、密钥隔离的逻辑，在多租户场景下开发效率提升非常明显。

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