عندما ينشئ المطوّرون برامج، فإنّها تتضمّن عادةً وحدات تعمل على خادم ويب، ووحدات أخرى تعمل في المتصفّح، ووحدات أخرى تعمل كتطبيقات جوّالة على Android أو iOS. ويعتبر كل من المطوّرين والمستخدمين هذه الوحدات النمطية جزءًا من تطبيق واحد.
يتوافق تنفيذ بروتوكول OAuth 2.0 من Google مع هذا التصوّر للعالم. لاستخدام أي من الخدمات المستندة إلى OAuth2.0، يجب إعداد برنامجك في Google API Console. وحدة التنظيم في API Console هي "مشروع"، ويمكن أن يتوافق مع تطبيق متعدد المكونات. ويمكنك تقديم معلومات عن العلامة التجارية لكل مشروع، ويجب تحديد واجهات برمجة التطبيقات التي سيصل إليها التطبيق. يتم تحديد كل مكوّن من مكونات التطبيق المتعدد المكونات من خلال معرّف العميل، وهو سلسلة فريدة يتم إنشاؤها في API Console.
أهداف تفويض الحسابات المتعددة
عندما يستخدم تطبيق الإصدار 2.0 من OAuth للحصول على التفويض، يعمل التطبيق نيابةً عن المستخدم لطلب رمز مميز للوصول من الإصدار 2.0 من OAuth للوصول إلى أحد الموارد، ويحدّد التطبيق هذا المورد باستخدام سلسلة واحدة أو أكثر من سلاسل النطاق. عادةً، يُطلب من المستخدم الموافقة على إذن الوصول.
عندما يمنح المستخدم إذن الوصول إلى تطبيقك لنطاق معيّن، تظهر له شاشة طلب الموافقة التي تتضمّن العلامة التجارية للمنتج على مستوى المشروع والتي أعددتها في Google API Console. لذلك، ترى Google أنّه عندما يمنح المستخدم إذن الوصول إلى نطاق معيّن لأي رقم تعريف عميل في أحد المشاريع، يشير هذا الإذن إلى ثقة المستخدم في التطبيق بأكمله لهذا النطاق.
والنتيجة هي أنّه لن يُطلب من المستخدم الموافقة على الوصول إلى أي مورد أكثر من مرة واحدة للتطبيق المنطقي نفسه، وذلك عندما يمكن لمكوّنات التطبيق إثبات صحة هويتها بشكل موثوق من خلال البنية الأساسية لمنح الأذونات في Google، والتي تشمل حاليًا تطبيقات الويب وتطبيقات Android وتطبيقات Chrome وتطبيقات iOS وتطبيقات الكمبيوتر والأجهزة ذات الإدخال المحدود.
رموز الدخول على مستوى حسابات العملاء
يمكن للبرامج الحصول على رموز الدخول المميزة لبروتوكول OAuth 2.0 بطرق مختلفة، وذلك حسب النظام الأساسي الذي يتم تشغيل الرمز عليه. لمعرفة التفاصيل، يُرجى الاطّلاع على استخدام بروتوكول OAuth 2.0 للدخول إلى واجهات Google APIs. عادةً، يجب الحصول على موافقة المستخدم عند منح رمز دخول.
لحسن الحظ، يمكن أن تستخدم البنية الأساسية لتفويض Google معلومات حول موافقات المستخدمين على رقم تعريف العميل ضمن مشروع معيّن عند تقييم ما إذا كان سيتم تفويض مستخدمين آخرين في المشروع نفسه.
ويتمثّل التأثير في أنّه إذا طلب تطبيق Android رمز دخول لنطاق معيّن، وكان المستخدم الذي يقدّم الطلب قد منح الموافقة من قبل لتطبيق ويب في المشروع نفسه على النطاق نفسه، لن يُطلب من المستخدم الموافقة مرة أخرى. ويعمل ذلك في كلا الاتجاهين: إذا تم منح إذن الوصول إلى نطاق في تطبيق Android، لن يُطلب الإذن مرة أخرى من عميل آخر في المشروع نفسه، مثل تطبيق ويب.