Better Auth: مصادقة TypeScript الحديثة في 2026

إذا أطلقت تطبيق Next.js أو تطبيق TypeScript متكامل في السنوات الأخيرة، فلابد أنك صارعت مع المصادقة. كانت NextAuth (المعروفة الآن باسم Auth.js) هي الخيار الافتراضي منذ 2020، لكن أي شخص هاجر بين الإصدارات الرئيسية، أو حاول تصحيح عنوان رد اتصال، أو حاول إضافة دعم المؤسسات والمصادقة الثنائية يعرف مدى صعوبة الأمر. تحل Clerk مشكلة تجربة المطور لكنها تربطك بخدمة SaaS مدفوعة. ترتبط Supabase Auth بـ Supabase. وأسعار Auth0 موجهة للمؤسسات الكبرى.

في 2026، استحوذ خيار جديد على المشهد: Better Auth. مفتوحة المصدر، مستضافة ذاتياً، آمنة الأنواع بالكامل، مستقلة عن إطار العمل، ومصممة بحيث تبقى الأجزاء التي لا تحتاجها خارج حزمتك. يشرح هذا الدليل ما هي، ولماذا انتشرت، وكيفية إطلاقها في الإنتاج.

الإجابة في 30 ثانية

Better Auth هي مكتبة مصادقة قائمة على TypeScript تمنحك استضافة ذاتية بأسلوب NextAuth مع تجربة مطور بأسلوب Clerk. تدعم البريد الإلكتروني وكلمة المرور، وOAuth، والروابط السحرية، ومفاتيح المرور (Passkeys)، والمصادقة الثنائية، والمؤسسات، وأدوات الإدارة من خلال نظام إضافات نظيف. أنت تملك قاعدة البيانات، وأنت تملك الجلسات، وتتدفق الأنواع من الخادم إلى العميل دون خطوات توليد يدوية.

اختر Better Auth إذا أردت تحكماً كاملاً في مكدس المصادقة دون كتابته من الصفر، وسئمت من محاربة مكتبة المصادقة في كل ترقية.

لماذا تنتقل الفرق بعيداً عن NextAuth

الشكاوى متسقة بشكل ملحوظ عبر الفرق التي تحولت:

• انتشار التكوين. قسمت Auth.js v5 التكوين عبر ملفات وسياقات تشغيل متعددة. إعداد OAuth بسيط ينتشر بسهولة عبر أربعة ملفات قبل أن يعمل.
• تسرب أمان الأنواع. تتطلب أنواع الجلسة توسيعاً للوحدات، والأنواع المولّدة لا تعكس الحقول المخصصة دون عمل يدوي.
• احتكاك بيئة Edge. يحتاج البرنامج الوسيط الذي يتحدث إلى قاعدة بيانات إلى تكوين منفصل. الفصل بين Edge وNode غير محكم.
• الإضافات من الدرجة الثانية. إضافة المصادقة الثنائية أو المؤسسات تعني كتابتها بنفسك أو لصق حزم مجتمعية معاً.
• الترحيل محفوف بالمخاطر. كسرت ترقيات الإصدارات الرئيسية الجلسات وتدفقات إعادة التوجيه وتكوينات المزودين أكثر من مرة.

صُممت Better Auth استجابةً مباشرة لهذه المشكلات. الفرضية: المصادقة بنية تحتية أساسية، لذلك يجب أن تكون المكتبة مكتبة، وليست إطار عمل له آراء حول تخطيط ملفاتك.

البنية الأساسية

