تلتزم Google بتعزيز المساواة العرقية في المجتمعات السوداء. أنظر كيف.

OAuth 2.0 للتلفزيون وتطبيقات أجهزة الإدخال المحدودة

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

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

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

البدائل

إذا كنت تكتب تطبيقًا لمنصة مثل Android أو iOS أو macOS أو Linux أو Windows (بما في ذلك Universal Windows Platform) ، والتي لديها إمكانية الوصول إلى المتصفح وإمكانيات الإدخال الكاملة ، فاستخدم تدفق 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 Credentials page.
  2. انقر على إنشاء بيانات اعتماد> معرّف عميل OAuth .
  3. حدد نوع تطبيق أجهزة التلفزيون وأجهزة الإدخال المحدودة .
  4. اختر اسمًا لعميل OAuth 2.0 وانقر على إنشاء .

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

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

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

راجع قائمة النطاقات المسموح بها للتطبيقات أو الأجهزة المثبتة.

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

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

  1. يرسل تطبيقك طلبًا إلى خادم تفويض Google يحدد النطاقات التي سيطلب تطبيقك الإذن بالوصول إليها.
  2. يستجيب الخادم بعدة أجزاء من المعلومات المستخدمة في الخطوات اللاحقة ، مثل رمز الجهاز ورمز المستخدم.
  3. أنت تعرض المعلومات التي يمكن للمستخدم إدخالها على جهاز منفصل لتفويض تطبيقك.
  4. يبدأ تطبيقك في استقصاء خادم تفويض Google لتحديد ما إذا كان المستخدم قد سمح لتطبيقك أم لا.
  5. يقوم المستخدم بالتبديل إلى جهاز يتمتع بقدرات إدخال أكثر ثراءً ، وتشغيل متصفح ويب ، والانتقال إلى عنوان URL المعروض في الخطوة 3 وإدخال رمز يتم عرضه أيضًا في الخطوة 3. يمكن للمستخدم بعد ذلك منح (أو رفض) الوصول إلى تطبيقك.
  6. تحتوي الاستجابة التالية لطلب الاقتراع على الرموز المميزة التي يحتاجها تطبيقك لتفويض الطلبات نيابة عن المستخدم. (إذا رفض المستخدم الوصول إلى تطبيقك ، فلن تحتوي الاستجابة على رموز.)

توضح الصورة أدناه هذه العملية:

يقوم المستخدم بتسجيل الدخول على جهاز منفصل يحتوي على متصفح

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

الخطوة 1: طلب رموز الجهاز والمستخدم

في هذه الخطوة ، يرسل جهازك طلب HTTP POST إلى خادم تفويض Google ، على https://oauth2.googleapis.com/device/code ، والذي يحدد تطبيقك بالإضافة إلى نطاقات الوصول التي يريد التطبيق الوصول إليها على باسمى او لاجلى. يجب عليك استرداد عنوان URL هذا من مستند الاكتشاف باستخدام قيمة بيانات تعريف 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=email%20profile

يوضح هذا المثال أمر curl لإرسال نفس الطلب:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

الخطوة 2: معالجة استجابة خادم التفويض

سيرد خادم التفويض أحد الاستجابات التالية:

استجابة النجاح

إذا كان الطلب صالحًا ، فستكون استجابتك عبارة عن كائن JSON يحتوي على الخصائص التالية:

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

يتيح هذا الرمز للجهاز الذي يقوم بتشغيل التطبيق تحديد ما إذا كان المستخدم قد منح حق الوصول أم رفضه.

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: اعرض كود المستخدم

اعرض user_code الخاص verification_url و user_code تم الحصول عليه في الخطوة 2 للمستخدم. يمكن أن تحتوي كلا القيمتين على أي حرف قابل للطباعة من مجموعة أحرف US-ASCII. يجب أن يوجه المحتوى الذي تعرضه للمستخدم إلى الانتقال إلى عنوان verification_url من user_code على جهاز منفصل وإدخال رمز user_code .

صمم واجهة المستخدم الخاصة بك مع مراعاة القواعد التالية:

  • 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 هذه القيمة على 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: يستجيب المستخدم لطلب الوصول

تُظهر الصورة التالية صفحة مشابهة لما يراه المستخدمون عند انتقالهم إلى عنوان URL الخاص verification_url الذي قمت بعرضه في الخطوة 3 :

قم بتوصيل الجهاز بإدخال رمز

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

مثال على شاشة الموافقة لعميل الجهاز

الخطوة 6: معالجة الردود على طلبات الاقتراع

يستجيب خادم تفويض Google لكل طلب اقتراع بإحدى الاستجابات التالية:

لقد تم منح الوصول

إذا منح المستخدم حق الوصول إلى الجهاز (عن طريق النقر فوق Allow في شاشة الموافقة) ، فستحتوي الاستجابة على رمز وصول ورمز تحديث مميز. تمكن الرموز المميزة جهازك من الوصول إلى Google APIs نيابة عن المستخدم. (تحدد خاصية scope في الاستجابة واجهات برمجة التطبيقات التي يمكن للجهاز الوصول إليها.)

في هذه الحالة ، تحتوي استجابة API الحقول التالية:

مجالات
access_token الرمز الذي يرسله تطبيقك لتفويض طلب Google API.
expires_in العمر المتبقي لرمز الوصول بالثواني.
refresh_token رمز مميز يمكنك استخدامه للحصول على رمز وصول جديد. رموز التحديث صالحة حتى يقوم المستخدم بإلغاء الوصول. لاحظ أنه يتم إرجاع رموز التحديث دائمًا للأجهزة.
scope نطاقات الوصول الممنوحة بواسطة access_token التعبير عنها 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"
}

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

تم الرفض

إذا رفض المستخدم منح الوصول إلى الجهاز ، فإن استجابة الخادم لها رمز حالة استجابة 403 HTTP ( Forbidden ). تحتوي الاستجابة على الخطأ التالي:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

إذن الانتظار

إذا لم يكمل المستخدم تدفق التفويض بعد ، فسيعرض الخادم رمز حالة استجابة HTTP 428 ( Precondition Required شرط Precondition Required ). تحتوي الاستجابة على الخطأ التالي:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

الاقتراع بشكل متكرر

إذا كان الجهاز يرسل طلبات الاستقصاء بشكل متكرر ، فسيقوم الخادم بإرجاع رمز حالة استجابة 403 HTTP ( 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 APIs

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

يمكنك تجربة جميع واجهات برمجة تطبيقات Google وعرض نطاقاتها في ملعب OAuth 2.0 .

أمثلة HTTP GET

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

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

تحديث رمز الوصول

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

لتحديث رمز وصول ، يرسل تطبيقك طلب 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 Sign-In

  • email
  • openid
  • profile

محرك API

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

يوتيوب API

  • https://www.googleapis.com/auth/youtube
  • https://www.googleapis.com/auth/youtube.readonly