بروتوكول OAuth 2.0 للتطبيقات المتوافقة مع أجهزة iOS والكمبيوتر

<0x0 تقدّم النظرة العامة ملخّصًا لعمليات OAuth 2.0 التي تتيحها Google، ما يساعدك في التأكّد من اختيار العملية المناسبة لتطبيقك.

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

يتيح بروتوكول OAuth 2.0 للمستخدمين مشاركة بيانات محدَّدة مع أحد التطبيقات والحفاظ على خصوصية أسماء المستخدمين وكلمات المرور والمعلومات الأخرى. على سبيل المثال، يمكن لأحد التطبيقات استخدام OAuth 2.0 للحصول على إذن من المستخدمين لتخزين الملفات في حساباتهم على Google Drive.

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

يشبه مسار التفويض هذا المسار المستخدَم في تطبيقات خادم الويب. ويكمن الاختلاف الرئيسي في أنّ التطبيقات المثبَّتة يجب أن تفتح متصفّح النظام وتوفّر معرّف موارد منتظمًا محليًا لإعادة التوجيه من أجل التعامل مع الردود الواردة من خادم التفويض التابع لـ Google.

المكتبات والعينات

بالنسبة إلى تطبيقات iOS، ننصحك باستخدام أحدث إصدار من حزمة تطوير البرامج (SDK) لخدمة &quot;تسجيل الدخول باستخدام Google&quot; المتوافقة مع iOS. تتولّى حزمة تطوير البرامج (SDK) عملية تفويض المستخدم، وهي أسهل في التنفيذ من البروتوكول ذي المستوى الأدنى الموضّح في هذا الدليل.

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

المتطلبات الأساسية

تفعيل واجهات برمجة التطبيقات لمشروعك

يجب تفعيل واجهات Google APIs في API Consoleلأي تطبيق يستدعي هذه الواجهات.

لتفعيل واجهة برمجة تطبيقات لمشروعك، اتّبِع الخطوات التالية:

1. Open the API Library في Google API Console
2. If prompted, select a project, or create a new one.
3. تعرض API Library جميع واجهات برمجة التطبيقات المتاحة، ويتم تجميعها حسب فئة المنتج ومدى رواجها. إذا لم يكن واجهة برمجة التطبيقات التي تريد تفعيلها ظاهرة في القائمة، استخدِم البحث للعثور عليها، أو انقر على عرض الكل في مجموعة المنتجات التي تنتمي إليها.
4. اختَر واجهة برمجة التطبيقات التي تريد تفعيلها، ثم انقر على الزر تفعيل.
5. If prompted, enable billing.
6. If prompted, read and accept the API's Terms of Service.

إنشاء بيانات اعتماد التفويض

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

1. Go to the Clients page.
2. انقر على إنشاء عميل.
3. توضّح الأقسام التالية أنواع العملاء التي يتيحها خادم التفويض من Google. اختَر نوع العميل الذي يُنصح به لتطبيقك، وأدخِل اسمًا لعميل OAuth، واضبط الحقول الأخرى في النموذج على النحو المناسب.

iOS

1. اختَر نوع تطبيق iOS.
2. أدخِل اسمًا لعميل OAuth. يتم عرض هذا الاسم في مشروعك Clients page لتحديد العميل.
3. أدخِل معرّف الحزمة لتطبيقك. معرّف الحزمة هو قيمة المفتاح CFBundleIdentifier في ملف الموارد الخاص بقائمة خصائص معلومات تطبيقك (info.plist). يتم عرض القيمة بشكل شائع في اللوحة General أو اللوحة Signing & Capabilities في أداة تعديل مشاريع Xcode. يظهر معرّف الحزمة أيضًا في قسم "المعلومات العامة" ضمن صفحة "معلومات التطبيق" الخاصة بالتطبيق على موقع App Store Connect الإلكتروني من Apple.

   تأكَّد من استخدام رقم تعريف الحزمة الصحيح لتطبيقك، لأنّه لن يكون بإمكانك تغييره إذا كنت تستخدم ميزة App Check.

4. (اختياري)

   أدخِل رقم تعريف تطبيقك في App Store إذا كان التطبيق منشورًا في متجر Apple App Store. معرّف المتجر هو سلسلة رقمية مضمّنة في كل عنوان URL في Apple App Store.

   1. افتح تطبيق Apple App Store على جهاز iOS أو iPadOS.
   2. ابحث عن تطبيقك.
   3. انقر على زر المشاركة (مربع وسهم للأعلى).
   4. انقر على نسخ الرابط.
   5. الصِق الرابط في محرِّر نصوص. معرّف App Store هو الجزء الأخير من عنوان URL.

      مثلاً: https://apps.apple.com/app/google/id284815942

5. (اختياري)

   أدخِل معرّف الفريق. يمكنك الاطّلاع على مقالة تحديد موقع معرّف الفريق في مستندات حساب المطوّر على Apple للحصول على مزيد من المعلومات.

   ملاحظة: يجب ملء حقل "رقم تعريف الفريق" إذا كنت تريد تفعيل App Check للعميل.
6. (اختياري)

   فعِّل خدمة App Check لتطبيق iOS. عند تفعيل خدمة App Check، يتم استخدام خدمة App Attest من Apple للتحقّق من أنّ طلبات OAuth 2.0 الواردة من عميل OAuth حقيقية ومن تطبيقك، ما يساعد في تقليل خطر انتحال هوية التطبيق. مزيد من المعلومات عن تفعيل خدمة App Check لتطبيق iOS

7. انقر على إنشاء.

UWP

