يوضح هذا المستند كيفية تنفيذ تفويض OAuth 2.0 للدخول إلى Google APIs من خلال التطبيقات التي تعمل على أجهزة مثل أجهزة التلفزيون ووحدات تحكم الألعاب والطابعات. وبشكل أكثر تحديدًا، تم تصميم هذه العملية للأجهزة التي لا يمكنها الوصول إلى متصفّح أو التي تتضمّن إمكانيات إدخال محدودة.
يسمح بروتوكول OAuth 2.0 للمستخدمين بمشاركة بيانات محدَّدة مع أحد التطبيقات مع الحفاظ على خصوصية أسماء المستخدمين وكلمات المرور والمعلومات الأخرى. على سبيل المثال، قد يستخدم تطبيق تلفزيوني بروتوكول OAuth 2.0 للحصول على إذن لاختيار ملف مخزّن على Google Drive.
ولأنّ التطبيقات التي تستخدم هذه العملية يتم توزيعها على أجهزة فردية، يُفترض أنّ التطبيقات لا يمكنها الاحتفاظ بسرّية. يمكنهم الوصول إلى Google APIs أثناء وجود المستخدم في التطبيق أو أثناء تشغيل التطبيق في الخلفية.
البدائل
إذا كنت تكتب تطبيقًا على نظام أساسي، مثل Android أو iOS أو macOS أو Linux أو Windows (بما في ذلك نظام التشغيل Windows Windows الأساسي)، الذي يمكنه الوصول إلى المتصفح وإمكانات الإدخال الكاملة، يمكنك استخدام مسار OAuth 2.0 لتطبيقات الجوّال وسطح المكتب. (يجب استخدام هذه الخطوات حتى إذا كان تطبيقك أداة سطر الأوامر بدون واجهة رسومية).
إذا كنت تريد فقط تسجيل دخول المستخدمين باستخدام حساباتهم على Google واستخدام الرمز المميّز JWT للحصول على معلومات الملف الشخصي الأساسية للمستخدم، يُرجى الاطّلاع على تسجيل الدخول على أجهزة التلفزيون وأجهزة الإدخال المحدودة.
المتطلّبات الأساسية
تفعيل واجهات برمجة التطبيقات لمشروعك
يحتاج أي تطبيق يستدعي واجهات Google API إلى تفعيل واجهات برمجة التطبيقات هذه في API Console.
لتفعيل واجهة برمجة تطبيقات لمشروعك:
- Open the API Library في Google API Console.
- If prompted, select a project, or create a new one.
- تسرد API Library جميع واجهات برمجة التطبيقات المتاحة مجمّعة حسب مجموعة المنتجات ومدى رواجها. إذا كانت واجهة برمجة التطبيقات التي تريد تفعيلها غير مرئية في القائمة، استخدِم البحث للعثور عليها، أو انقر على عرض الكل في مجموعة المنتجات التي تنتمي إليها.
- اختر واجهة برمجة التطبيقات التي تريد تفعيلها، ثم انقر على الزر تفعيل.
- If prompted, enable billing.
- If prompted, read and accept the API's Terms of Service.
إنشاء بيانات اعتماد للتفويض
يجب أن يحتوي أي تطبيق يستخدم OAuth 2.0 للدخول إلى واجهات برمجة تطبيقات Google على بيانات اعتماد التفويض التي تحدد التطبيق في خادم OAuth 2.0 التابع لـ Google. توضّح الخطوات التالية كيفية إنشاء بيانات الاعتماد لمشروعك. ويمكن للتطبيقات بعد ذلك استخدام بيانات الاعتماد للوصول إلى واجهات برمجة التطبيقات التي فعّلتها لذلك المشروع.
- Go to the Credentials page.
- انقر على إنشاء بيانات الاعتماد >؛ معرِّف عميل OAuth.
- اختَر نوع التطبيق أجهزة التلفزيون وأجهزة الإدخال المحدودة.
- أدخِل اسمًا لبرنامج OAuth 2.0، ثم انقر على إنشاء.
تحديد نطاقات الوصول
وتتيح النطاقات للتطبيق إمكانية طلب الوصول إلى الموارد التي يحتاج إليها فقط، مع السماح للمستخدمين أيضًا بالتحكم في مقدار حق الوصول الذي تمنحه لهم. وبالتالي، قد تكون هناك علاقة عكسية بين عدد النطاقات المطلوبة واحتمالية الحصول على موافقة المستخدم.
قبل البدء في تنفيذ تفويض OAuth 2.0، ننصحك بتحديد النطاقات التي يحتاج تطبيقك إلى إذن للوصول إليها.
راجِع قائمة النطاقات المسموح بها للتطبيقات أو الأجهزة المثبَّتة.
الحصول على رموز الدخول عبر OAuth 2.0
على الرغم من أن تطبيقك يعمل على جهاز ذي إمكانيات إدخال محدودة، يجب أن تتوفّر للمستخدمين إمكانية الوصول بشكل منفصل إلى جهاز يتضمن إمكانات إدخال أكثر ثراءً لإكمال عملية التفويض هذه. وتتّبع الخطوات الخطوات التالية:
- يرسل تطبيقك طلبًا إلى خادم تفويض Google الذي يحدد النطاقات التي سيطلب تطبيقك إذنًا للوصول إليها.
- يستجيب الخادم باستخدام العديد من معلومات المستخدم في الخطوات اللاحقة، مثل رمز الجهاز ورمز المستخدم.
- يتم عرض المعلومات التي يمكن للمستخدم إدخالها على جهاز منفصل لتفويض تطبيقك.
- يبدأ تطبيقك في استطلاع رأي خادم تفويض Google لتحديد ما إذا كان المستخدم قد فوَّض تطبيقك أم لا.
- ينتقل المستخدم إلى جهاز يتضمن إمكانيات إدخال أفضل، ويشغّل متصفّح الويب، وينتقل إلى عنوان URL المعروض في الخطوة 3 ويُدخِل رمزًا يظهر أيضًا في الخطوة 3. ويمكن للمستخدم بعد ذلك منح (أو رفض) حق الوصول إلى تطبيقك.
- تتضمّن الاستجابة التالية لطلب استطلاع الرأي الرموز المميزة التي يحتاج إليها تطبيقك للسماح بالطلبات بالنيابة عن المستخدم. (إذا رفض المستخدم الوصول إلى تطبيقك، لن تحتوي الاستجابة على رموز مميزة).
وتوضّح الصورة أدناه هذه العملية:

