عندما ينشئ المطوّرون برامج، يتم بشكل دوري تضمين وحدات يتم تشغيلها على خادم الويب، ووحدات أخرى يتم تشغيلها في المتصفّح، وغيرها من الوحدات التي يتم تشغيلها كتطبيقات أصلية للأجهزة الجوّالة. وعادةً ما ينظر كل من المطوّرين ومستخدمي البرامج إلى جميع هذه الوحدات على أنّها جزء من تطبيق واحد.
يتوافق تطبيق Google لبروتوكول OAuth 2.0 مع هذه النظرة إلى العالم. لاستخدام أي من خدمات 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، لن يُطلب ذلك مرة أخرى من عميل آخر في المشروع نفسه، مثل تطبيق الويب.