تعمل Better Auth كمجموعة واحدة من مسارات API مثبتة تحت /api/auth/*. تقوم بتكوينها مرة واحدة في ملف خادم، ويغذي نفس التكوين إجراءات الخادم ومعالجات المسارات وعميل SDK. كل شيء TypeScript عادي، بدون DSL، بدون خطوة توليد كود، بدون وحدات افتراضية.

يبدو إعداد Next.js الحد الأدنى كما يلي:

import { betterAuth } from "better-auth"
import { drizzleAdapter } from "better-auth/adapters/drizzle"
import { db } from "@/db"
 
export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: "pg" }),
  emailAndPassword: { enabled: true },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    },
  },
})

هذا الكائن الواحد هو مصدر الحقيقة. يُثبَّت المعالج في مكان واحد:

import { auth } from "@/lib/auth"
import { toNextJsHandler } from "better-auth/next-js"
 
export const { GET, POST } = toNextJsHandler(auth)

وعميل SDK سطر واحد:

import { createAuthClient } from "better-auth/react"
 
export const authClient = createAuthClient()

يستنتج العميل أنواعه مباشرة من تكوين الخادم. أضف إضافة على الخادم، تظهر الطرق المطابقة على العميل. لا توجد خطوة إعادة توليد، ولا توسيع أنواع يدوي.

محولات قواعد البيانات والملكية

تأتي Better Auth مع محولات من الدرجة الأولى لـ Drizzle وPrisma وKysely وMongoDB. يُولَّد المخطط بواسطة CLI ويعيش في قاعدة الكود مثل أي ترحيل آخر. تُخزَّن الجلسات والحسابات وسجلات المستخدمين في قاعدة بياناتك، لا توجد خدمة خارجية تحتفظ بالحالة.

توليد المخطط:

npx @better-auth/cli generate
npx @better-auth/cli migrate

تتبع الجداول المولدة أسماء تقليدية: user وsession وaccount وverification. يمكنك توسيع جدول المستخدم بحقول عشوائية من خلال التكوين، وتظل هذه الحقول مكتوبة بالأنواع من البداية إلى النهاية:

export const auth = betterAuth({
  user: {
    additionalFields: {
      role: { type: "string", defaultValue: "member" },
      companyId: { type: "string", required: false },
    },
  },
})

session.user.role الآن مكتوبة بنوع string في كل مكان: الخادم، العميل، البرنامج الوسيط. لا حاجة لملف توسيع يدوي.

نظام الإضافات هو الميزة الأبرز

نظام الإضافات هو المكان الذي تتقدم فيه Better Auth على كل بديل. تأتي كل قدرة كإضافة تختار تفعيلها. لا تحمل الحزمة سوى ما تفعّله.

import { twoFactor, organization, admin, passkey, magicLink } from "better-auth/plugins"
 
export const auth = betterAuth({
  plugins: [
    twoFactor(),
    organization({ allowUserToCreateOrganization: true }),
    admin(),
    passkey({ rpName: "Noqta" }),
    magicLink({ sendMagicLink: async ({ email, url }) => sendEmail(email, url) }),
  ],
})

تضيف كل إضافة مساراتها وجداول قاعدة بياناتها وطرق العميل الخاصة بها. يكتشفها عميل SDK تلقائياً:

await authClient.twoFactor.enable({ password: "..." })
await authClient.organization.create({ name: "Noqta" })
await authClient.passkey.addPasskey()
await authClient.signIn.magicLink({ email: "user@example.com" })

تغطي الإضافات الرسمية المتاحة في 2026 المصادقة الثنائية والروابط السحرية ومفاتيح المرور (WebAuthn) والمؤسسات والفرق وأدوات الإدارة ومفاتيح API والجلسات المجهولة والجلسات المتعددة ووضع موفر OIDC وتحديد المعدل. توسع إضافات المجتمع هذا بـ SAML وSSO وتدفقات مخصصة.

الجلسات والبرنامج الوسيط

الجلسات مدعومة بـ JWT افتراضياً ولكن يمكن تبديلها إلى جلسات قاعدة بيانات بعلامة تكوين واحدة. في كلتا الحالتين، قراءة الجلسة في أي سياق موحدة:

import { auth } from "@/lib/auth"
import { headers } from "next/headers"
 
const session = await auth.api.getSession({ headers: await headers() })
if (!session) redirect("/login")

نفس الاستدعاء يعمل في Server Components وRoute Handlers وServer Actions والبرنامج الوسيط. لا يحتاج البرنامج الوسيط إلى تكوين منفصل متوافق مع Edge، توفر Better Auth فحص جلسة خفيف الوزن يعمل على Edge دون الوصول إلى قاعدة البيانات:

import { getSessionCookie } from "better-auth/cookies"
import { NextResponse } from "next/server"
 
export async function middleware(request: Request) {
  const sessionCookie = getSessionCookie(request)
  if (!sessionCookie) return NextResponse.redirect(new URL("/login", request.url))
  return NextResponse.next()
}

للتحقق الكامل من الجلسة في البرنامج الوسيط يمكنك استدعاء API، ولكن فحص الكوكي يكفي لمعظم حماية المسارات ويتجنب رحلة قاعدة بيانات في كل طلب.

أمان الأنواع من البداية إلى النهاية

هذا هو الجزء الذي يفاجئ الناس حقاً القادمين من NextAuth. تضيف حقلاً إلى نموذج المستخدم في التكوين، وتحدث ثلاثة أشياء تلقائياً:

1. يضيف ترحيل مخطط قاعدة البيانات العمود.
2. يتضمن نوع session.user على الخادم الحقل.
3. ترجع خطافة العميل authClient.useSession() الحقل بالنوع الصحيح.

لا توسيع next-auth.d.ts، لا انحراف بين أنواع العميل والخادم، لا as any. تمتد الإضافات الأنواع بنفس الطريقة، فعّل إضافة المؤسسة وتظهر session.activeOrganization كحقل مكتوب على الجانبين.

الأداء وحجم الحزمة

Better Auth مبنية حول tree-shaking. تضيف المكتبة الأساسية بدون إضافات حوالي 25 كيلوبايت مضغوطة إلى حزمة العميل. كل إضافة تفعّلها تضيف كود العميل الخاص بها، لكن الإضافات التي لا تفعّلها لا تساهم بأي شيء. تشحن NextAuth v5 بالمقارنة ما يقرب من 50 كيلوبايت وتسحب مزودين قد لا تستخدمهم.

على الخادم، معالجة الطلبات إرسال صغير عبر المسارات المُكوَّنة. لا انعكاس، لا تحميل وحدات في وقت الطلب. البدايات الباردة على Vercel وCloudflare Workers أسرع بشكل ملحوظ من NextAuth.

أين لا تزال Better Auth تحتوي على نقاط ضعف

ليست مثالية. بعض المجالات التي يستحق معرفتها قبل التبني:

• التوثيق يتحسن لكنه غير متساوٍ. توثيق الإضافات أحياناً ضعيف، وتحتاج أحياناً إلى قراءة المصدر لفهم علامة.
• إضافات المجتمع متفاوتة الجودة. التزم بالإضافات الرسمية للإنتاج حتى يكون لإضافة مجتمعية سجل أداء.
• SSO المؤسسي (SAML) من صيانة المجتمع. إذا كنت بحاجة إلى SAML لمبيعات B2B، قيّم إضافة SAML بعناية أو اقرن Better Auth بمزود SSO مخصص.
• الترحيل من NextAuth ليس آلياً. الجلسات وتجزئات كلمات المرور وروابط الحسابات تحتاج إلى نقل متعمد. خطط لنافذة ترحيل لمرة واحدة.

نمط الترحيل من NextAuth

أنظف ترحيل أجريناه يبدو هكذا:

1. أقم Better Auth بجانب NextAuth في نفس التطبيق تحت بادئة مختلفة (مثلاً /api/auth-v2/*).
2. هاجر جداول المستخدم والحساب والجلسة. مخطط Better Auth مشابه بما يكفي لتغطية معظم الحقول بترحيل SQL واحد.
3. للمستخدمين القائمين على كلمة المرور، احتفظ بعمود التجزئة القديم واستخدم خطافة Better Auth verifyPassword للتحقق من التجزئة القديمة في تسجيل الدخول الأول، ثم أعد التجزئة إلى التنسيق الجديد.
4. لمستخدمي OAuth، تنتقل روابط الحسابات بإعادة تسمية عمود. لا حاجة لإعادة المصادقة.
5. بدّل عميل SDK ميزة بميزة خلف علامة. شغّل كليهما بالتوازي لمدة أسبوع لاكتشاف الحالات الحدية.
6. أوقف NextAuth بمجرد استقرار المقاييس.

أجرينا هذا الترحيل على تطبيق Next.js إنتاجي في مارس 2026. كان إجمالي وقت التوقف صفراً، عدد الأخطاء في الأسبوع الأول ثلاثة، ولم ينظر الفريق إلى الوراء.

متى لا تستخدم Better Auth

بعض الحالات التي يكون فيها الخيار الخاطئ:

• تحتاج إلى واجهة مستضافة اليوم وليس لديك سعة هندسية. تمنحك Clerk مكوناً جاهزاً مصقولاً، وإدارة مستخدمين مستضافة، وامتثال SOC 2 جاهزاً. تمنحك Better Auth أوليات.
• أنت متجذر بعمق في Supabase. Supabase Auth جيدة، تتكامل مع RLS، ولا توجد ميزة ترحيل إذا كانت Supabase مكدسك بالفعل.
• تحتاج إلى SAML SSO مع عقود دعم البائعين. Auth0 وWorkOS موجودان لسبب.

لكل شخص آخر — معظم فرق SaaS المستقلة ومعظم تطبيقات Next.js — أصبحت Better Auth الآن الافتراضي الذي نوصي به في نقطة عند بدء مشروع جديد.

البدء

التثبيت والإعداد:

npm install better-auth
npx @better-auth/cli init

يرشدك CLI خلال اختيار محول قاعدة البيانات، ويولد المخطط، وينشئ ملف تكوين المصادقة، ويعد العميل. خلال خمس عشرة دقيقة يمكن أن يكون لديك بريد إلكتروني وكلمة مرور وGoogle OAuth وجلسة عاملة في تطبيق Next.js جديد.

التوثيق على الموقع الرسمي، والمصدر على GitHub تحت رخصة MIT. المكتبة على وتيرة إصدار ثابتة مع خارطة طريق واضحة ونوع متعقب المشكلات الذي يحصل على ردود في أيام، وليس أسابيع.

كانت المصادقة هي الجزء من كل مشروع نخشى لمسه. مع Better Auth، أصبحت الجزء الذي نعدّه أولاً ثم ننساه.