تشرح الأقسام التالية هذه الخطوات بالتفصيل. نظرًا لتنوّع الإمكانيات وبيئات التشغيل التي قد تتوفّر للأجهزة، تستخدم الأمثلة الموضّحة في هذا المستند برنامج سطر الأوامر curl
. ويجب نقل هذه الأمثلة بسهولة إلى لغات وأوقات تشغيل مختلفة.
الخطوة 1: طلب رموز الأجهزة والمستخدمين
في هذه الخطوة، يرسل جهازك طلب HTTP POST إلى خادم تفويض Google، على
https://oauth2.googleapis.com/device/code
، الذي يحدد تطبيقك
بالإضافة إلى نطاقات الوصول التي يريد تطبيقك الوصول إليها نيابة عن المستخدم.
يجب استرداد عنوان URL هذا من
مستند Discovery باستخدام قيمة البيانات الوصفية device_authorization_endpoint
. يجب تضمين معلمات طلب HTTP التالية:
المعلَمات | |
---|---|
client_id |
مطلوب
معرِّف العميل لتطبيقك. ويمكنك العثور على هذه القيمة في API Console Credentials page. |
scope |
مطلوب
هي قائمة للنطاقات المحدّدة بمسافات تحدّد الموارد التي يمكن لتطبيقك الوصول إليها نيابةً عن المستخدم. وتحدّد هذه القيم شاشة الموافقة التي يعرضها محرّك البحث Google للمستخدم. راجِع قائمة النطاقات المسموح بها للتطبيقات أو الأجهزة المثبّتة. وتتيح النطاقات للتطبيق إمكانية طلب الوصول إلى الموارد التي يحتاجها فقط مع السماح للمستخدمين أيضًا بالتحكم في مقدار إمكانية الوصول التي تمنحها إلى تطبيقك. وبالتالي، هناك علاقة عكسية بين عدد النطاقات المطلوبة واحتمال الحصول على موافقة المستخدم. |
أمثلة
يعرض المقتطف التالي نموذجًا لطلب:
POST /device/code HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id&scope=
يعرض المثال التالي أمر curl
لإرسال الطلب نفسه:
curl -d "client_id=client_id&scope=" \ https://oauth2.googleapis.com/device/code
الخطوة 2: معالجة استجابة خادم التفويض
سيعرض خادم التفويض أحد الردود التالية:
تم الرد بنجاح
إذا كان الطلب صالحًا، سيكون ردّه هو رمز JSON يحتوي على السمات التالية:
أماكن إقامة | |
---|---|
device_code |
قيمة تحدّدها Google بشكلٍ فريد لتحديد الجهاز الذي يُشغِّل التطبيق الذي يطلب
التفويض. سيفوّض المستخدم ذلك الجهاز من جهاز آخر مزوّد بإمكانيات إدخال أكثر ثراءً. على سبيل المثال، قد يستخدم المستخدم كمبيوترًا محمولاً أو هاتفًا جوّالاً لتفويض
تطبيق يعمل على التلفزيون. في هذه الحالة، تتعرّف الخاصية device_code على التلفزيون.
ويسمح هذا الرمز للجهاز الذي يُشغِّل التطبيق بتحديد ما إذا كان المستخدم قد منح إمكانية الوصول أو رفضه. |
expires_in |
طول المدة بالثواني، وتكون قيمتا device_code وuser_code صالحة. وإذا لم يُكمل المستخدم خلال هذا الوقت تدفق التفويض ولم يُجرِ جهازك أيضًا استطلاع رأي لاسترداد معلومات حول قرار المستخدم، قد تحتاج إلى إعادة بدء هذه العملية من الخطوة 1. |
interval |
المهلة الزمنية بالثواني، التي يجب أن ينتظر خلالها الجهاز بين طلبات استطلاع الرأي. على سبيل المثال، إذا كانت القيمة 5 ، يجب أن يرسل جهازك طلب استطلاع إلى خادم تفويض Google كل خمس ثوانٍ. يمكنك الاطّلاع على
الخطوة 3 للحصول على مزيد من التفاصيل. |
user_code |
قيمة حساسة لحالة الأحرف تحدّد لمحرّك البحث Google النطاقات التي يطلب التطبيق الوصول إليها. وستوجِّه واجهة المستخدم المستخدم إلى إدخال هذه القيمة على جهاز منفصل يتضمن إمكانات إدخال أكثر ثراءً. ويستخدم Google بعد ذلك القيمة لعرض مجموعة النطاقات الصحيحة عند مطالبة المستخدم بمنح حق الوصول إلى تطبيقك. |
verification_url |
عنوان URL يجب أن ينتقل المستخدم إليه على جهاز منفصل لإدخال user_code ومنح التطبيق أو رفضه. وستعرض واجهة المستخدم
هذه القيمة أيضًا. |
يعرض المقتطف التالي نموذج رد:
{ "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8", "user_code": "GQVQ-JKEC", "verification_url": "https://www.google.com/device", "expires_in": 1800, "interval": 5 }
تم تجاوز الحصة المخصصة
إذا تجاوزت طلبات رمز الجهاز الحصة المرتبطة بمعرِّف العميل، ستتلقّى استجابة 403، مع تضمين الخطأ التالي:
{ "error_code": "rate_limit_exceeded" }
وفي هذه الحالة، استخدِم استراتيجية تراجع لتقليل معدّل الطلبات.
الخطوة 3: عرض رمز المستخدم
اعرض verification_url
وuser_code
التي تم الحصول عليها في الخطوة 2 للمستخدم. يمكن أن تحتوي كلتا القيمتين على أي حرف قابل للطباعة من مجموعة أحرف US-ASCII. ويجب أن يوجّه المحتوى
الذي تعرضه للمستخدم إلى الانتقال إلى
verification_url
على جهاز منفصل وإدخال user_code
.
صمم واجهة المستخدم (UI) مع وضع القواعد التالية في الاعتبار:
user_code
- يجب عرض
user_code
في حقل يمكنه التعامل مع 15 'W' حرفًا بحجم. وبعبارة أخرى، إذا كان بإمكانك عرض الرمزWWWWWWWWWWWWWWW
بشكل صحيح، تكون واجهة المستخدم صالحة ونقترح استخدام قيمة السلسلة هذه عند اختبار طريقة عرضuser_code
في واجهة المستخدم. - إنّ
user_code
حسّاس لحالة الأحرف ويجب عدم تعديله بأي شكل من الأشكال، مثل تغيير حالة الأحرف أو إدراج أحرف تنسيق أخرى.
- يجب عرض
verification_url
- يجب أن تكون المساحة التي تعرض
verification_url
واسعة بما يكفي للتعامل مع سلسلة عنوان URL يبلغ طولها 40 حرفًا. - ويجب ألا تعدّل
verification_url
بأي شكل من الأشكال، باستثناء المخطّط المعروض اختياريًا. وإذا كنت تخطّط لإزالة المخطط (مثلhttps://
) من عنوان URL لأسباب تتعلّق بالعرض، تأكّد من أنّ تطبيقك يمكن أن يعالج كل من خيارَيhttp
وhttps
.
- يجب أن تكون المساحة التي تعرض
الخطوة 4: استطلاع خادم التفويض في Google
بما أن المستخدم سيستخدم جهازًا منفصلاً للانتقال إلى verification_url
ومنح إذن الوصول (أو رفضه)، لن يتم إشعار الجهاز الذي يقدّم الطلب تلقائيًا
عندما يستجيب المستخدم لطلب الوصول. ولهذا السبب، يحتاج الجهاز مقدِّم الطلب إلى استطلاع رأي خادم تفويض Google حتى تتمكن من تحديد وقت استجابة المستخدم للطلب.
يجب أن يواصل الجهاز الذي يقدِّم الطلب إرسال طلبات استطلاع الرأي حتى يتلقّى ردًّا يشير إلى أنّ المستخدم قد ردّ على طلب الوصول أو إلى أن تنتهي صلاحية device_code
وuser_code
التي تم الحصول عليها في الخطوة 2. تحدّد السمة interval
المعروضة في الخطوة 2 مقدار الوقت بالثواني للانتظار بين الطلبات.
عنوان URL لنقطة النهاية لإجراء الاستطلاع هو https://oauth2.googleapis.com/token
. يحتوي طلب إجراء الاستطلاع
على المعلّمات التالية:
المعلَمات | |
---|---|
client_id |
معرِّف العميل لتطبيقك. ويمكنك العثور على هذه القيمة في API Console Credentials page. |
client_secret |
سر العميل لـ client_id المقدمة. ويمكنك العثور على هذه القيمة في
API Console
Credentials page. |
device_code |
تمثّل هذه السمة device_code التي يعرضها خادم التفويض في
الخطوة 2. |
grant_type |
اضبط هذه القيمة على urn:ietf:params:oauth:grant-type:device_code . |
أمثلة
يعرض المقتطف التالي نموذجًا لطلب:
POST /token HTTP/1.1 Host: oauth2.googleapis.com Content-Type: application/x-www-form-urlencoded client_id=client_id& client_secret=client_secret& device_code=device_code& grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
يعرض المثال التالي أمر curl
لإرسال الطلب نفسه:
curl -d "client_id=client_id&client_secret=client_secret& \ device_code=device_code& \ grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \ -H "Content-Type: application/x-www-form-urlencoded" \ /token
الخطوة 5: استجابة المستخدم لطلب الوصول
تعرض الصورة التالية صفحة مشابهة لما يراه المستخدمون عند انتقالهم إلى verification_url
التي عرضها في الخطوة 3:

