الهوية المشتركة بين العملاء

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يدعم تطبيق OAuth 2.0 من Google طريقة العرض هذه للعالم. لاستخدام أي من الخدمات المستندة إلى بروتوكول OAuth2.0، يجب إعداد برنامجك في Google API Console. إنّ الوحدة التنظيمية في API Console هي &&;; ملاحظاتك و—مشاريع يمكن أن تتوافق مع تطبيق متعدّد المكونات. بالنسبة إلى كل مشروع، يمكنك تقديم معلومات العلامة التجارية، وعليك تحديد واجهات برمجة التطبيقات التي يمكن للتطبيق الوصول إليها. ويتم تحديد كل مكوّن في تطبيق متعدّد المكوّنات من خلال معرّف العميل، وهو سلسلة فريدة يتم إنشاؤها في السمة API Console.

أهداف التفويض من جميع العملاء

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

عندما يمنح المستخدم إمكانية الوصول إلى تطبيقك لنطاق معيّن، ينظر المستخدم إلى شاشة موافقة المستخدم، التي تتضمّن العلامة التجارية للمنتج على مستوى المشروع التي أعددتها في Google API Console. وبالتالي، تنظر Google إلى أنّه في حال منح المستخدم إذن الوصول إلى نطاق معيّن إلى أي معرِّف عميل في المشروع، تشير المِنح إلى أنّ المستخدم ثق في التطبيق بأكمله لهذا النطاق.

ونتيجة لذلك، يجب ألا يُطلب من المستخدم الموافقة على الوصول إلى أي مورد أكثر من مرة للتطبيقات المنطقية نفسها، في حال كان من الممكن مصادقة مكوّنات التطبيق بشكل موثوق به من خلال البنية الأساسية للتفويض في Google، والتي تشمل اليوم تطبيقات الويب وتطبيقات Android وتطبيقات Chrome وتطبيقات iOS وتطبيقات سطح المكتب الأصلية والأجهزة ذات الإدخالات المحدود.

رموز الدخول عبر العملاء

يمكن للبرامج الحصول على رموز الدخول عبر OAuth 2.0 بطرق متنوعة، وذلك بناءً على النظام الأساسي الذي يتم تشغيل الرمز عليه. لمعرفة التفاصيل، راجِع استخدام OAuth 2.0 للوصول إلى Google APIs. يجب عادةً الموافقة على المستخدم عند منح رمز الدخول.

ولحسن الحظ، يمكن أن تستخدم البنية الأساسية لتفويض Google معلومات عن موافقات المستخدمين لمعرّف العميل ضمن مشروع معيّن عند تقييم ما إذا كان سيتم تفويض الآخرين في المشروع نفسه.

ونتيجة لذلك، إذا طلب تطبيق Android رمز دخول لنطاق معيّن، وكان المستخدم الذي قدّم طلب الموافقة قد وافق على تطبيق ويب في المشروع نفسه لهذا النطاق نفسه، لن يُطلب من المستخدم الموافقة مرة أخرى على الموافقة. وتعمل الطريقة في الحالتَين: إذا تم منح إمكانية الوصول إلى نطاق معيّن في تطبيق Android، لن يُطلب منه مرة أخرى من برنامج آخر في المشروع نفسه، مثل تطبيق ويب.