دليل شامل 2026

ما هو OAuth؟ وكيف تستخدم "تسجيل الدخول باستخدام Google" بأمان؟ (دليل 2026)

✍️ فريق VEXORA التقني 📅 تحديث: أغسطس 2026 ⏱️ 16 دقيقة قراءة 🏷️ الأمن السيبراني × إدارة الحسابات

TL;DR — الخلاصة السريعة

• OAuth هو البروتوكول الذي يسمح لك بتسجيل الدخول لموقع جديد باستخدام حساب Google أو Apple أو Microsoft دون أن تعطي هذا الموقع كلمة مرورك الفعلية إطلاقًا — يمنحه فقط "بطاقة صلاحية" محدودة ومؤقتة.
• في يناير 2025، كشف باحثون أمنيون ثغرة حقيقية في تدفق "تسجيل الدخول باستخدام Google" تتيح لمن يشتري نطاق شركة ناشئة مغلقة إعادة إنشاء حسابات بريد بأسماء موظفين سابقين والدخول بها لخدمات كانوا يستخدمونها — وأكدت Google أن هذا السلوك "يعمل كما هو مصمَّم".
• "تصيّد الموافقة" (Consent Phishing) أصبح من أخطر أساليب الاختراق في 2026: بدل سرقة كلمة مرورك، يخدعك المهاجم لتوافق طواعية على منح تطبيق خبيث صلاحيات واسعة عبر شاشة موافقة OAuth حقيقية تمامًا.
• الحماية الفعلية لا تحتاج تجنّب استخدام "تسجيل الدخول باستخدام Google" كليًا؛ بل تحتاج فهم شاشة الأذونات (Scopes) قبل الموافقة، ومراجعة دورية للتطبيقات المتصلة بحسابك كل 6 أشهر.

محتويات المقال

1. ما هو OAuth؟ الشرح المبسّط ببطاقة الفندق
2. الفرق بين OAuth وOpenID Connect: التفويض مقابل الهوية
3. كيف يعمل "تسجيل الدخول باستخدام Google" خطوة بخطوة
4. لماذا هذا أأمن من كلمة مرور جديدة لكل موقع (في الغالب)
5. المخاطر الحقيقية الموثّقة في 2026
6. كيف تراجع وتدير التطبيقات المتصلة بحسابك
7. كيف تقرأ شاشة الأذونات (Scopes) قبل الموافقة
8. أخطاء شائعة عند استخدام تسجيل الدخول الموحّد
9. أسئلة شائعة
10. الخلاصة

ما هو OAuth؟ الشرح المبسّط ببطاقة الفندق

OAuth 2.0 هو بروتوكول تفويض (Authorization) يسمح لتطبيق أو موقع ("العميل" Client) بالوصول لبيانات محددة في حسابك على خدمة أخرى ("خادم الموارد" Resource Server، مثل Google) دون أن يحصل على كلمة مرورك الفعلية إطلاقًا. بدل ذلك، يحصل على "رمز وصول" (Access Token) مؤقت ومحدود الصلاحيات.

أبسط طريقة لفهم الفكرة: تخيّل أنك تصل إلى فندق. بدل أن تعطي موظف الاستقبال مفتاحك الرئيسي (كلمة المرور)، يتحقق الفندق من هويتك ثم يعطيك بطاقة مفتاح مؤقتة (Access Token) تفتح غرفتك فقط، لفترة محددة، ويمكن إلغاؤها في أي وقت دون التأثير على مفتاحك الرئيسي. هذا بالضبط ما يحدث عندما تضغط "تسجيل الدخول باستخدام Google": الموقع الجديد لا يرى كلمة مرور Google الخاصة بك أبدًا؛ يحصل فقط على بطاقة صلاحية محدودة النطاق.

الفرق بين OAuth وOpenID Connect: التفويض مقابل الهوية

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

OAuth 2.0 (التفويض)

• يجيب عن: "ما الذي يمكن لهذا التطبيق فعله في حسابي؟"
• يصدر Access Token يحدد نطاق الصلاحيات (Scopes) الممنوحة
• لا يخبر التطبيق بالضرورة بهويتك الحقيقية

OpenID Connect (المصادقة)

• يجيب عن: "من أنت فعليًا؟"
• يضيف ID Token يحمل معلومات هويتك (الاسم، البريد) فوق آلية OAuth نفسها
• هذا هو ما يجعل "تسجيل الدخول باستخدام Google" تسجيل دخول حقيقي، لا مجرد تفويض صلاحية