بعد إدخال user_code
، وفي حال عدم تسجيل الدخول إلى Google، ستظهر للمستخدم شاشة موافقة، مثل الشاشة الموضحة أدناه:

الخطوة 6: التعامل مع الردود على طلبات الاستطلاع
يستجيب خادم التفويض من Google لكل طلب اقتراع يتضمن أحد الردود التالية:
تم منح حق الوصول
إذا منحك المستخدم إمكانية الوصول إلى الجهاز (من خلال النقر على Allow
على شاشة الموافقة)،
ستتضمّن الاستجابة رمز دخول ورمزًا مميزًا لإعادة التحميل. تتيح الرموز المميزة لجهازك
الوصول إلى Google APIs نيابةً عن المستخدم. (تحدّد السمة scope
في الاستجابة واجهات برمجة التطبيقات التي يمكن للجهاز الوصول إليها).
وفي هذه الحالة، تحتوي استجابة واجهة برمجة التطبيقات على الحقول التالية:
الحقول | |
---|---|
access_token |
الرمز المميز الذي يرسله تطبيقك لتفويض طلب Google API. |
expires_in |
الفترة المتبقية من رمز الدخول بالثواني. |
refresh_token |
رمز مميز يمكنك استخدامه للحصول على رمز دخول جديد. وتكون الرموز المميّزة لإعادة التحميل صالحة إلى أن يُبطل المستخدم حق الوصول. تجدر الإشارة إلى أنه يتم إرجاع الرموز المميزة لإعادة التحميل دائمًا للأجهزة. |
scope |
نطاقات الدخول التي تمنحها access_token معبرًا عنها كقائمة من السلاسل الحساسة لحالة الأحرف والمفصولة بمسافات. |
token_type |
نوع الرمز المميّز المعروض في الوقت الحالي، يتم دائمًا ضبط قيمة هذا الحقل على Bearer . |
يعرض المقتطف التالي نموذج رد:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email", "token_type": "Bearer", "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
يكون لفترة محدودة رموز الدخول. إذا كان تطبيقك بحاجة إلى الوصول إلى واجهة برمجة تطبيقات على مدار فترة زمنية طويلة، يمكنه استخدام الرمز المميز لإعادة التحميل للحصول على رمز دخول جديد. إذا كان تطبيقك بحاجة إلى هذا النوع من الوصول، يجب تخزين الرمز المميّز لإعادة التحميل لاستخدامه لاحقًا.
تم رفض الوصول
إذا رفض المستخدم منح إمكانية الوصول إلى الجهاز، ستحتوي استجابة الخادم على
رمز حالة استجابة HTTP 403
(Forbidden
). وتحتوي الاستجابة على
الخطأ التالي:
{ "error": "access_denied", "error_description": "Forbidden" }
التفويض في انتظار المراجعة
إذا لم يكمل المستخدم بعد عملية التفويض، سيعرض الخادم رمز حالة استجابة HTTP 428
(Precondition Required
). تحتوي الاستجابة على الخطأ التالي:
{ "error": "authorization_pending", "error_description": "Precondition Required" }
إجراء استطلاعات رأي بشكل متكرّر
إذا كان الجهاز يرسل طلبات استطلاع بشكل متكرر، سيعرض الخادم رمز حالة استجابة HTTP 403
(Forbidden
). تتضمن الاستجابة الخطأ التالي:
{ "error": "slow_down", "error_description": "Forbidden" }
أخطاء أخرى
يعرض خادم التفويض أيضًا أخطاءً إذا كان طلب البحث يفتقد إلى أي معلَمات مطلوبة أو يحتوي على قيمة معلّمة غير صحيحة. وعادةً ما تتضمّن هذه الطلبات رمز حالة استجابة HTTP 400
(Bad Request
) أو 401
(Unauthorized
). وتشمل هذه الأخطاء ما يلي:
خطأ | رمز حالة HTTP | الوصف |
---|---|---|
invalid_client |
401 |
لم يتم العثور على عميل OAuth. على سبيل المثال، يحدث هذا الخطأ إذا كانت قيمة المعلَمة client_id غير صالحة. |
invalid_grant |
400 |
قيمة المعلمة code غير صالحة. |
unsupported_grant_type |
400 |
قيمة المعلمة grant_type غير صالحة. |
استدعاء واجهات Google API
بعد حصول تطبيقك على رمز دخول، يمكنك استخدام الرمز المميز لإجراء طلبات من خلال واجهة برمجة تطبيقات
Google نيابةً عن حساب مستخدم معيّن
إذا تم منح نطاقات الوصول المطلوبة من خلال واجهة برمجة التطبيقات. ولإجراء ذلك، يمكنك تضمين
رمز الدخول في طلب الوصول إلى واجهة برمجة التطبيقات من خلال تضمين معلمة
طلب البحث access_token
أو قيمة عنوان HTTP Authorization
Bearer
. وننصحك باستخدام عنوان HTTP، لأن سلاسل طلبات البحث غالبًا ما تكون مرئية في سجلات الخادم. وفي معظم
الحالات، يمكنك استخدام مكتبة برامج لإعداد طلباتك على Google APIs (مثل
استدعاء واجهة برمجة تطبيقات الملفات في Drive).
ويمكنك تجربة جميع واجهات برمجة تطبيقات Google وعرض نطاقاتها في مساحة بروتوكول OAuth 2.0.
أمثلة HTTP GET
قد يبدو استدعاء نقطة نهاية
drive.files
(واجهة برمجة تطبيقات ملفات Drive) باستخدام عنوان 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. |
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", "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
مع رمز خطأ.
النطاقات المسموح بها
لا يتوافق مسار OAuth 2.0 للأجهزة إلا مع النطاقات التالية:
OpenID Connect، تسجيل الدخول بحساب Google
email
openid
profile
واجهة برمجة تطبيقات Drive
https://www.googleapis.com/auth/drive.appdata
https://www.googleapis.com/auth/drive.file
واجهة برمجة تطبيقات YouTube
https://www.googleapis.com/auth/youtube
https://www.googleapis.com/auth/youtube.readonly