تسجيل الدخول عبر Google في موقعك: دليل OAuth وSSO

يُضاف تسجيل الدخول عبر Google إلى الموقع أو التطبيق باستخدام OAuth 2.0 وطبقة الهوية المبنية فوقه OpenID Connect (OIDC). الجواب المختصر: يُحوَّل المستخدم إلى Google، فتتحقق Google من هويته وترسل إلى موقعك ID token موقّعًا؛ يتحقق خادمك من توقيع هذا الرمز والجهة الموجّه إليها، ويطابق المستخدم مع سجلاتك، ثم يفتح جلسة خاصة بك. موقعك لا يرى كلمة مرور Google ولا يخزّنها أبدًا. الإعداد التقني سريع؛ أما ما يطيل المشروع فهو ربط الحسابات وإدارة الجلسات ومتطلبات تسجيل الدخول الموحد (SSO) لدى عملاء الشركات. تشرح هذه المقالة التدفق الذي نطبّقه في مشاريع الويب المؤسسية؛ وهي جانب المصادقة في خدمة تطوير الويب لدينا.

OAuth وOpenID Connect وSSO: ما الفرق؟

تُستخدم هذه المصطلحات الثلاثة بالتبادل في الحديث اليومي، لكنها تجيب عن ثلاثة أسئلة مختلفة. OAuth 2.0 بروتوكول لتفويض الصلاحيات: يقول «يمكن لهذا التطبيق قراءة تقويمي نيابةً عني»، ولا يقول من أنت. OpenID Connect هو طبقة الهوية فوق OAuth: يحمل ID token موقّع معلومة «هذا المستخدم هو هذه الهوية وبريده مؤكَّد». تسجيل الدخول عبر Google هو عمليًا OpenID Connect. أما SSO (تسجيل الدخول الموحد) فهو هدف معماري: يسجّل المستخدم الدخول مرة واحدة ويصل إلى عدة تطبيقات دون إدخال كلمة مرور أخرى. وهناك حاجتان مختلفتان:

• الدخول الاجتماعي (B2C): يسجّل عملاؤك ويدخلون بحساب Google أو Apple أو Microsoft. الهدف تقليل الاحتكاك وعدم تحمّل إدارة كلمات المرور.
• SSO للشركات (B2B / التطبيقات الداخلية): يدخل الموظفون عبر مزوّد هوية الشركة (Google Workspace أو Microsoft Entra ID أو Keycloak). الهدف إدارة مركزية للوصول: من يغادر الشركة يُقطع وصوله من مكان واحد.

يستخدم الاثنان البروتوكول نفسه، لكن قرارات المنتج تختلف. في الدخول الاجتماعي يختار المستخدم المزوّد؛ وفي SSO للشركات تحدد الشركة العميلة المزوّد وغالبًا ما تريد ربط مستأجرها الخاص عبر SAML أو OIDC.

تدفق تسجيل الدخول عبر Google خطوة بخطوة

التدفق الموصى به هو «authorization code مع PKCE». التدفق الضمني القديم الذي كان يولّد الرموز في المتصفح لم يعد موصى به؛ تُحصَّل الرموز دائمًا على الخادم، ولا يصل إلى المتصفح سوى ملف تعريف ارتباط الجلسة الخاص بك.

• يُنشأ عميل OAuth في Google Cloud Console؛ وتُسجَّل عناوين إعادة التوجيه المسموح بها (redirect URI) بمطابقة تامة دون أحرف بدل.
• عندما يضغط المستخدم «تسجيل الدخول عبر Google» يولّد الخادم قيمة state عشوائية وcode_verifier الخاص بـ PKCE، ويحفظهما في ملف تعريف ارتباط قصير العمر، ثم يحوّل المستخدم إلى عنوان التفويض في Google.
• تتحقق Google من الهوية، وتعرض للمستخدم البيانات التي ستُشارَك وتطلب موافقته؛ ثم يعود المتصفح إلى عنوان callback لديك ومعه code.
• يقارن الخادم state مع ملف تعريف الارتباط، ويستبدل code بـ ID token عند نقطة الرموز في Google (مع client_secret وcode_verifier).
• يُتحقق من توقيع ID token بمفاتيح Google المنشورة، ومن حقلي iss وaud ومدة الصلاحية؛ ويجب أن يكون البريد مؤكَّدًا.
• يُعثر على المستخدم في قاعدة البيانات أو يُنشأ، ويكتمل الدخول بملف تعريف ارتباط الجلسة الخاص بك. رمز Google لا يُرسل إلى المتصفح أبدًا.

