oidc-provider客户端凭证模式如何给access_token添加sub声明

问题根因 #

oidc-provider 对access_token内置保留声明有默认校验过滤逻辑：sub声明默认被绑定为用户主体标识，而client_credentials授权流不存在终端用户主体，因此框架会自动把你通过extraAccessTokenClaims传入的自定义sub值判定为非法值移除，不是接口调用方式错误。

可直接落地的解决步骤 #

• 首先在access_token的允许声明列表中加入sub，放开框架对该声明的白名单校验
• 开启client_credentials流专属的subFromClientId配置开关，告诉框架当前授权模式下sub值取客户端ID，不需要关联用户主体，框架就不会再自动过滤该声明
• 对应配置代码参考：

import Provider from 'oidc-provider';

const provider = new Provider('你的认证服务发行者地址', {
  // 其余已有配置保持不变
  claims: {
    access_token: {
      sub: null, // 将sub加入access_token允许返回的声明列表
      // 其余你需要返回的声明按原有逻辑配置即可
    }
  },
  features: {
    clientCredentials: {
      subFromClientId: true, // 核心开关：允许client_credentials模式下用clientId作为sub值
      // 其余clientCredentials相关配置保持不变
    }
  },
  // 如果你还有其他自定义access_token声明的逻辑，原有extraAccessTokenClaims代码保留即可
  // 不需要再在这个方法里额外给sub赋值，开启上述开关后框架会自动填充sub为对应clientId
});

• 配置完成后重启服务，重新调用client_credentials授权接口生成access_token，解码后即可看到sub声明已正确填充为对应客户端的clientId，符合RFC 7523规范要求。

避坑提示 #

不要通过强行篡改token生成生命周期钩子的方式硬写sub值，这种方式会绕过框架的一致性校验，后续调用令牌校验、令牌刷新接口时会出现sub值丢失、权限校验不通过的问题，用官方预留的配置开关是无兼容风险的最优方案。

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