关于在Next.js 14应用中基于Supabase实现仅用userId或邮箱的永久用户认证方案的咨询

兄弟，我太懂你这个困扰了——想搞个能让用户随时、反复用的永久认证链接，结果Supabase的magic link要么24小时就过期，要么点一次就废，甚至同一个邮箱重新生成还返回过期token，这体验确实拉胯。而且你不想碰明文密码，也不想折腾那种存加密密码还要处理密码更新的破事儿，完全能理解，这方案谁想当备选啊！那咱们来唠几个更靠谱的替代思路：

方案1：自定义JWT令牌+数据库哈希存储验证 #

这个思路是自己掌控整个认证链路，不用依赖Supabase的magic link限制：

• 生成一个包含用户ID的长期JWT（比如设10年过期），然后把这个JWT的哈希值存在Supabase的自定义表（比如permanent_auth_tokens）里，绝对不要存明文JWT
• 当用户通过这个令牌访问时，先在后端验证JWT的签名和有效性，再去数据库匹配哈希值是否对应正确的用户

举个代码例子（可以在Next.js API路由或者Supabase Edge Function里实现）：

// 生成永久令牌的逻辑（仅后端执行）
import jwt from 'jsonwebtoken';
import { createHash } from 'crypto';
import { supabaseAdmin } from '../path-to-supabase-admin';

export async function generatePermanentToken(userId) {
  // 嵌入用户ID，设置超长过期时间
  const token = jwt.sign({ sub: userId }, process.env.JWT_SECRET, { expiresIn: '10y' });
  // 生成令牌哈希值用于存储
  const tokenHash = createHash('sha256').update(token).digest('hex');
  // 存入自定义表
  await supabaseAdmin.from('permanent_auth_tokens').insert({
    user_id: userId,
    token_hash: tokenHash,
    created_at: new Date().toISOString()
  });
  return token;
}

// 验证令牌并获取用户信息的逻辑
export async function verifyPermanentToken(token) {
  try {
    // 先验证JWT的签名和过期时间
    const decoded = jwt.verify(token, process.env.JWT_SECRET);
    const userId = decoded.sub;
    // 计算哈希值匹配数据库记录
    const tokenHash = createHash('sha256').update(token).digest('hex');
    const { data: tokenRecord } = await supabaseAdmin.from('permanent_auth_tokens')
      .select('user_id')
      .eq('user_id', userId)
      .eq('token_hash', tokenHash)
      .single();
    
    if (tokenRecord) {
      // 验证通过，拉取用户信息
      const { data: user } = await supabaseAdmin.auth.admin.getUserById(userId);
      return user;
    }
    return null;
  } catch (err) {
    console.error('令牌验证失败:', err);
    return null;
  }
}

优缺点：灵活性拉满，你可以随时在数据库里禁用某个令牌（比如用户要取消永久权限）；缺点是要自己处理令牌的生成、验证、存储，而且一定要把JWT密钥藏好，别泄露了。

方案2：Supabase原生会话+自定义用户元数据 #

这个思路是利用Supabase的原生会话管理，给需要永久认证的用户生成超长有效期的会话：

• 先给用户的元数据里加个标记（比如permanent_auth: true），方便后续识别
• 用Supabase Admin API生成一个超长过期时间的会话令牌，直接返回给用户使用

代码示例：

import { supabaseAdmin } from '../path-to-supabase-admin';

export async function createPermanentSession(userId) {
  // 给用户标记永久认证权限
  await supabaseAdmin.auth.admin.updateUserById(userId, {
    user_metadata: { permanent_auth: true }
  });
  // 生成10年有效期的会话
  const { data: session, error } = await supabaseAdmin.auth.admin.createSession({
    user_id: userId,
    expires_in: 315360000 // 10年对应的秒数
  });
  if (error) throw error;
  return session.access_token;
}

注意点：Supabase默认用户修改密码时会 invalidate 所有会话，所以如果用户改了密码，这个永久会话也会失效，需要重新生成。另外要确认你的Supabase实例允许设置这么长的会话过期时间（大部分情况下是支持的）。

方案3：用户专属API密钥+服务端代理认证 #

如果你的场景是内部工具、信任用户的自动化访问，这个方案更合适：

• 给每个用户生成一个专属API密钥，存储它的哈希值在自定义表（比如user_api_keys）里
• 用户请求时在请求头里带这个API密钥，后端验证哈希值后，用Supabase Admin API给该用户生成一个临时会话（比如1小时过期），再用这个临时会话处理业务逻辑

代码示例：

// 生成用户API密钥的逻辑
import { randomBytes } from 'crypto';
import { createHash } from 'crypto';
import { supabaseAdmin } from '../path-to-supabase-admin';

export async function generateUserApiKey(userId) {
  const apiKey = randomBytes(32).toString('hex');
  const apiKeyHash = createHash('sha256').update(apiKey).digest('hex');
  // 存入数据库，标记是否激活
  await supabaseAdmin.from('user_api_keys').insert({
    user_id: userId,
    key_hash: apiKeyHash,
    is_active: true
  });
  return apiKey;
}

// 验证API密钥并生成临时会话的逻辑
export async function authenticateWithApiKey(apiKey) {
  const apiKeyHash = createHash('sha256').update(apiKey).digest('hex');
  // 查找有效API密钥
  const { data: keyRecord } = await supabaseAdmin.from('user_api_keys')
    .select('user_id')
    .eq('key_hash', apiKeyHash)
    .eq('is_active', true)
    .single();
  
  if (!keyRecord) return null;
  // 生成临时会话，避免长期会话的安全风险
  const { data: session } = await supabaseAdmin.auth.admin.createSession({
    user_id: keyRecord.user_id,
    expires_in: 3600 // 1小时过期
  });
  return session;
}

优缺点：可以随时禁用某个API密钥，不用管用户密码的变化；但更适合服务端/工具类访问，普通前端用户用的话体验可能不如直接的认证链接。

总结一下：如果是给普通前端用户做永久认证链接，方案1（自定义JWT）最灵活；如果想尽量用Supabase原生能力，方案2更省心；如果是内部工具或自动化场景，方案3更合适。

内容来源于stack exchange