1. اختَر نوع التطبيق النظام الأساسي العام لـ Windows.
2. أدخِل اسمًا لعميل OAuth. يتم عرض هذا الاسم في مشروعك Clients page لتحديد العميل.
3. أدخِل معرّف Microsoft Store الخاص بتطبيقك والمؤلّف من 12 حرفًا. يمكنك العثور على هذه القيمة في Microsoft Partner Center في صفحة هوية التطبيق ضمن قسم &quot;إدارة التطبيقات&quot;.
4. انقر على إنشاء.

بالنسبة إلى تطبيقات UWP، يتم إنشاء معرّف الموارد المنتظم لإعادة التوجيه باستخدام معرّف أمان الحزمة الفريد لتطبيقك (SID). يمكنك العثور على Package SID لتطبيقك في ملف Package.appxmanifest ضمن مشروع Visual Studio.

عند إنشاء معرّف العميل في وحدة تحكّم Google Cloud، يجب تحديد معرّف الموارد المنتظم (URI) لإعادة التوجيه بالتنسيق التالي، باستخدام قيمة معرّف الأمان (SID) لحزمة التطبيق بالأحرف الصغيرة:

ms-app://YOUR_APP_PACKAGE_SID

ملاحظة: يجب استخدام المخطط ms-app:// لكي تعمل عملية إعادة التوجيه إلى OAuth 2.0 بشكلٍ سليم. يتم استخدام هذا المخطط لتفعيل البروتوكول، ما يسمح لنظام التشغيل بتشغيل تطبيقك وتقديم ردّ التفويض من Google بعد أن يصادق المستخدم على هويته في المتصفّح.

بالنسبة إلى تطبيقات UWP، لا يمكن أن يزيد طول مخطط URI المخصّص عن 39 حرفًا، كما هو موضّح في مستندات Microsoft.

تحديد نطاقات الوصول

تتيح النطاقات لتطبيقك طلب الوصول إلى الموارد التي يحتاجها فقط، كما تتيح للمستخدمين التحكّم في مقدار الوصول الذي يمنحونه لتطبيقك. وبالتالي، قد تكون هناك علاقة عكسية بين عدد النطاقات المطلوبة واحتمالية الحصول على موافقة المستخدم.

قبل البدء في تنفيذ تفويض OAuth 2.0، ننصحك بتحديد النطاقات التي سيحتاج تطبيقك إلى إذن للوصول إليها.

ملاحظة: لا تتوفّر ميزة "تفويض الوصول بشكل تدريجي" للتطبيقات المثبَّتة أو الأجهزة.

يحتوي مستند نطاقات واجهة برمجة التطبيقات OAuth 2.0 على قائمة كاملة بالنطاقات التي يمكنك استخدامها للوصول إلى Google APIs.

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

الحصول على رموز الدخول عبر OAuth 2.0

توضّح الخطوات التالية كيفية تفاعل تطبيقك مع خادم OAuth 2.0 من Google للحصول على موافقة المستخدم على تنفيذ طلب API بالنيابة عنه. يجب أن يحصل تطبيقك على هذه الموافقة قبل أن يتمكّن من تنفيذ طلب Google API يتطلّب إذن المستخدم.

الخطوة 1: إنشاء أداة التحقّق من الرمز والتحدّي

تتيح Google بروتوكول مفتاح الحماية لتبادل الرموز (PKCE) لجعل عملية تثبيت التطبيق أكثر أمانًا. يتم إنشاء أداة التحقّق من الرمز الفريد لكل طلب ترخيص، ويتم إرسال قيمتها المحوّلة، والتي تُسمّى "code_challenge"، إلى خادم الترخيص للحصول على رمز الترخيص.

إنشاء أداة التحقّق من الرمز

