Next.js NextAuth中实现基于角色的Google登录与自定义参数传递

本文详细探讨了在Next.js应用中，如何利用NextAuth实现基于角色的Google登录，并解决向NextAuth后端`signIn`回调传递自定义参数（如`userType`）的挑战。核心策略是创建多个自定义OAuth提供者，每个提供者预设一个角色类型，从而在`signIn`回调中通过`user`对象获取到正确的用户类型，实现不同角色用户的数据库存储。

在构建现代Web应用时，用户身份验证是不可或缺的一部分。Next.js结合NextAuth提供了一种强大且灵活的认证解决方案。然而，当需要实现更复杂的逻辑，例如根据用户选择的角色（如“管理员”或“普通用户”）来处理登录并将其存储到不同的数据库表或具有不同属性时，如何将这些自定义信息从前端传递到NextAuth的后端signIn回调就成了一个常见问题。

背景与挑战

在NextAuth中，signIn函数通常用于触发认证流程。对于OAuth提供者（如Google），其签名如下：signIn(providerId, options, authorizationParams)。其中，options对象通常包含callbackUrl等参数，而authorizationParams则直接传递给OAuth提供者进行授权请求。这意味着，我们尝试在options或authorizationParams中直接添加自定义参数（如userType）并期望在后端signIn回调中接收到，是行不通的。这些参数不会直接转发到signIn回调的user或profile对象中。

例如，以下前端尝试传递userType的方式在后端signIn回调中都将返回undefined：

// 常见但无效的前端尝试
await signIn(providerId, { callbackUrl: "/dashboard"}, {credentials:{userType: userType}});
await signIn(providerId, { userType: userType, callbackUrl: "/dashboard"});

为了解决这个问题，我们需要一种机制，在NextAuth的认证流程中，将userType这样的上下文信息可靠地注入到signIn回调可访问的对象中。

解决方案：自定义 OAuth 提供者

核心思想是为每种用户类型创建独立的自定义OAuth提供者。这样，当用户选择某个角色进行登录时，前端调用对应的提供者ID，后端NextAuth配置中的该提供者会通过其profile回调将预设的userType注入到user对象中，从而在signIn回调中获取。

1. 后端 NextAuth 配置 (/app/api/auth/[...nextauth]/route.js)

首先，我们需要修改NextAuth的配置，定义多个自定义的Google OAuth提供者。每个提供者都有一个唯一的id，并在其profile回调中明确指定userType。

import NextAuth from 'next-auth';
import GoogleProvider from 'next-auth/providers/google'; // 仍然可以作为参考，但我们将创建自定义的
import { connectToDB } from '@/utils/database';
import { User, TypeA, TypeB } from '@/models/user'; // 假设这是您的Mongoose模型

// 辅助函数，用于生成随机头像URL（示例）
function getRandomAvatarURL() {
  // 实现您的逻辑，例如从预设列表或API获取
  return "https://example.com/default-avatar.png";
}

const handler = NextAuth({
  providers: [
    // 为 TypeA 用户创建自定义 Google 提供者
    {
      id: "googleTypeA", // 唯一的ID
      name: "Google (Type A)",
      type: "oauth",
      wellKnown: "https://accounts.google.com/.well-known/openid-configuration",
      authorization: { params: { scope: "openid email profile" } },
      idToken: true,
      checks: ["pkce", "state"],
      profile(profile) {
        // 在此处注入 userType
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
          image: profile.picture,
          userType: "typeA", // 明确指定用户类型
        };
      },
      clientId: process.env.GOOGLE_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    },
    // 为 TypeB 用户创建自定义 Google 提供者
    {
      id: "googleTypeB", // 唯一的ID
      name: "Google (Type B)",
      type: "oauth",
      wellKnown: "https://accounts.google.com/.well-known/openid-configuration",
      authorization: { params: { scope: "openid email profile" } },
      idToken: true,
      checks: ["pkce", "state"],
      profile(profile) {
        // 在此处注入 userType
        return {
          id: profile.sub,
          name: profile.name,
          email: profile.email,
          image: profile.picture,
          userType: "typeB", // 明确指定用户类型
        };
      },
      clientId: process.env.GOOGLE_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    },
    // 如果您还需要通用的 GoogleProvider，可以继续添加
    // GoogleProvider({
    //     clientId: process.env.GOOGLE_ID,
    //     clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    // })
  ],

  callbacks: {
    async session({ session }) {
      const sessionUser = await User.findOne({
        email: session.user.email
      });
      if (sessionUser) {
        session.user.id = sessionUser._id.toString();
        session.user.image = sessionUser.image;
        // 如果需要，也可以将 userType 添加到 session 中
        session.user.userType = sessionUser.userType;
      }
      return session;
    },

    async signIn({ user, profile }) { // 注意：user 对象现在包含了 profile 回调中注入的 userType
      try {
        await connectToDB();

        // 检查用户是否已存在
        const userExists = await User.findOne({
          email: profile.email
        });

        // 如果用户不存在，则根据 user.userType 创建新用户
        if (!userExists) {
          const name = profile.name.split(" ");
          const firstName = name[0] || ".";
          const lastName = name.slice(1).join(" ") || ".";
          const username = `${firstName}${lastName}`.replace(/\s/g, "");

          // 根据 user.userType 创建不同类型的用户
          if (user.userType === "typeA") {
            await TypeA.create({
              email: profile.email,
              username: username,
              image: getRandomAvatarURL(),
              userType: "typeA",
            });
          } else if (user.userType === "typeB") {
            await TypeB.create({
              email: profile.email,
              username: username,
              image: getRandomAvatarURL(),
              userType: "typeB",
            });
          } else {
            // 处理未知的 userType 或通用用户
            console.warn("Unknown userType encountered:", user.userType);
            // 也可以选择创建一个默认类型的用户
            await User.create({
                email: profile.email,
                username: username,
                image: getRandomAvatarURL(),
                userType: "default", // 或者抛出错误
            });
          }
        }

        return true;

      } catch (error) {
        console.error("Error during signIn:", error);
        if (error.code === 11000) {
          console.log("Unique constraint violation error! Username already Exists!");
        }
        return false;
      }
    }
  },
});

