如何高效处理多个IDP下发的不透明访问令牌的鉴权问题

最优方案：认证成功后下发自托管JWT #

这是大流量业务的通用落地方式，可完全解决现有痛点：

• 用户首次通过Google/Apple的access token登录时，你先调用对应IDP的userinfo接口完成身份校验，确认合法后，直接由你的后端服务签发自有JWT令牌返回给客户端
• JWT中可以自定义存入用户ID、权限角色、过期时间等你需要的字段，签名用你自己服务的非对称密钥（RSA）或者对称密钥（HS256）即可
• 后续所有客户端请求都携带这个自签发的JWT，鉴权逻辑直接在Express中间件里完成本地验签，不用查DB、不用调用第三方IDP接口，性能达到毫秒级
• 优势：后续接入任意数量的IDP都不会影响鉴权性能，还可以自主控制令牌有效期、权限扩展，完全不受第三方IDP的接口限流、超时影响
  注意：JWT payload是明文可解码的，不要存入密码、手机号等敏感信息

Express简易实现示例：

const jwt = require('jsonwebtoken');
// 登录接口逻辑
app.post('/api/auth/login', async (req, res) => {
  const { idp, accessToken } = req.body; // 客户端登录时携带当前使用的IDP标识
  // 1. 调用对应IDP的userinfo接口校验accessToken合法性
  let userInfo;
  if (idp === 'google') {
    userInfo = await verifyGoogleToken(accessToken);
  } else if (idp === 'apple') {
    userInfo = await verifyAppleToken(accessToken);
  }
  if (!userInfo) return res.sendStatus(401);
  // 2. 校验通过，查DB确认用户存在/创建新用户
  const user = await upsertUser(userInfo);
  // 3. 签发自有JWT，有效期按需调整
  const token = jwt.sign(
    { userId: user.id, role: user.role },
    process.env.JWT_SECRET,
    { expiresIn: '2h' }
  );
  res.json({ token });
});

// 全局鉴权中间件，所有需要鉴权的接口先过这个中间件
const authMiddleware = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.sendStatus(401);
  try {
    // 本地验签，完全不需要外部请求
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.user = payload;
    next();
  } catch (err) {
    return res.sendStatus(401);
  }
};

备选优化方案：缓存令牌映射关系 #

如果因为业务原因不能替换现有令牌传输机制，必须每次用IDP的不透明令牌鉴权，可以在你现有方案2的基础上加一层分布式缓存优化：

• 新增Redis等内存缓存层，用户首次鉴权通过后，将{ 不透明令牌: 对应issuer, userId }存入缓存，过期时间和IDP颁发的access_token有效期保持一致（Google/Apple的access_token默认有效期多为1小时，可自行匹配）
• 后续鉴权时先查缓存，命中则直接调用对应IDP的校验接口，未命中再查DB获取issuer，缓存命中率可以达到95%以上，大幅降低DB查询压力
• 额外优化：给IDP的userinfo请求配置HTTP连接池开启keep-alive，减少TCP握手开销，进一步降低接口调用耗时

原有方案的问题说明 #

• 串行校验IDP接口的方案完全不可行，除了性能线性下降的问题，还会面临第三方接口限流、超时的额外风险，不适合大用户量场景
• 直接查DB获取issuer的方案虽然可用，但大流量下DB查询压力会很高，加缓存层或者替换为自签发JWT是更合理的迭代方向

内容的提问来源于stack exchange，提问作者A.Sinan