code_verifier هي سلسلة عشوائية مشفّرة ذات إنتروبيا عالية تستخدم الأحرف غير المحجوزة [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"، ويبلغ الحد الأدنى لطولها 43 حرفًا والحد الأقصى 128 حرفًا.

يجب أن يحتوي رمز التحقّق على إنتروبيا كافية تجعل من غير العملي تخمين القيمة.

إنشاء تحدّي الرمز

تتوفّر طريقتان لإنشاء تحدّي الرمز.

طُرق إنشاء تحدّي الرمز
S256 (يُنصح به)	تمثّل تحدّي الرمز تجزئة SHA256 للرمز التحقّق من الصحة، ويتم ترميزها باستخدام Base64URL (بدون إضافة أي مساحة). code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
plain	تمثّل قيمة تحدّي الرمز القيمة نفسها التي تم إنشاؤها أعلاه لرمز التحقّق. code_challenge = code_verifier

الخطوة 2: إرسال طلب إلى خادم OAuth 2.0 من Google

للحصول على تفويض المستخدم، أرسِل طلبًا إلى خادم التفويض التابع لـ Google على https://accounts.google.com/o/oauth2/v2/auth. تعالج نقطة النهاية هذه عملية البحث عن الجلسة النشطة، وتصادق على المستخدم، وتحصل على موافقته. لا يمكن الوصول إلى نقطة النهاية إلا عبر SSL، وهي ترفض اتصالات HTTP (غير SSL).

يتيح خادم التفويض مَعلمات سلسلة طلب البحث التالية للتطبيقات المثبَّتة:

المعلمات
client_id	مطلوب معرّف العميل لتطبيقك يمكنك العثور على هذه القيمة في Cloud Console Clients page.
redirect_uri	مطلوب تحدّد هذه السمة الطريقة التي يرسل بها خادم التفويض من Google ردًا إلى تطبيقك. تتوفّر عدة خيارات لإعادة التوجيه للتطبيقات المثبَّتة، وعليك إعداد بيانات اعتماد التفويض مع الأخذ في الاعتبار طريقة معيّنة لإعادة التوجيه. يجب أن تتطابق القيمة تمامًا مع أحد معرّفات الموارد المنتظمة (URI) المسموح بها لإعادة التوجيه الخاصة بعميل OAuth 2.0 الذي أعددته في Cloud Console Clients pageالخاص بالعميل. إذا لم تتطابق هذه القيمة مع معرّف URI معتمَد، سيظهر لك الخطأ redirect_uri_mismatch. يعرض الجدول قيمة المَعلمة redirect_uri المناسبة لكل طريقة: قيم redirect_uri مخطّط معرّف الموارد المنتظم (URI) المخصّص com.example.app:redirect_uri_path أو com.googleusercontent.apps.123:redirect_uri_path ‫com.example.app هي صيغة نظام أسماء النطاقات العكسي لنطاق يخضع لتحكّمك. يجب أن يحتوي المخطط المخصّص على نقطة ليكون صالحًا. ‫com.googleusercontent.apps.123 هو تدوين نظام أسماء النطاقات العكسي لمعرّف العميل. ‫redirect_uri_path هو مكوّن مسار اختياري، مثل /oauth2redirect. يُرجى العِلم أنّ المسار يجب أن يبدأ بشرطة مائلة واحدة، وهو ما يختلف عن عناوين URL العادية التي تستخدم HTTP. ملاحظة : لم يعُد يتم توفير المخططات المخصَّصة لمعرّفات الموارد المنتظمة (URI) على تطبيقات Android وChrome. مزيد من المعلومات عن بدائل المخطّطات المخصَّصة عنوان IP للاسترجاع http://127.0.0.1:port أو http://[::1]:port اطلب من منصتك الحصول على عنوان IP المناسب الخاص بالشبكة المحلية، وابدأ برنامج استماع HTTP على منفذ عشوائي متاح. استبدِل port برقم المنفذ الفعلي الذي يستمع إليه تطبيقك. يُرجى العِلم أنّ خيار إعادة التوجيه إلى عنوان IP الخاص بالشبكة المحلية في التطبيقات �
response_type	مطلوب تحدِّد هذه السمة ما إذا كانت نقطة نهاية Google OAuth 2.0 تعرض رمز تفويض. اضبط قيمة المَعلمة على code للتطبيقات المثبَّتة.
scope	مطلوب قائمة مفصولة بمسافات تتضمّن النطاقات التي تحدّد الموارد التي يمكن لتطبيقك الوصول إليها نيابةً عن المستخدم. تُعلم هذه القيم شاشة الموافقة التي تعرضها Google للمستخدم. تتيح النطاقات لتطبيقك طلب الوصول إلى الموارد التي يحتاج إليها فقط، كما تتيح للمستخدمين التحكّم في مقدار الوصول الذي يمنحونه لتطبيقك. وبالتالي، هناك علاقة عكسية بين عدد النطاقات المطلوبة واحتمالية الحصول على موافقة المستخدم.
code_challenge	مقترَح تحدّد هذه السمة code_verifier مشفَّرًا سيتم استخدامه كتحدٍّ من جهة الخادم أثناء تبادل رمز التفويض. اطّلِع على مقالة إنشاء تحدّي باستخدام الرمز لمزيد من المعلومات.
code_challenge_method	مقترَح تحدّد هذه السمة الطريقة المستخدَمة لترميز code_verifier التي سيتم استخدامها أثناء تبادل رمز التفويض. يجب استخدام هذه المَعلمة مع المَعلمة code_challenge. إذا لم تكن السمة code_challenge_method متوفّرة في الطلب الذي يتضمّن code_challenge، تكون القيمة التلقائية للسمة code_challenge_method هي plain. القيمتان المسموح بإدراجهما لهذه المَعلمة هما S256 أو plain.
state	مقترَح تحدّد هذه السمة أي قيمة سلسلة يستخدمها تطبيقك للحفاظ على الحالة بين طلب التفويض والاستجابة من خادم التفويض. يعرض الخادم القيمة نفسها التي ترسلها كزوج name=value في معرّف جزء عنوان URL (#) لـ redirect_uri بعد أن يوافق المستخدم على طلب الوصول الذي يقدّمه تطبيقك أو يرفضه. يمكنك استخدام هذه المَعلمة لعدّة أغراض، مثل توجيه المستخدم إلى المرجع الصحيح في تطبيقك، وإرسال أرقام عشوائية، والحدّ من عمليات تزوير الطلبات على مستوى المواقع الإلكترونية. بما أنّه يمكن تخمين redirect_uri، فإنّ استخدام قيمة state يمكن أن يزيد من ضمانك بأنّ الاتصال الوارد هو نتيجة لطلب مصادقة. إذا أنشأت سلسلة عشوائية أو ترميزًا لتجزئة ملف تعريف ارتباط أو قيمة أخرى تسجّل حالة العميل، يمكنك التحقّق من صحة الردّ لضمان أنّ الطلب والردّ نشآ في المتصفّح نفسه، ما يوفّر الحماية من هجمات مثل تزوير الطلبات على مستوى المواقع الإلكترونية. راجِع مستندات OpenID Connect للاطّلاع على مثال حول كيفية إنشاء رمز مميّز state وتأكيده. ملاحظة مهمة: يجب أن يمنع عميل OAuth هجمات تزوير الطلبات عبر المواقع (CSRF) كما هو موضّح في مواصفات OAuth2 . يمكن تحقيق ذلك باستخدام المَعلمة state للحفاظ على الحالة بين طلب التفويض واستجابة خادم التفويض.
login_hint	اختياريّ إذا كان تطبيقك يعرف المستخدم الذي يحاول إثبات هويته، يمكنه استخدام هذه المَعلمة لتقديم تلميح إلى خادم مصادقة Google. يستخدم الخادم التلميح لتبسيط عملية تسجيل الدخول، إما عن طريق ملء حقل البريد الإلكتروني مسبقًا في نموذج تسجيل الدخول أو عن طريق اختيار جلسة تسجيل الدخول المتعدد المناسبة. اضبط قيمة المَعلمة على عنوان بريد إلكتروني أو معرّف sub، وهو يساوي معرّف المستخدم على Google.

ملاحظة: لا تتوفّر ميزة التفويض التدريجي مع التطبيقات المثبَّتة، وذلك لأنّ العميل لا يمكنه الحفاظ على سرية client_secret.

أمثلة على عناوين URL للتفويض

تعرض علامات التبويب أدناه نماذج لعناوين URL الخاصة بالتفويض لخيارات عناوين URI المختلفة لإعادة التوجيه.

تتطابق عناوين URL باستثناء قيمة المَعلمة redirect_uri. تحتوي عناوين URL أيضًا على المَعلمتَين المطلوبتَين response_type وclient_id، بالإضافة إلى المَعلمة الاختيارية state. يحتوي كل عنوان URL على فواصل أسطر ومسافات لتسهيل قراءته.

مخطط معرّف الموارد المنتظم (URI) المخصّص

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

عنوان IP للاسترجاع

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

الخطوة 3: تطلب Google من المستخدم الموافقة

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

لا يحتاج تطبيقك إلى اتّخاذ أي إجراء في هذه المرحلة، إذ ينتظر الردّ من خادم OAuth 2.0 التابع لـ Google الذي يوضّح ما إذا تم منح أي إذن بالوصول. يتم توضيح هذا الرد في الخطوة التالية.

الأخطاء

قد تعرض الطلبات المُرسَلة إلى نقطة نهاية تفويض OAuth 2.0 من Google رسائل خطأ موجّهة إلى المستخدمين بدلاً من عمليات المصادقة والتفويض المتوقّعة. في ما يلي رموز الخطأ الشائعة والحلول المقترَحة:

admin_policy_enforced

لا يمكن لحساب Google منح الإذن باستخدام نطاق واحد أو أكثر من النطاقات المطلوبة بسبب سياسات مشرف Google Workspace. راجِع مقالة المساعدة في &quot;مشرف Google Workspace&quot; بعنوان التحكّم في اختيار التطبيقات الداخلية والخارجية التي يمكنها الوصول إلى بيانات Google Workspace لمزيد من المعلومات حول كيفية حظر المشرف للوصول إلى جميع النطاقات أو النطاقات الحسّاسة والمقيّدة إلى أن يتم منح إذن الوصول بشكل صريح إلى معرّف عميل OAuth.

disallowed_useragent

يتم عرض نقطة نهاية التفويض داخل وكيل مستخدم مضمّن غير مسموح به بموجب سياسات OAuth 2.0 من Google.

قد يواجه مطوّرو تطبيقات iOS وmacOS هذا الخطأ عند فتح طلبات الحصول على إذن في WKWebView. على المطوّرين بدلاً من ذلك استخدام مكتبات iOS، مثل Google Sign-In for iOS أو AppAuth for iOS من OpenID Foundation.

قد يواجه مطوّرو الويب هذا الخطأ عندما يفتح تطبيق iOS أو macOS رابط ويب عامًا في وكيل مستخدم مضمّن، وينتقِل المستخدم إلى نقطة نهاية تفويض OAuth 2.0 من Google من موقعك الإلكتروني. على المطوّرين السماح بفتح الروابط العامة في معالج الروابط التلقائي لنظام التشغيل، والذي يتضمّن معالجات الروابط العامة أو تطبيق المتصفّح التلقائي. وتُعد مكتبة SFSafariViewController أيضًا خيارًا متاحًا.

org_internal

إنّ رقم تعريف عميل OAuth في الطلب هو جزء من مشروع يحدّ من الوصول إلى حسابات Google في مؤسسة Google Cloud محدّدة. لمزيد من المعلومات حول خيار الإعداد هذا، راجِع قسم نوع المستخدم في مقالة المساعدة بعنوان "إعداد شاشة موافقة OAuth".

deleted_client

تم حذف عميل OAuth المستخدَم لتقديم الطلب. يمكن أن تتم عملية الحذف يدويًا أو تلقائيًا في حال العملاء غير النشطين . يمكن استعادة العملاء المحذوفين في غضون 30 يومًا من الحذف. مزيد من المعلومات

invalid_grant

إذا كنت تستخدم رمز التحقّق من الصحة والتحدّي، تكون المَعلمة code_callenge غير صالحة أو غير متوفّرة. تأكَّد من ضبط المَعلمة code_challenge بشكلٍ صحيح.

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

redirect_uri_mismatch

لا يتطابق redirect_uri الذي تم تمريره في طلب التفويض مع معرّف الموارد المنتظم (URI) لإعادة التوجيه المصرّح به لمعرّف عميل OAuth. راجِع معرّفات الموارد المنتظمة (URI) المعتمَدة لإعادة التوجيه في Google Cloud Console Clients page.

قد يكون redirect_uri الذي تم تمريره غير صالح لنوع العميل.

قد تشير المَعلمة redirect_uri إلى مسار OAuth خارج النطاق (OOB) الذي تم إيقافه نهائيًا ولم يعُد متاحًا. راجِع دليل نقل البيانات لتعديل عملية الدمج.

invalid_request

حدث خطأ في الطلب الذي قدّمته. قد يرجع ذلك إلى عدة أسباب:

• لم يتم تنسيق الطلب بشكلٍ صحيح
• لم يتضمّن الطلب المَعلمات المطلوبة
• يستخدم الطلب طريقة لا تسمح بها Google لمنح إذن الوصول. التأكّد من أنّ عملية دمج OAuth تستخدم طريقة دمج مقترَحة
• تم استخدام نظام مخصّص غير متوافق لمعرّف الموارد المنتظم لإعادة التوجيه. إذا ظهرت لك رسالة الخطأ مخطط معرّف الموارد المنتظم (URI) المخصّص غير متاح على تطبيقات Android أو Chrome، يمكنك الاطّلاع على مزيد من المعلومات حول بدائل مخطط معرّف الموارد المنتظم (URI) المخصّص.

الخطوة 4: التعامل مع استجابة خادم OAuth 2.0

تعتمد الطريقة التي يتلقّى بها تطبيقك ردّ التفويض على مخطط معرّف الموارد المنتظم (URI) لإعادة التوجيه الذي يستخدمه. وبغض النظر عن المخطط، سيتضمّن الردّ إما رمز تخويل (code) أو خطأ (error). على سبيل المثال، يشير error=access_denied إلى أنّ المستخدم رفض الطلب.

إذا منح المستخدِم الإذن لتطبيقك، يمكنك استبدال رمز التفويض برمز دخول ورمز مميّز لإعادة التحميل كما هو موضّح في الخطوة التالية.

الخطوة 5: تبديل رمز التفويض برموز مميّزة لإعادة التحميل والدخول

لتبديل رمز تفويض برمز دخول، اتّصِل بنقطة النهاية https://oauth2.googleapis.com/token واضبط المَعلمات التالية:

الحقول
client_id	معرّف العميل الذي تم الحصول عليه من Cloud Console Clients page
client_secret	سر العميل الذي تم الحصول عليه من Cloud Console Clients page
code	رمز التفويض الذي تم عرضه من الطلب الأوّلي.
code_verifier	رمز التحقّق الذي أنشأته في الخطوة 1
grant_type	وفقًا لما هو محدّد في مواصفات OAuth 2.0، يجب ضبط قيمة هذا الحقل على authorization_code.
redirect_uri	أحد معرّفات الموارد المنتظمة (URI) لإعادة التوجيه المُدرَجة لمشروعك في Cloud Console Clients page لـ client_id.

يعرض المقتطف التالي نموذجًا لطلب:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

تستجيب Google لهذا الطلب من خلال عرض عنصر JSON يحتوي على رمز مميز قصير الأمد للوصول ورمز مميز لإعادة التحميل.

يتضمّن الردّ الحقول التالية:

الحقول
access_token	الرمز المميز الذي يرسله تطبيقك للموافقة على طلب Google API
expires_in	تمثّل هذه السمة مدة صلاحية رمز الدخول المتبقية بالثواني.
id_token	ملاحظة: لا يتم عرض هذه السمة إلا إذا تضمّن طلبك نطاق معرّف، مثل openid أو profile أو email. القيمة هي رمز JSON المميّز للويب (JWT) يحتوي على معلومات هوية موقَّعة رقميًا حول المستخدم.
refresh_token	رمز مميّز يمكنك استخدامه للحصول على رمز مميّز جديد للوصول تكون رموز إعادة التحميل صالحة إلى أن يبطل المستخدم إذن الوصول أو تنتهي صلاحية رمز إعادة التحميل. يُرجى العِلم أنّه يتم دائمًا عرض الرموز المميزة لإعادة التحميل للتطبيقات المثبَّتة.
refresh_token_expires_in	تمثّل هذه السمة مدة صلاحية الرمز المميز لإعادة التحميل المتبقية بالثواني. لا يتم ضبط هذه القيمة إلا عندما يمنح المستخدم إذن الوصول المستند إلى الوقت.
scope	نطاقات الوصول التي يمنحها access_token معبَّر عنها كقائمة من السلاسل الحساسة لحالة الأحرف والمفصولة بمسافات.
token_type	تمثّل هذه السمة نوع الرمز المميّز الذي يتم عرضه. في الوقت الحالي، يتم دائمًا ضبط قيمة هذا الحقل على Bearer.

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

يعرض المقتطف التالي نموذجًا لردّ:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

ملاحظة: يجب أن يتجاهل تطبيقك أي حقول غير معروفة مضمّنة في الرد.

الخطوة 6: التحقّق من النطاقات التي منحها المستخدمون

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

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

لمزيد من المعلومات التفصيلية، يُرجى الاطّلاع على كيفية التعامل مع الأذونات الدقيقة.

للتحقّق مما إذا كان المستخدم قد منح تطبيقك إذن الوصول إلى نطاق معيّن، افحص الحقل scope في ردّ رمز الدخول. نطاقات الوصول التي يمنحها الرمز access_token، ويتم التعبير عنها كقائمة من السلاسل الحساسة لحالة الأحرف والمفصولة بمسافات

على سبيل المثال، يشير نموذج استجابة رمز الدخول التالي إلى أنّ المستخدم قد منح تطبيقك إذن الوصول إلى نشاط Drive وأحداث التقويم للقراءة فقط:

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

طلب بيانات من Google APIs

بعد أن يحصل تطبيقك على رمز مميز للوصول، يمكنك استخدام الرمز المميز لإجراء طلبات إلى إحدى واجهات برمجة التطبيقات من Google نيابةً عن حساب مستخدم معيّن، وذلك إذا تم منح نطاقات الوصول التي تتطلّبها واجهة برمجة التطبيقات. لإجراء ذلك، يجب تضمين رمز الدخول في طلب إلى واجهة برمجة التطبيقات من خلال تضمين مَعلمة طلب بحث access_token أو قيمة Bearer لعنوان HTTP Authorization. عند الإمكان، من الأفضل استخدام عنوان HTTP، لأنّ سلاسل طلب البحث تكون عادةً مرئية في سجلات الخادم. في معظم الحالات، يمكنك استخدام مكتبة برامج العميل لإعداد طلباتك إلى واجهات Google API (على سبيل المثال، عند استدعاء Drive Files API).

يمكنك تجربة جميع واجهات Google APIs والاطّلاع على نطاقاتها في مساحة بروتوكول OAuth 2.0.

أمثلة على طلبات HTTP GET

قد يبدو طلب إلى نقطة النهاية drive.files (Drive Files API) باستخدام عنوان HTTP Authorization: Bearer على النحو التالي. يُرجى العِلم أنّه عليك تحديد رمز الدخول الخاص بك:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

في ما يلي طلب موجّه إلى واجهة برمجة التطبيقات نفسها للمستخدم الذي تمّت المصادقة عليه باستخدام مَعلمة سلسلة طلب البحث access_token:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

أمثلة على curl

يمكنك اختبار هذه الأوامر باستخدام تطبيق سطر الأوامر curl. في ما يلي مثال يستخدم خيار عنوان HTTP (الخيار المفضّل):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

أو يمكنك استخدام خيار مَعلمة سلسلة طلب البحث:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

إعادة تحميل رمز دخول

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

لتجديد رمز الدخول، يرسل تطبيقك طلب HTTPS POST إلى خادم التفويض في Google (https://oauth2.googleapis.com/token) يتضمّن المَعلمات التالية:

الحقول
client_id	معرّف العميل الذي تم الحصول عليه من API Console
client_secret	سر العميل الذي تم الحصول عليه من API Console (لا ينطبق client_secret على الطلبات الواردة من العملاء المسجّلين كتطبيقات Android أو iOS أو Chrome).
grant_type	كما هو محدّد في مواصفات OAuth 2.0، يجب ضبط قيمة هذا الحقل على refresh_token.
refresh_token	الرمز المميز لإعادة التحميل الذي تم إرجاعه من عملية تبديل رمز التفويض

يعرض المقتطف التالي نموذجًا لطلب:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

ما دام المستخدم لم يبطل إذن الوصول الممنوح للتطبيق، سيعرض خادم الرموز المميزة عنصر JSON يتضمّن رمزًا مميزًا جديدًا للوصول. يعرض المقتطف التالي نموذجًا للاستجابة:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "token_type": "Bearer"
}

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

إبطال الرمز المميز

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

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

لإبطال رمز مميّز آليًا، يرسل تطبيقك طلبًا إلى https://oauth2.googleapis.com/revoke ويتضمّن الرمز المميّز كمعلَمة:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

يمكن أن يكون الرمز المميز رمز دخول أو رمزًا مميزًا لإعادة التحميل. إذا كان الرمز المميز هو رمز دخول وكان يتضمّن رمزًا مميزًا لإعادة التحميل، سيتم أيضًا إبطال رمز إعادة التحميل.

إذا تمت معالجة الإلغاء بنجاح، سيكون رمز حالة HTTP للاستجابة هو 200. في حال حدوث خطأ، يتم عرض رمز حالة HTTP 400 مع رمز خطأ.

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

طُرق إعادة توجيه التطبيقات

مخطط معرّف الموارد المنتظم (URI) المخصّص

المخططات المخصّصة لمعرّفات الموارد المنتظمة (URI) هي شكل من أشكال الربط بصفحات في التطبيق تستخدم مخططًا محدّدًا مخصّصًا لفتح تطبيقك.

ملاحظة مهمة: لم يعُد مسموحًا باستخدام المخططات المخصّصة لمعرّفات الموارد المنتظمة (URI) بسبب خطر انتحال هوية التطبيقات.

بديل لاستخدام مخططات URI المخصّصة في تطبيقات Chrome

استخدِم Chrome Identity API التي تقدّم استجابة OAuth 2.0 مباشرةً إلى تطبيقك، ما يلغي الحاجة إلى معرّف موارد منتظم لإعادة التوجيه.

عنوان IP للاسترجاع (أجهزة macOS وLinux وWindows)

ملاحظة مهمة: تم إيقاف خيار إعادة التوجيه إلى عنوان IP الاستماع إلى صوتك لأنواع العملاء الذين يستخدمون بروتوكول OAuth على Android وتطبيق Chrome وiOS. راجِع دليل نقل البيانات إلى عنوان IP للاستماع إلى صوتك للحصول على تعليمات حول كيفية نقل البيانات إلى طريقة بديلة متوافقة.

لتلقّي رمز التفويض باستخدام عنوان URL هذا، يجب أن يكون تطبيقك يستمع إلى خادم الويب المحلي. يمكن إجراء ذلك على العديد من المنصات، ولكن ليس كلها. ومع ذلك، إذا كانت المنصة تتيح ذلك، ننصحك باستخدام هذه الآلية للحصول على رمز التفويض.

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

الاستخدام المقترَح	تطبيقات macOS وLinux وWindows على أجهزة الكمبيوتر (وليس النظام الأساسي العام لـ Windows)
قيم النموذج	اضبط نوع التطبيق على تطبيق متوافق مع الكمبيوتر المكتبي.

ملاحظة: راجِع تعريف المَعلمة redirect_uri للحصول على مزيد من المعلومات حول عنوان IP الخاص بالشبكة المحلية. يمكن أيضًا استخدام localhost بدلاً من عنوان IP الخاص بالشبكة المحلية، ولكن قد يتسبّب هذا الإعداد في حدوث مشاكل في جدران الحماية الخاصة بالعملاء. تسمح معظم جدران الحماية، وليس كلها، بالتواصل عبر التكرار الحلقي.

النسخ واللصق يدويًا (متوقّف نهائيًا)

ملاحظة مهمة: لم يعُد خيار النسخ واللصق اليدوي، المعروف أيضًا باسم طريقة إعادة التوجيه خارج النطاق (OOB)، متاحًا. راجِع دليل نقل البيانات إلى المصادقة خارج النطاق للحصول على تعليمات حول كيفية نقل البيانات إلى بديل آمن.

حماية تطبيقاتك

إثبات ملكية التطبيق على Chrome

يمكنك إثبات ملكية تطبيقك للحدّ من خطر انتحال هوية التطبيق.

لإكمال عملية إثبات الملكية، عليك استخدام حساب المطوّر في "سوق Chrome الإلكتروني". يجب استيفاء المتطلبات التالية لإكمال عملية التحقّق بنجاح:

• يجب أن يكون لديك عنصر مسجّل في لوحة بيانات المطوّر في &quot;سوق Chrome الإلكتروني&quot; يحمل رقم تعريف العنصر نفسه الذي يحمله عميل OAuth لإضافة Chrome الذي تريد إكمال عملية إثبات الهوية له.
• يجب أن تكون ناشرًا للعنصر في "سوق Chrome الإلكتروني". مزيد من المعلومات عن إدارة إذن الوصول في "لوحة بيانات المطوّر في سوق Chrome الإلكتروني"

في قسم إثبات ملكية التطبيق في عميل "إضافة Chrome"، انقر على الزر إثبات الملكية لإكمال عملية إثبات الملكية.

ملاحظة: انتظِر بضع دقائق قبل إكمال عملية إثبات الملكية بعد منح إذن الوصول إلى حسابك.

في حال نجاح عملية التحقّق، سيظهر إشعار يؤكّد نجاحها. وإلا، ستظهر رسالة خطأ.

لإصلاح عملية إثبات هوية تعذّر إتمامها، جرِّب ما يلي:

• تأكَّد من توفّر عنصر مسجَّل في لوحة بيانات المطوّر في "سوق Chrome الإلكتروني" يحمل رقم تعريف العنصر نفسه الذي يحمله عميل OAuth لإضافة Chrome الذي تريد إكمال عملية إثبات ملكيته.
• تأكَّد من أنّك ناشر التطبيق، أي يجب أن تكون الناشر الفردي للتطبيق أو أحد أعضاء مجموعة ناشري التطبيق. مزيد من المعلومات حول إدارة إذن الوصول في "لوحة بيانات المطوّر" في "سوق Chrome الإلكتروني"
• إذا كنت قد عدّلت قائمة الناشرين في المجموعة مؤخرًا، تأكَّد من مزامنة قائمة العضوية في المجموعة في &quot;لوحة بيانات المطوّر&quot; في &quot;سوق Chrome الإلكتروني&quot;. مزيد من المعلومات حول مزامنة قائمة المشتركين في الناشر.

App Check (على أجهزة iOS فقط)

تساعد ميزة App Check في حماية تطبيقات iOS من الاستخدام غير المصرَّح به من خلال استخدام خدمة App Attest من Apple للتحقّق من أنّ الطلبات المُرسَلة إلى نقاط نهاية OAuth 2.0 من Google مصدرها تطبيقاتك الأصلية. يساعد ذلك في تقليل مخاطر انتحال هوية التطبيق.

تفعيل App Check لعميل iOS

يجب استيفاء المتطلبات التالية لتفعيل App Check بنجاح على عميل iOS:

• يجب تحديد معرّف فريق لعميل iOS.
• يجب عدم استخدام حرف بدل في معرّف الحزمة لأنّه يمكن أن يؤدي إلى أكثر من تطبيق واحد. وهذا يعني أنّه يجب ألا يتضمّن معرّف الحزمة رمز النجمة (*).

تحذير: عند تفعيل App Check، لن تتمكّن من تعديل معرّف حزمة عميل OAuth بدون إنشاء عميل جديد. قبل إنشاء عميل iOS أو تفعيل App Check، تأكَّد من استخدام معرّف الحزمة الصحيح. قد يؤدي تعديل معرّف الحزمة لمشروع حالي إلى حدوث مشاكل في تجربة مستخدمي تطبيقاتك إذا كنت تستخدم معرّف الحزمة كعنوان URI لإعادة التوجيه.

لتفعيل ميزة &quot;فحص التطبيقات&quot;، فعِّل زر التبديل حماية عميل OAuth من إساءة الاستخدام باستخدام ميزة &quot;فحص التطبيقات من Firebase&quot; في عرض التعديل لعميل iOS.

بعد تفعيل App Check، ستبدأ في رؤية مقاييس متعلّقة بطلبات OAuth من عميلك في عرض التعديل الخاص بعميل OAuth. لن يتم حظر الطلبات الواردة من مصادر لم يتم التحقّق منها إلى أن تفرض استخدام App Check. يمكن أن تساعدك المعلومات الواردة في صفحة مراقبة المقاييس في تحديد الوقت المناسب لبدء تنفيذ السياسة.

قد تظهر لك أخطاء متعلّقة بميزة "فحص التطبيق" عند تفعيلها لتطبيق iOS. لحلّ هذه الأخطاء، جرِّب ما يلي:

• تأكَّد من أنّ معرّف الحزمة ومعرّف الفريق اللذين حدّدتهما صالحان.
• تأكَّد من عدم استخدام حرف بدل لمعرّف الحزمة.

فرض استخدام App Check على عميل iOS

لا يؤدي تفعيل App Check لتطبيقك إلى حظر الطلبات غير المعروفة تلقائيًا. لتفعيل هذه الحماية، انتقِل إلى عرض التعديل في تطبيق iOS. ستظهر مقاييس App Check على يسار الصفحة ضمن قسم Google Identity لنظام التشغيل iOS. تتضمّن المقاييس المعلومات التالية:

• عدد الطلبات التي تم التحقّق منها: الطلبات التي تتضمّن رمزًا مميّزًا صالحًا من App Check. بعد تفعيل فرض استخدام App Check، لن تنجح سوى الطلبات في هذه الفئة.
• عدد الطلبات التي لم يتم التحقّق منها: من المحتمل أن تكون طلبات قديمة من العملاء - طلبات لا تتضمّن رمزًا مميزًا من App Check، وقد تكون هذه الطلبات من إصدار قديم من تطبيقك لا يتضمّن عملية تنفيذ App Check.
• عدد الطلبات التي لم يتم التحقّق منها: الطلبات ذات المصدر غير المعروف - الطلبات التي لا تتضمّن رمزًا مميّزًا من App Check ولا يبدو أنّها واردة من تطبيقك.
• عدد الطلبات التي لم يتم التحقّق منها: الطلبات غير الصالحة - الطلبات التي تتضمّن رمزًا مميزًا غير صالح من App Check، وقد تكون واردة من عميل غير موثوق يحاول انتحال هوية تطبيقك، أو من بيئات محاكاة.

راجِع هذه المقاييس لمعرفة كيف سيؤثر فرض استخدام App Check في المستخدمين.

لفرض استخدام App Check، انقر على الزر ENFORCE وأكِّد اختيارك. بعد تفعيل عملية التنفيذ، سيتم رفض جميع الطلبات التي لم يتم التحقّق منها من عميلك.

ملاحظة: بعد تفعيل خيار فرض القيود، قد يستغرق تطبيق التغييرات ما يصل إلى 15 دقيقة.

إيقاف فرض استخدام App Check على عميل iOS

سيؤدي عدم فرض استخدام App Check في تطبيقك إلى إيقاف الفرض، وسيسمح بجميع الطلبات الواردة من عميلك إلى نقاط نهاية Google OAuth 2.0، بما في ذلك الطلبات غير المؤكَّدة.

لإيقاف فرض استخدام App Check على عميل iOS، انتقِل إلى عرض التعديل الخاص بعميل iOS وانقر على الزر إيقاف الفرض وأكِّد اختيارك.

ملاحظة: بعد إيقاف فرض استخدام App Check، قد يستغرق تطبيق التغييرات مدة تصل إلى 15 دقيقة.

إيقاف App Check لعميل iOS

سيؤدي إيقاف ميزة App Check لتطبيقك إلى إيقاف جميع عمليات المراقبة والتنفيذ التي تجريها هذه الميزة. ننصحك بعدم فرض استخدام App Check بدلاً من ذلك حتى تتمكّن من مواصلة تتبُّع المقاييس الخاصة بالعميل.

لإيقاف ميزة &quot;فحص التطبيقات&quot; لعميل iOS، انتقِل إلى عرض التعديل الخاص بعميل iOS وأوقِف زر التبديل حماية عميل OAuth من إساءة الاستخدام باستخدام ميزة &quot;فحص التطبيقات من Firebase&quot;.

ملاحظة: بعد إيقاف App Check، قد يستغرق تطبيق التغييرات مدة تصل إلى 15 دقيقة.

الوصول المستند إلى الوقت

يسمح الوصول المستند إلى الوقت للمستخدم بمنح تطبيقك الإذن بالوصول إلى بياناته لمدة محدودة لإكمال إجراء معيّن. تتوفّر إمكانية الوصول المستند إلى الوقت في منتجات محدّدة من Google أثناء مسار الموافقة، ما يمنح المستخدمين خيار منح إذن الوصول لفترة زمنية محدودة. ومن الأمثلة على ذلك Data Portability API التي تتيح نقل البيانات لمرة واحدة.

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

محتوى إضافي للقراءة

تحدّد أفضل الممارسات الحالية من IETF OAuth 2.0 للتطبيقات الأصلية العديد من أفضل الممارسات الموضّحة هنا.

تنفيذ ميزة "الحماية العابرة للحساب"

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

في ما يلي بعض الأمثلة على أنواع الأحداث التي ترسلها خدمة "الحماية على مستوى الحسابات" من Google إلى تطبيقك:

• https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
• https://schemas.openid.net/secevent/oauth/event-type/token-revoked
• https://schemas.openid.net/secevent/risc/event-type/account-disabled

يمكنك الاطّلاع على صفحة حماية حسابات المستخدمين باستخدام ميزة "الحماية العابرة للحساب" للحصول على مزيد من المعلومات حول كيفية تنفيذ ميزة "الحماية العابرة للحساب" والقائمة الكاملة بالأحداث المتاحة.