مثال: callback كـ route handler في Next.js

// app/api/auth/google/callback/route.ts
import { createRemoteJWKSet, jwtVerify } from 'jose';

const GOOGLE_JWKS = createRemoteJWKSet(
  new URL('https://www.googleapis.com/oauth2/v3/certs'),
);

export async function GET(req: Request) {
  const url = new URL(req.url);
  const code = url.searchParams.get('code');
  const state = url.searchParams.get('state');

  // state كُتب في ملف تعريف ارتباط عند بدء الدخول: فحص CSRF
  if (!code || !state || state !== await readStateCookie()) {
    return new Response('Invalid request', { status: 400 });
  }

  // استبدال code بالرمز يتم دائمًا على الخادم
  const tokenRes = await fetch('https://oauth2.googleapis.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      code,
      grant_type: 'authorization_code',
      client_id: process.env.GOOGLE_CLIENT_ID!,
      client_secret: process.env.GOOGLE_CLIENT_SECRET!,
      redirect_uri: process.env.GOOGLE_REDIRECT_URI!,
      code_verifier: await readVerifierCookie(),
    }),
  });
  const { id_token } = (await tokenRes.json()) as { id_token: string };

  // التحقق من التوقيع والمُصدِر والجهة المستقبلة والصلاحية
  const { payload } = await jwtVerify(id_token, GOOGLE_JWKS, {
    issuer: ['https://accounts.google.com', 'accounts.google.com'],
    audience: process.env.GOOGLE_CLIENT_ID,
  });
  if (payload.email_verified !== true) {
    return new Response('Email not verified', { status: 403 });
  }

  // الهوية هي قيمة "sub" الدائمة من Google وليست عنوان البريد
  const user = await findOrLinkUser({
    provider: 'google',
    subject: payload.sub!,
    email: String(payload.email),
  });

  return createSessionAndRedirect(user.id, '/dashboard');
}

ربط الحسابات: حيث تتعثر المشاريع

معظم المواقع التي تضيف تسجيل الدخول عبر Google لديها بالفعل مستخدمون مسجّلون بالبريد وكلمة المرور. إذا لم يُقرَّر مسبقًا ما يحدث عندما يدخل الشخص نفسه عبر Google، فإما أن ينشأ حسابان منفصلان أو يُدمج الحساب الخطأ. ثلاث قواعد تحل المشكلة. الأولى: هوية المستخدم ليست عنوان بريده بل قيمة sub الدائمة التي ترسلها Google؛ البريد يتغير وsub لا يتغير. الثانية: الدمج التلقائي مع حساب قائم يتم فقط إذا كانت Google قد أكّدت البريد؛ وإلا أمكن لحساب يدّعي بريد شخص آخر أن يسجّل الدخول. الثالثة: يجب أن يتمكن المستخدم من ربط أكثر من مزوّد، لذلك تُحفظ بيانات المزوّد في جدول «هويات» منفصل (المستخدم، المزوّد، sub) لا كأعمدة في جدول المستخدمين.

مفتاح المستخدم ليس البريد بل المعرّف الدائم الذي يصدره المزوّد. النظام الذي يعتمد البريد مفتاحًا يخلط بين الحسابات بمجرد تغيّر العنوان أو إرسال مزوّد آخر العنوان نفسه دون تأكيد.

SSO للشركات: Google Workspace وMicrosoft Entra

عندما يُطلب SSO لمنتج B2B أو للوحة داخلية، تكبر المهمة ببضع خطوات. يجب تقييد النطاقات المسموح لها بالدخول: حقل hd في ID token من Google يحمل نطاق Workspace الخاص بالمستخدم، لكنه مجرد فحص ولا يغني عن التفويض. إذا كان المستخدمون يُنشؤون تلقائيًا عند أول دخول (just-in-time provisioning) فيجب تحديد الدور الذي يبدؤون به؛ شرحنا تصميم الأدوار في مقالة أدوار المستخدمين والتفويض. وإذا كان سيُربط Microsoft Entra أو مستأجر آخر، فعادةً ما يسجّل العميل تطبيقك من جهته عبر SAML أو OIDC، وتحتفظ أنت بمُصدِر ومجموعة مفاتيح منفصلة لكل عميل. أكثر بند يُنسى هو الخروج: عندما يغادر الموظف الشركة يُغلق حسابه لدى مزوّد الهوية، لكن جلستك المفتوحة تبقى حية حتى انتهاء مدتها. اجعل الجلسات قصيرة أو استمع إلى إشعار الخروج من المزوّد.

