在Next.js中能否将JWT令牌存储到Local Storage用于API请求鉴权？

结论：可以将JWT存在Local Storage并在请求中携带，但需关注安全风险与Next.js适配细节 #

一、基础实现方式 #

完全可以把JWT访问令牌存在Local Storage里，发起API请求时取出并放入Authorization: Bearer <token>请求头中。在Next.js的客户端组件里（服务端组件无法访问浏览器的Local Storage），你可以封装一个通用的请求工具函数来统一处理令牌携带逻辑，避免重复代码。

示例代码：

// utils/api.js
export async function authFetch(url, options = {}) {
  // 从Local Storage获取令牌
  const accessToken = localStorage.getItem('accessToken');
  
  // 构造请求头，携带Bearer令牌
  const requestHeaders = {
    ...options.headers,
    'Content-Type': 'application/json',
  };
  if (accessToken) {
    requestHeaders['Authorization'] = `Bearer ${accessToken}`;
  }

  try {
    const response = await fetch(url, {
      ...options,
      headers: requestHeaders,
    });

    // 处理令牌过期场景
    if (response.status === 401) {
      localStorage.removeItem('accessToken');
      window.location.href = '/login';
      throw new Error('令牌已过期，请重新登录');
    }

    return await response.json();
  } catch (error) {
    console.error('API请求失败:', error);
    throw error;
  }
}

在仪表盘客户端组件中使用：

// app/dashboard/page.js
'use client'; // 必须标记为客户端组件才能访问Local Storage

import { authFetch } from '@/utils/api';
import { useEffect, useState } from 'react';

export default function Dashboard() {
  const [userDashboardData, setUserDashboardData] = useState(null);

  useEffect(() => {
    const loadDashboardData = async () => {
      try {
        const data = await authFetch('https://your-api.com/user/dashboard');
        setUserDashboardData(data);
      } catch (err) {
        // 这里可以添加错误提示逻辑
      }
    };

    loadDashboardData();
  }, []);

  return (
    <div className="dashboard">
      {userDashboardData ? (
        <div>
          <h2>你的专属仪表盘</h2>
          <p>用户名：{userDashboardData.username}</p>
          <p>角色：{userDashboardData.role}</p>
        </div>
      ) : (
        <p>加载中...</p>
      )}
    </div>
  );
}

二、关键安全注意事项 #

Local Storage存储JWT存在XSS攻击风险：因为浏览器中的JavaScript可以直接读取Local Storage内容，如果你的页面被注入恶意脚本，令牌会被窃取，进而导致用户账号被盗用。

要降低风险，你需要：

• 严格过滤和转义所有用户输入内容，避免DOM注入
• 配置内容安全策略（CSP），限制脚本加载来源，禁止不安全的inline脚本和eval
• 避免使用可能引入XSS风险的第三方脚本，或确保其经过安全审计

三、更安全的替代方案：HttpOnly Cookie #

如果你的自研API和Next.js应用同域（或可以配置CORS允许凭证），优先推荐将JWT存在HttpOnly、Secure属性的Cookie中：

• HttpOnly Cookie无法被JavaScript读取，从根源上避免XSS窃取令牌
• Secure属性确保Cookie仅通过HTTPS传输，防止中间人攻击

使用这种方案时，API请求需要携带credentials: 'include'（fetch）或withCredentials: true（axios），同时API端需要配置CORS的Access-Control-Allow-Credentials: true，并指定允许的Origin。

总结 #

将JWT存在Local Storage并在请求中携带是可行的实现方式，适合你的客户端渲染场景，但必须做好XSS防护。如果追求更高的安全性，建议改用HttpOnly Cookie方案，尤其是当API和Next.js应用同域时。

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