لماذا هذا الفارق التقني يهمك كمستخدم عادي؟ عمليًا، كل مرة تضغط فيها "تسجيل الدخول باستخدام Google" فأنت تستخدم كلا البروتوكولين معًا: OpenID Connect يثبت هويتك للموقع الجديد، وOAuth يحدد بدقة ما الذي يمكن لهذا الموقع الوصول إليه في حسابك (البريد فقط؟ جهات الاتصال؟ ملفات Drive؟). شاشة "الموافقة" التي تراها قبل تسجيل الدخول هي بالضبط النقطة التي يتحدد فيها هذا النطاق — وهي أهم جزء في هذا المقال بأكمله.

كيف يعمل "تسجيل الدخول باستخدام Google" خطوة بخطوة

تضغط "تسجيل الدخول بـGoogle" على موقع جديد

←

يُعاد توجيهك لصفحة تسجيل دخول Google الحقيقية

←

تراجع شاشة الأذونات وتوافق

←

Google تصدر رمز وصول محدود النطاق للموقع

←

الموقع يستخدم الرمز دون رؤية كلمة مرورك أبدًا

النمط الموصى به تقنيًا في 2026 لهذا التدفق يُسمى "رمز التفويض مع PKCE" (Authorization Code + PKCE)، وهو مصمَّم خصيصًا لمنع اعتراض رمز الوصول أثناء عملية إعادة التوجيه، حتى في تطبيقات الجوال التي لا تستطيع تخزين أسرار (Secrets) بأمان تام. معظم مزودي الهوية الكبار (Google، Apple، Microsoft) يطبّقون هذا النمط افتراضيًا اليوم.

لماذا هذا أأمن من كلمة مرور جديدة لكل موقع (في الغالب)

✅ مزايا حقيقية

• لا تُنشئ كلمة مرور جديدة يمكن اختراقها أو تسريبها في حال تعرّض ذلك الموقع تحديدًا لاختراق قاعدة بياناته
• يمكنك إلغاء الوصول فورًا من مكان مركزي واحد (حساب Google) دون الحاجة لتغيير كلمة مرور في كل موقع منفصل
• يستفيد تلقائيًا من طبقات أمان حساب Google نفسه (المصادقة الثنائية، كشف تسجيل الدخول المشبوه)

⚠️ لكن هذا يخلق نقطة فشل واحدة مركزية

• إذا تم اختراق حساب Google الرئيسي نفسه، فقد يفتح ذلك الباب لكل الحسابات المرتبطة به عبر OAuth دفعة واحدة
• يجعل من الضروري أكثر من أي وقت مضى تأمين الحساب "الأساسي" (Google/Apple/Microsoft) بأقصى درجة ممكنة من الحماية

المخاطر الحقيقية الموثّقة في 2026

هذا القسم مبني بالكامل على حوادث وثغرات موثّقة فعليًا، لا سيناريوهات افتراضية.

ثغرة إعادة استخدام النطاقات المنتهية (موثّقة، يناير 2025) كشف باحثون أمنيون ثغرة حقيقية في تدفق "تسجيل الدخول باستخدام Google": حين تُغلق شركة ناشئة ويترك نطاقها (Domain) ينتهي، يستطيع أي شخص شراء ذلك النطاق منتهي الصلاحية وإعادة إنشاء عناوين بريد إلكتروني مطابقة لأسماء الموظفين السابقين. بما أن Google تعتمد على عنوان البريد ونطاقه لتحديد هوية المستخدم عبر OAuth، فإن هذه الحسابات المُعاد إنشاؤها تستطيع تسجيل الدخول لأي خدمة استخدم فيها الموظف السابق "تسجيل الدخول باستخدام Google" — بما فيها أنظمة موارد بشرية تحتوي مستندات ضريبية وبيانات تأمين حساسة. أكدت Google رسميًا أن هذا السلوك "يعمل كما هو مصمَّم" (working as intended)، ما يعني أن المسؤولية تقع على الشركات لإلغاء ربط الحسابات فور إغلاق أي نطاق تنظيمي.

تصيّد الموافقة (Consent Phishing) بدل محاولة سرقة كلمة مرورك مباشرة، يرسل المهاجم رابطًا يقودك إلى شاشة موافقة OAuth حقيقية تمامًا (تابعة فعليًا لـGoogle أو Microsoft)، لكن التطبيق الذي يطلب الصلاحيات تطبيق خبيث يطلب نطاقًا واسعًا جدًا من الأذونات (قراءة كل بريدك، الوصول لملفاتك). بما أن الشاشة نفسها حقيقية وشرعية تمامًا، يوافق الضحية دون شك، ويمنح التطبيق الخبيث وصولًا مستمرًا دون الحاجة لسرقة أي كلمة مرور إطلاقًا. تقارير التصيّد الإلكتروني لعام 2025 تصف هذا النمط بأنه أصبح "سلسلة التوريد الجديدة" لهجمات البريد الإلكتروني والأنظمة السحابية المؤسسية.