قائمة الفحص الأمنية

• state وPKCE إلزاميان في كل طلب؛ state يُستخدم مرة واحدة ويُقارن بملف تعريف الارتباط عند callback.
• تُسجَّل عناوين redirect URI بمطابقة تامة؛ يُستخدم عميل منفصل للاختبار وآخر للإنتاج، ولا يوضع client_secret في المتصفح أو حزمة التطبيق أبدًا.
• يُستخدم ID token للهوية فقط؛ أما تفويض استدعاءات API فيتم بجلستك أو برمز تصدره أنت. إرسال ID token إلى خدمات أخرى كأنه مفتاح وصول خطأ شائع.
• تبقى النطاقات (scope) في حدها الأدنى: openid وemail وprofile تكفي لمعظم المواقع. الوصول إلى التقويم أو Drive يُطلب منفصلًا ولاحقًا عند الحاجة.
• يُصمَّم مسار الاستعادة للمستخدم الذي يفقد حساب Google مسبقًا: رابط بريدي لمرة واحدة أو مزوّد ثانٍ. الحسابات المرتبطة بمزوّد واحد هي أكثر مصادر طلبات الدعم.
• تُفرض حدود معدل على نقاط الدخول وتُسجَّل المحاولات الفاشلة؛ أما بقية أسطح الهجوم فنتناولها في مقالة أمان الموقع الإلكتروني.

في العمليات عالية المخاطر (تأكيد الدفع، تغيير الصلاحيات) لا يكفي الدخول عبر Google وحده؛ اطلب تحققًا ثانيًا لحظة تنفيذ العملية. تناولنا هذا الجانب في مقالة التحقق عبر رمز SMS OTP.

خدمة هوية جاهزة أم بناء ذاتي؟

الخدمات المستضافة مثل Auth0 وFirebase Authentication وClerk، والمنتجات التي تشغّلها على خادمك مثل Keycloak، تقدّم هذا التدفق كاملًا مع إعادة تعيين كلمة المرور والمصادقة متعددة العوامل جاهزةً. لمزوّد واحد ونموذج مستخدمين بسيط يكفي بناء ذاتي بمكتبة مثل Auth.js، وتبقى بيانات المستخدمين في قاعدة بياناتك. أما إذا طُلبت معًا SSO متعدد المستأجرين ودعم SAML والمصادقة متعددة العوامل وسجلات التدقيق، فإن الخدمة الجاهزة أو Keycloak تختصر المشروع أسابيع. يحسم القرار سؤالان: أين ستُخزَّن بيانات المستخدمين، وهل يمكن عند مغادرة الخدمة تصدير المستخدمين مع تجزئات كلمات المرور؟ إذا كان جدول المستخدمين في قاعدة بياناتك فإن السؤال الثاني يحل نفسه؛ ويتوافق هذا النهج مع نموذج تعدد المستأجرين في مقالة تطوير منتج SaaS.

ملاحظة حول البيانات الشخصية

مع تسجيل الدخول عبر Google يصل إليك الاسم والبريد وصورة الملف الشخصي؛ وهذه بيانات شخصية يجب أن تذكر سياسة الخصوصية مصدرها (مزوّد الهوية) والغرض من معالجتها. اطلب فقط ما يحتاجه الدخول ولا تخزّن صورة الملف الشخصي إن لم تُستخدم. الإطار القانوني التركي موضح في مقالة الموقع المتوافق مع KVKK؛ وهذا النص ليس استشارة قانونية.

الخلاصة

عند تنفيذه بشكل صحيح، يمنح تسجيل الدخول عبر Google المستخدمين تسجيلًا بلا احتكاك ويعفي موقعك من تخزين كلمات المرور. التدفق التقني قياسي؛ وما يحدد المشروع هو قواعد ربط الحسابات، وعمر الجلسة، وتوقعات عملاء الشركات بشأن SSO. إذا أردت إضافة الدخول الاجتماعي أو SSO للشركات إلى موقع قائم، أرسل متطلباتك عبر نموذج طلب العرض ولنخطط التدفق معًا مع جدول المستخدمين الحالي لديك.