基于MERN栈的Zendesk OAuth实现及Token存储方案咨询

1. 当前实现方式是否正确？ #

前3步完全符合OAuth授权码流程的规范，但第4步通过URL参数传递token的方式严重错误。OAuth授权码流程的核心设计就是让后端完成token交换，避免前端直接接触敏感凭证，你现在的做法直接把token暴露在公开可追踪的位置，违背了这个安全初衷。

2. 正确的令牌处理方式 #

推荐方案（后端代理模式） #

后端拿到Zendesk的access_token后，不要直接返回给前端：

• 生成自定义会话令牌（比如JWT），将Zendesk token加密存储在JWT中，或者存在后端的Redis等缓存服务里，关联用户会话。
• 将自定义会话令牌存入HTTP-only、Secure的Cookie中（生产环境必须开启Secure和SameSite=Strict）。
• 后续前端请求后端接口时，Cookie会自动携带，后端解密或从缓存中取出Zendesk token，代为调用Zendesk API，前端全程不直接接触Zendesk的token。

改进后的回调代码示例：

import jwt from 'jsonwebtoken';

export const authCallback = (req: Request, res: Response): void => {
  const body = {
    grant_type: 'authorization_code',
    code: req.query.code,
    client_id: process.env.ZENDESK_CLIENT_ID,
    client_secret: process.env.ZENDESK_SECRET,
  };

  axios
    .post(`https://${process.env.SUBDOMAIN}.zendesk.com/oauth/tokens`, body, {
      headers: { 'Content-Type': 'application/json' },
    })
    .then((response) => {
      const zendeskToken = response.data.access_token;
      // 生成自定义会话JWT，有效期与Zendesk token对齐
      const sessionToken = jwt.sign(
        { zendeskToken },
        process.env.JWT_SECRET!,
        { expiresIn: response.data.expires_in }
      );

      // 设置安全Cookie，禁止前端脚本读取
      res.cookie('app_session', sessionToken, {
        httpOnly: true,
        secure: process.env.NODE_ENV === 'production',
        sameSite: 'strict',
        maxAge: response.data.expires_in * 1000,
      });

      // 重定向到前端首页，无需携带token参数
      return res.redirect(`${process.env.ORIGIN}`);
    })
    .catch((err) => {
      return res.status(400).send({ message: err.message });
    });
};

备选方案（前端直接调用Zendesk API） #

如果业务必须让前端直接使用Zendesk token，不要用URL重定向传递，而是返回JSON响应：

// 替换重定向逻辑
return res.status(200).json({ token: zendeskToken });

前端接收后再存储到安全位置，后续请求Zendesk API时在请求头中携带Authorization: Bearer ${token}。

3. 存入Session Storage是否可行？ #

可行，但存在明显局限性：

• 优点：仅在当前标签页会话有效，关闭标签页后自动清除，比Local Storage安全度稍高。
• 缺点：
  • 易受XSS攻击：如果前端页面存在XSS漏洞，攻击者可通过脚本直接读取Session Storage中的token，冒充用户操作。
  • 无法跨标签页：用户新开标签页需要重新登录，体验较差。

如果选择这种方式，必须配合严格的XSS防护（比如配置内容安全策略CSP、严格过滤用户输入输出），并且设置较短的token过期时间。

4. 暴露令牌的风险 #

风险极高，主要包括：

• URL参数会被记录在浏览器历史、书签、服务器访问日志、代理日志中，任何能获取这些记录的人都可以盗用token。
• 若token过期时间较长，攻击者可长期冒用用户权限操作Zendesk数据。
• 即使是HTTPS传输，URL的参数部分仍可能在某些场景（如中间代理、浏览器历史导出）中泄露。

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