ضعف حماية CSRF في منصات تكامل غير موثوقة ثغرات موثّقة في عدة منصات تكامل API موحّدة أظهرت أن ضعف تطبيق معامل "الحالة" (State Parameter) في تدفق OAuth يتيح للمهاجمين انتحال شخصية تطبيقات OAuth موثوقة ومعروفة مسبقًا لدى المستخدمين، ما يرفع احتمالية نجاح هجمات التصيّد لأن المستخدم يرى اسم تطبيق يثق به بالفعل.

كيف تراجع وتدير التطبيقات المتصلة بحسابك

1. لحساب Google: اذهب إلى myaccount.google.com/permissions لرؤية قائمة كاملة بكل التطبيقات ذات الوصول لحسابك، مع تفاصيل الصلاحيات الممنوحة لكل منها بالضبط.
2. لحساب Microsoft: اذهب إلى Settings > Security and Account Access > Apps and Sessions > Connected Apps لمراجعة نفس القائمة على منصة Microsoft.
3. لحساب Facebook/Meta: اذهب إلى Settings & Privacy > Settings > Apps and Websites لرؤية أي تطبيق خارجي حصل على وصول عبر حسابك.
4. طبّق القاعدة البسيطة: إذا كنت لا تتعرف على التطبيق، أو لم تستخدمه منذ أكثر من 6 أشهر، اضغط "إزالة الوصول" (Remove Access) فورًا دون تردد.
5. انتبه بشكل خاص للاختبارات والألعاب القديمة: تطبيقات الاختبارات الترفيهية (Quizzes) القديمة غالبًا ما تطلب أذونات أوسع بكثير مما تحتاجه فعليًا، وتبقى منسية دون استخدام لسنوات.

عادة أمان يوصى بها من خبراء الأمن السيبراني خصص تذكيرًا كل 6 أشهر بالضبط لإجراء "تدقيق OAuth" كامل لحسابك الرئيسي — مراجعة شاملة لكل تطبيق متصل، بدل الانتظار حتى تشك بمشكلة أمنية فعلية. هذا يقلل بشكل كبير من "سطح الهجوم" (Attack Surface) المتراكم بمرور الوقت دون أن تلاحظه.

كيف تقرأ شاشة الأذونات (Scopes) قبل الموافقة

الخطأ الأكثر شيوعًا هو الضغط على "السماح" أو "متابعة" بشكل تلقائي دون قراءة ما تطلبه شاشة الموافقة فعليًا. المبدأ التقني الذي يجب أن يحكم قرارك هو "الحد الأدنى من الصلاحيات" (Principle of Least Privilege): هل يحتاج هذا التطبيق فعليًا كل ما يطلبه لوظيفته المعلنة؟

أمثلة على أذونات OAuth شائعة ومدى معقوليتها حسب نوع التطبيق

الإذن المطلوب	معقول لـ	مثير للريبة إذا طلبه
عنوان البريد الإلكتروني الأساسي فقط	أي تطبيق يستخدم "تسجيل الدخول" كوظيفة أساسية	—
قراءة جهات الاتصال الكاملة	تطبيقات إدارة علاقات العملاء أو التواصل	لعبة أو أداة تحويل ملفات بسيطة
قراءة/إرسال البريد الإلكتروني نيابة عنك	أدوات إدارة البريد أو الأتمتة المصرَّح بها	أي تطبيق لا علاقة له مباشرة بالبريد الإلكتروني
الوصول الكامل لملفات Google Drive	أدوات النسخ الاحتياطي أو التحرير التعاوني	تطبيق طقس أو حاسبة بسيطة

أخطاء شائعة عند استخدام تسجيل الدخول الموحّد

❌ الموافقة التلقائية دون قراءة شاشة الأذونات

• الضغط على "السماح" بشكل انعكاسي هو الفجوة الأمنية الأكثر استغلالًا في هجمات تصيّد الموافقة

❌ عدم إلغاء ربط الحسابات بعد ترك وظيفة أو إغلاق شركة

• كما أثبتت ثغرة إعادة استخدام النطاقات، تسجيلات الدخول المرتبطة بحسابات عمل سابقة تبقى نشطة إذا لم تُلغَ يدويًا