export { handler as GET, handler as POST };

在上述代码中，我们定义了两个自定义提供者：googleTypeA 和 googleTypeB。它们的关键在于profile函数，它接收Google返回的原始profile数据，并允许我们对其进行转换。我们在此处添加了userType属性，并将其值设置为"typeA"或"typeB"。这样，在signIn回调中，user对象就会包含这个userType属性，我们可以据此进行条件判断。

2. 前端调用 (Nav 组件或其他地方)

前端的调用变得非常直接，只需根据用户选择的角色调用对应的提供者ID即可。

// 假设这是您的 Nav 组件
import { signIn } from 'next-auth/react';
import Image from 'next/image'; // 如果您使用 Next.js Image 组件

const Nav = () => {
  // ... 其他代码，例如获取 providers

  const handleSignin = async (userType) => {
    let providerId;
    if (userType === "typeA") {
      providerId = "googleTypeA";
    } else if (userType === "typeB") {
      providerId = "googleTypeB";
    } else {
      console.error("Invalid user type selected.");
      return;
    }

    await signIn(providerId, { callbackUrl: "/dashboard" });
  };

  return (
    // ...
    
      {/* 按钮示例：选择登录为 TypeA 用户 */}
       handleSignin("typeA")}
      >
        
        登录为 Type A
      

      {/* 按钮示例：选择登录为 TypeB 用户 */}
       handleSignin("typeB")}
      >
        
        登录为 Type B
      
    
    // ...
  );
};

export default Nav;

现在，当用户点击“登录为 Type A”按钮时，将调用signIn("googleTypeA", ...)，NextAuth后端会触发googleTypeA提供者的profile回调，将userType: "typeA"注入到user对象中，然后signIn回调就能正确识别并处理。

数据库模型（Mongoose Discriminators）

为了完整性，这里简要回顾一下原始问题中提到的Mongoose模型设置，它利用了Discriminators来实现基于角色的用户存储：

import mongoose, { Schema, model, models } from "mongoose";

// 基础用户 Schema
const userSchema = new Schema({
  email: {
    type: String,
    required: [true, "Email is required"],
    unique: [true, "Email already exists"],
    index: true,
  },
  username: {
    type: String,
    required: [true, "Username is required"],
    match: [/^[a-zA-Z0-9]+$/, "Username is invalid"],
    index: true,
  },
  image: {
    type: String,
  },
  userType: { // 区分用户类型的字段
    type: String,
    enum: ["typeA", "typeB"],
    required: [true, "User type is required"],
  },
});

// TypeA 用户的 Discriminator Schema
const typeASchema = new Schema({
  // 引用基础 User
  typeA: {
    type: mongoose.Schema.Types.ObjectId,
    ref: "User",
  },
  other1: [{ // TypeA 独有的字段
    type: mongoose.Schema.Types.ObjectId,
    ref: "other_table1",
  }],
});

// TypeB 用户的 Discriminator Schema
const typeBSchema = new Schema({
  // 引用基础 User
  typeB: {
    type: mongoose.Schema.Types.ObjectId,
    ref: "User",
  },
  other2: [{ // TypeB 独有的字段
    type: mongoose.Schema.Types.ObjectId,
    ref: "other_table2",
  }],
});

// 定义基础 User 模型
const User = models.User || model("User", userSchema);
// 定义 TypeA 和 TypeB Discriminator 模型
const TypeA = models.TypeA || User.discriminator("TypeA", typeASchema);
const TypeB = models.TypeB || User.discriminator("TypeB", typeBSchema);

export { User, TypeA, TypeB };

通过Mongoose的Discriminators，TypeA和TypeB模型实际上是User模型的特殊版本，它们共享User的基础字段，并拥有各自特有的字段。在NextAuth的signIn回调中，我们根据user.userType创建相应的TypeA或TypeB实例，确保数据正确地存储到对应的逻辑模型中。

注意事项

1. 提供者数量管理： 如果您的应用有大量的用户类型，这种为每种类型创建一个自定义提供者的方法可能会导致NextAuth配置变得冗长。在这种情况下，您可能需要重新评估用户类型的设计，或者探索更高级的动态提供者生成方案（如果NextAuth未来版本支持）。
2. 安全性： 本方案中userType是在服务器端NextAuth配置中硬编码到特定提供者中的，这保证了userType的安全性，不会被客户端随意篡改。
3. 错误处理： 确保在signIn回调中包含健壮的错误处理逻辑，以应对数据库连接失败、用户创建失败或唯一性约束冲突等问题。
4. 用户体验： 在前端，清晰地向用户展示不同角色登录的选项，并提供明确的按钮或链接，以避免混淆。
5. Session管理： 考虑在session回调中也将userType添加到session.user对象中，以便在整个应用中方便地访问当前用户的角色信息。

总结

通过创建自定义的OAuth提供者，并在其profile回调中注入特定的userType，我们成功地解决了在NextAuth中从前端向后端signIn回调传递自定义参数的问题。这种方法为实现基于角色的认证流程提供了清晰且安全的方式，使得后端能够根据用户类型执行不同的逻辑，如创建不同类型的用户记录。虽然这种方法增加了提供者的配置数量，但它在保证安全性和清晰性方面表现出色，是处理此类需求的一种有效策略。