ما هو OAuth؟ «تسجيل الدخول بحساب Google» والوصول المفوّض

OAuth معيار مفتوح يتيح لمستخدم أن يمنح تطبيقًا واحدًا وصولًا محدودًا إلى حسابه في خدمة أخرى، دون أن يسلّمه كلمة المرور. حين تنقر «Connect Google Calendar» وترى شاشة تسأل «هل تسمح لهذا التطبيق برؤية أحداثك؟»، فهذا هو OAuth. يحصل التطبيق على رمز يخص ما وافقت عليه فقط، ويمكنك إلغاؤه في أي وقت. والآلية نفسها، مع طبقة إضافية تسمى OpenID Connect، تشغّل «تسجيل الدخول بحساب Google» وأزرار مشابهة.

لماذا يهم OAuth عند البناء بالذكاء الاصطناعي

يظهر OAuth في حالتين شائعتين حين تبني تطبيقًا:

1. تسجيل الدخول الاجتماعي. تريد أن يستطيع مستخدموك «تسجيل الدخول بحساب Google» (أو Apple أو Microsoft أو GitHub) بدلًا من إنشاء كلمة مرور جديدة. انظر كيف تضيف تسجيل دخول إلى تطبيقك.
2. الاتصال بحسابات المستخدمين في خدمات أخرى. يحتاج تطبيقك إلى قراءة تقويم المستخدم، أو النشر على حسابه الاجتماعي، أو سحب الملفات من سحابته، أو مزامنة بيانات محاسبته.

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

تشبيه يومي

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

• الاستقبال هو خادم التفويض (صفحة تسجيل دخول Google).
• التحقق من هويتك هو تسجيلك الدخول إلى Google.
• بطاقة المفتاح هي رمز الوصول (Access Token).
• «الغرفة والنادي فقط» هي النطاقات (Scopes) التي وافقت عليها.
• المغادرة هي انتهاء صلاحية الرمز، أو إلغاؤك الوصول يدويًا.

التطبيق الذي تستخدمه لا يرى كلمة مرور Google أبدًا، بل يرى البطاقة فقط.

كيف يعمل OAuth خطوة بخطوة

أكثر التدفقات شيوعًا لتطبيقات الويب هو تدفق رمز التفويض (Authorization Code Flow). هذا ما يحدث حين يربط مستخدم تقويم Google الخاص به بتطبيق جدولة مواعيد:

1. النقر. ينقر المستخدم «Connect Google Calendar».
2. التوجيه إلى المزود. يرسل التطبيق المتصفح إلى Google مع معرّف العميل الخاص به، والنطاقات التي يريدها (قراءة أحداث التقويم)، وعنوان الرد (Redirect URI) الذي يجب أن تعيد Google المستخدم إليه.
3. تسجيل الدخول والموافقة. يسجل المستخدم الدخول إلى Google (إذا لم يكن مسجلًا)، ويرى شاشة الموافقة التي تعرض ما يطلبه التطبيق، فينقر «Allow».
4. العودة برمز. تعيد Google توجيه المتصفح إلى عنوان الرد الخاص بالتطبيق مع رمز تفويض (Authorization Code) قصير العمر ويُستخدم مرة واحدة.
5. التبادل على الخادم. يرسل خادم التطبيق هذا الرمز، مع السر الخاص به، مباشرة إلى Google فيستلم رمز وصول (وغالبًا رمز تحديث).
6. استخدام الواجهة. يستدعي الخادم واجهة تقويم Google برمز الوصول فيحصل على أحداث المستخدم.

يبدو رد النداء في الخطوة 4 هكذا:

https://yourapp.com/auth/google/callback?code=4/0Adeu5B...&state=x7Kq9

والرد الذي يحتوي الرمز في الخطوة 5 هو JSON بهذا الشكل:

{
  "access_token": "ya29.a0Af...",
  "expires_in": 3599,
  "refresh_token": "1//0gL...",
  "scope": "https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

OAuth مقابل OpenID Connect ومقابل تسجيل الدخول الخاص بك

كثير من التطبيقات تجمع بينها: تسجيل دخول بالبريد وكلمة المرور، إضافةً إلى «تسجيل الدخول بحساب Google» عبر OIDC، واتصالات OAuth منفصلة بخدمات أخرى.

مصطلحات أساسية

مفاهيم خاطئة شائعة

• «OAuth نظام تسجيل دخول». OAuth العادي يمنح الوصول، أما OpenID Connect فيتولى الهوية. واستخدام رمز وصول خام كدليل على هوية شخص ما تسبب في أخطاء أمنية حقيقية.
• «التطبيق يحصل على كلمة مروري». لا يحدث ذلك أبدًا. وتلك هي الفكرة.
• «طلب صلاحيات أكثر لا يضر». المستخدمون يتوجسون من الطلبات الواسعة، وقد تشترط مزودات مثل Google مراجعة التطبيق للصلاحيات الحساسة أو المقيّدة. اطلب فقط ما تحتاجه.
• «السر الخاص بالعميل يمكن وضعه في الواجهة الأمامية». أي شيء في كود المتصفح عام. احتفظ به في أسرار الخادم.
• «يعمل في الاختبار إذن سيعمل في الإنتاج». كثير من المزودات تحد من التطبيقات غير المُتحقَّق منها، مثل قصرها على مستخدمين تجريبيين مسجلين، ويجب تسجيل عنوان الرد للنطاق الحي بشكل منفصل.
• «الرموز تدوم إلى الأبد». رموز الوصول تنتهي بسرعة، ويستطيع المستخدمون إلغاء الوصول. ويجب أن يتعامل تطبيقك مع الحالتين بسلاسة.

ماذا تسأل مُنشئ التطبيقات بالذكاء الاصطناعي

• «أضف زر „تسجيل الدخول بحساب Google“ باستخدام OpenID Connect ومكتبة مصادقة مُصانة جيدًا، ولا تكتب تدفق OAuth بنفسك.»
• «استخدم تدفق رمز التفويض مع PKCE، وتحقق من معامل state.»
• «اقرأ معرّف العميل والسر من متغيرات البيئة على الخادم.»
• «اطلب النطاقات التي نحتاجها فقط: قراءة التقويم دون تعديل.»
• «اذكر لي كل عنوان إعادة توجيه أحتاج إلى تسجيله في لوحة المزود: للمعاينة، والرابط المنشور، ونطاقي المخصص.»
• «خزّن رموز التحديث مشفّرة في قاعدة البيانات، وعند انتهاء الرمز أو إلغائه اطلب من المستخدم إعادة الربط.»
• «اسمح للمستخدمين بفصل التكامل من صفحة إعداداتهم.»

OAuth وMythex

لا يملك Mythex تسجيل دخول مدمجًا للمستخدمين النهائيين في التطبيقات التي تبنيها؛ فوثائقه تصف نهجًا تأتي فيه بأداة المصادقة الخاصة بك: تختار مكتبة مصادقة أو مزودًا مستضافًا، وتخزن مفاتيحه كـأسرار المشروع، ويكتب الوكيل الكود. ووصفة إضافة المصادقة تتضمن طلبًا جاهزًا لذلك. وستصادف OAuth في Mythex نفسها أيضًا: يمكنك التسجيل بحساب Google، وربط GitHub لمزامنة المستودعات يستخدم OAuth الخاص بـ GitHub، والمساعدون الذين يتصلون بـ Mythex عبر MCP يمرون عبر صفحة موافقة OAuth. للمزيد، انظر ما هي المصادقة وما هي المصادقة الثنائية.

الأسئلة