基于FAPI 1的OIDC Provider中PAR阶段扩展校验的方案咨询

完全不需要fork库，node-oidc-provider本身提供了多个扩展点来实现PAR阶段的自定义校验逻辑，以下是两种常用方案：

方案1：给PAR端点添加前置中间件 #

通过配置routes.par.beforeHandlers，在官方PAR处理逻辑之前插入自定义校验代码，比如调用外部API检查客户端的额外注册信息：

const Provider = require('oidc-provider');

const provider = new Provider('http://your-oidc-domain.com', {
  routes: {
    par: {
      beforeHandlers: [
        async (ctx, next) => {
          // 获取当前认证的客户端实例
          const client = ctx.oidc.client;
          // 调用外部API校验客户端额外信息
          const isExtraInfoValid = await checkClientExtraRegistrationInfo(client.clientId);
          
          if (!isExtraInfoValid) {
            // 返回符合OIDC规范的错误响应
            ctx.throw(400, 'invalid_client', 'Client extra registration info does not meet requirements');
          }
          
          // 校验通过，继续执行官方PAR逻辑
          await next();
        }
      ]
    }
  },
  // 其他OIDC Provider配置...
});

方案2：利用客户端认证后钩子 #

PAR阶段首先会完成客户端认证，你可以通过postClientAuthentication钩子在认证完成后、PAR核心逻辑执行前加入校验，还能限定只对PAR请求生效：

const provider = new Provider('http://your-oidc-domain.com', {
  hooks: {
    postClientAuthentication: async (ctx, next) => {
      // 仅针对PAR请求执行自定义校验
      if (ctx.path === '/par') {
        const client = ctx.oidc.client;
        const valid = await yourExternalApiCheck(client);
        
        if (!valid) {
          ctx.throw(401, 'unauthorized_client', 'Client not allowed to use PAR based on extra checks');
        }
      }
      await next();
    }
  },
  // 其他OIDC Provider配置...
});

为什么不推荐fork？ #

fork库会带来长期的维护负担：后续官方版本的功能更新、安全补丁都需要手动合并，容易出现冲突和遗漏。而官方提供的扩展点正是为了适配这类自定义业务逻辑设计的，完全满足你的需求，是更符合最佳实践的方案。

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