❌ إهمال تأمين الحساب "الأساسي" الذي تُربط به كل الحسابات الأخرى

• حساب Google أو Microsoft الذي تستخدمه لتسجيل الدخول في كل مكان يستحق أقصى درجة ممكنة من الحماية (مصادقة ثنائية، مفتاح أمان مادي إن أمكن)

❌ الخلط بين شاشة موافقة "شرعية تقنيًا" و"آمنة فعليًا"

• شاشة الموافقة قد تكون حقيقية تمامًا (من Google نفسها) بينما التطبيق الذي يطلب الأذونات خبيث؛ الشرعية التقنية للشاشة لا تعني أمان التطبيق

أسئلة شائعة

هل "تسجيل الدخول باستخدام Google" يعطي الموقع الجديد كلمة مروري؟

لا، إطلاقًا. هذه هي الفكرة الأساسية من بروتوكول OAuth بالكامل: الموقع الجديد يحصل فقط على رمز وصول محدود النطاق ومؤقت، ولا يرى كلمة مرورك الفعلية لحساب Google في أي مرحلة من العملية.

ما الفرق العملي بين OAuth وOpenID Connect؟

OAuth 2.0 يحدد ما الذي يُسمح للتطبيق بفعله في حسابك (التفويض)، بينما OpenID Connect طبقة إضافية فوقه تثبت هويتك الفعلية للتطبيق (المصادقة). عمليًا، "تسجيل الدخول باستخدام Google" يستخدم كلا البروتوكولين معًا في نفس العملية.

هل يجب أن أتجنب استخدام "تسجيل الدخول باستخدام Google" تمامًا لأسباب أمنية؟

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

كيف أعرف أن شاشة "الموافقة" التي أراها حقيقية وليست تصيّدًا؟

تحقق أن عنوان الصفحة في شريط المتصفح ينتمي فعليًا لنطاق مزوّد الهوية الحقيقي (accounts.google.com مثلًا، لا نطاقًا مشابهًا مزيَّفًا). لكن تذكّر أن الخطر الأكبر في 2026 ليس شاشات مزيّفة، بل شاشات حقيقية تمامًا تطلب أذونات واسعة لتطبيق خبيث؛ لذا التركيز الأهم هو على قراءة الأذونات المطلوبة نفسها لا فقط التحقق من صحة الرابط.

الخلاصة

OAuth غيّر طريقة تسجيل الدخول عبر الإنترنت للأفضل بشكل جوهري، وأزال الحاجة لتذكّر عشرات كلمات المرور المختلفة. لكن كأي تقنية قوية، الفهم السطحي لها ("زر أزرق يسهّل تسجيل الدخول") يترك ثغرات حقيقية يستغلها المهاجمون عبر تصيّد الموافقة وثغرات إعادة استخدام النطاقات الموثّقة. الحماية الفعلية بسيطة عمليًا: اقرأ شاشة الأذونات قبل الموافقة، خصص وقتًا كل 6 أشهر لمراجعة التطبيقات المتصلة بحسابك الرئيسي، وأمِّن ذلك الحساب الرئيسي بأقصى درجة ممكنة — لأنه أصبح المفتاح الذي يفتح كل الأبواب الأخرى في حياتك الرقمية.

المصادر

• Truffle Security — Millions of Accounts Vulnerable due to Google's OAuth Flaw: trufflesecurity.com
• Forbes — Millions of Sign-In-With-Google Users Warned of Data-Theft Vulnerability: forbes.com
• ScorchingTECH — Is "Log in with Google" Safe? Understanding OAuth Risks (2026): scorchingtech.com
• Software Architecture Insights — The Hidden Risks of 'Sign In with Google': softwarearchitectureinsights.com
• Authgear — How OAuth 2.0 Works: A Developer's Guide (2026): authgear.com
• freeCodeCamp — How OAuth 2.0 Works: A Practical Guide for Backend Developers: freecodecamp.org

فريق VEXORA التقني

نغطي الأمن السيبراني، إدارة الهوية الرقمية، وحماية الحسابات بتحليل معمّق موجّه للقارئ العربي، بالاعتماد على مصادر رسمية وبيانات محدّثة باستمرار.

هل تريد تأمين حساباتك الرقمية خطوة بخطوة؟

تابع VEXORA لمزيد من الأدلة العملية حول الأمن السيبراني، إدارة الهوية الرقمية، وحماية الحسابات.

استكشف المزيد على VEXORA