ربط حساب Google باستخدام OAuth

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

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

في مسار رمز التفويض، تحتاج إلى نقطتَي نهاية:

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

  • نقطة نهاية تبادل الرموز المميزة المسؤولة عن نوعين من التبادلات:

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

اختيار مسار OAuth 2.0

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

إرشادات التصميم

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

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

المتطلبات

  1. عليك إعلام المستخدم بأنّ حساب المستخدم سيتم ربطه بحساب Google، وليس على منتج محدّد من Google، مثل Google Home أو "مساعد Google".

الاقتراحات

ننصحك بتنفيذ الإجراءات التالية:

  1. عرض سياسة خصوصية Google: إدراج رابط يؤدي إلى سياسة خصوصية Google على شاشة طلب الموافقة

  2. البيانات التي ستتم مشاركتها. استخدام لغة واضحة وموجزة لإطلاع المستخدم على البيانات التي طلبها من Google والغرض من ذلك

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

  4. إمكانية الإلغاء. قدِّم للمستخدمين طريقة للرجوع أو الإلغاء في حال اختيار عدم الربط.

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

  6. إمكانية إلغاء الربط: قدِّم آلية تتيح للمستخدمين إلغاء الربط، مثل عنوان URL بإعدادات الحساب على النظام الأساسي. بدلاً من ذلك، يمكنك تضمين رابط إلى حساب Google حيث يمكن للمستخدمين إدارة الحساب المرتبط.

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

    • إذا كان على المستخدم إغلاق شاشة طلب الموافقة لتبديل الحسابات، أرسِل خطأ يمكن استرداده إلى Google حتى يتمكّن المستخدم من تسجيل الدخول إلى الحساب المطلوب باستخدام ربط OAuth والمسار الضمني.

  8. أدرِج شعارك. عرض شعار شركتك على شاشة طلب الموافقة يمكنك استخدام إرشادات النمط لوضع شعارك. إذا كنت تريد أيضًا عرض شعار Google، يمكنك الاطّلاع على الشعارات والعلامات التجارية.

إنشاء المشروع

لإنشاء مشروعك من أجل استخدام ميزة ربط الحسابات، اتّبِع الخطوات التالية:

  1. Go to the Google API Console.
  2. انقر فوق إنشاء مشروع .
  3. أدخل اسمًا أو اقبل الاقتراح الذي تم إنشاؤه.
  4. قم بتأكيد أو تحرير أي حقول متبقية.
  5. انقر فوق إنشاء .

لعرض معرف المشروع الخاص بك:

  1. Go to the Google API Console.
  2. ابحث عن مشروعك في الجدول على الصفحة المقصودة. يظهر معرف المشروع في عمود المعرف .

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

  1. افتح صفحة شاشة موافقة OAuth في وحدة تحكُّم Google APIs.
  2. اختَر المشروع الذي أنشأته للتو، إذا طُلب منك ذلك.

  3. في صفحة "شاشة موافقة OAuth"، املأ النموذج وانقر على زر "حفظ".

    اسم التطبيق: اسم التطبيق الذي يطلب الموافقة يجب أن يعكس الاسم تطبيقك بدقة وأن يكون متسقًا مع اسم التطبيق الذي يظهر للمستخدمين في أي مكان آخر. سيظهر اسم التطبيق في شاشة الموافقة على ربط الحساب.

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

    البريد الإلكتروني للدعم:ليتمكّن المستخدمون من التواصل معك لطرح أسئلة حول موافقتهم.

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

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

    رابط الصفحة الرئيسية للتطبيق: الصفحة الرئيسية لتطبيقك. يجب استضافة هذا النوع من المحتوى على نطاق معتمد.

    رابط سياسة خصوصية التطبيق: يظهر على شاشة الموافقة على ربط حساب Google. يجب استضافة هذا النوع من المحتوى على نطاق معتمد.

    رابط "بنود خدمة التطبيق" (اختياري): يجب استضافته على نطاق معتمد.

    الشكل 1. شاشة الموافقة على ربط حساب Google لتطبيق وهمي، Tunery

  4. تحقق من "حالة إثبات الملكية"، إذا كان طلبك يحتاج إلى التحقق، فانقر على الزر "إرسال للتحقق" لإرسال طلبك للتحقق. يمكنك الرجوع إلى متطلبات التحقُّق من OAuth لمعرفة التفاصيل.

تنفيذ خادم OAuth

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

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

تتضمن جلسة تدفق شفرة OAuth 2.0 التي بدأتها Google التدفق التالي:

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

التعامل مع طلبات التفويض

عندما تحتاج إلى إجراء ربط الحساب باستخدام تدفق رمز مصادقة OAuth 2.0 ، ترسل Google المستخدم إلى نقطة نهاية التفويض بطلب يتضمن المعلمات التالية:

معلمات نقطة نهاية التفويض
client_id معرّف العميل الذي عينته لـ Google.
redirect_uri عنوان URL الذي ترسل إليه الرد على هذا الطلب.
state قيمة مسك الدفاتر التي يتم إعادتها إلى Google بدون تغيير في عنوان URI لإعادة التوجيه.
scope اختياري: مجموعة بمسافات سلاسل نطاق التي تحدد بيانات Google يطلب الإذن ل.
response_type نوع القيمة المراد إرجاعها في الاستجابة. لتدفق كود 2.0 إذن أوث، ونوع الاستجابة دائما code .
user_locale إعداد اللغة حساب Google في RFC5646 الشكل، تستخدم لتوطين المحتوى الخاص بك في اللغة المفضلة للمستخدم.

على سبيل المثال، إذا نقطة النهاية تفويضك يتوفر في https://myservice.example.com/auth ، قد طلب تبدو كما يلي:

GET https://myservice.example.com/auth?client_id=GOOGLE_CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE_STRING&scope=REQUESTED_SCOPES&response_type=code&user_locale=LOCALE

لكي تتعامل نقطة نهاية التفويض مع طلبات تسجيل الدخول ، قم بالخطوات التالية:

  1. تحقق من أن client_id يطابق معرف العميل الذي قمت بتعيينه إلى Google، وأن redirect_uri يطابق URL إعادة توجيه تقدمها جوجل لخدمتكم. هذه الفحوصات مهمة لمنع منح الوصول إلى تطبيقات العميل غير المقصودة أو المهيأة بشكل خاطئ. إذا كنت دعم أوث متعددة التدفقات 2.0، تأكد أيضا أن response_type غير code .
  2. تحقق مما إذا كان المستخدم قد قام بتسجيل الدخول إلى خدمتك. إذا لم يقم المستخدم بتسجيل الدخول ، أكمل عملية تسجيل الدخول أو تسجيل الاشتراك في الخدمة.
  3. قم بإنشاء رمز تفويض لـ Google لاستخدامه في الوصول إلى API الخاص بك. يمكن أن يكون رمز التفويض أي قيمة سلسلة ، ولكن يجب أن يمثل بشكل فريد المستخدم ، والعميل الذي يمثل الرمز المميز له ، ووقت انتهاء صلاحية الرمز ، ويجب ألا يكون قابلاً للتخمين. أنت تُصدر عادةً رموز تفويض تنتهي صلاحيتها بعد 10 دقائق تقريبًا.
  4. تأكد من أن URL المحدد من قبل redirect_uri المعلمة لديه النموذج التالي: 
      https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
  https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
  5. إعادة توجيه متصفح المستخدم إلى URL المحدد من قبل redirect_uri المعلمة. تتضمن رمز إذن أنت ولدت للتو والأصلي، وقيمة الدولة معدلة عند إعادة توجيه بإلحاق code و state المعلمات. وفيما يلي مثال من URL الناتجة: 
    https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID?code=AUTHORIZATION_CODE&state=STATE_STRING

التعامل مع طلبات تبادل الرمز المميز

تعتبر نقطة نهاية تبادل الرمز المميز لخدمتك مسؤولة عن نوعين من عمليات تبادل الرمز المميز:

  • تبادل رموز التفويض لرموز الوصول وتحديث الرموز المميزة
  • تبادل رموز التحديث للحصول على رموز الوصول

تتضمن طلبات تبادل الرمز المميز المعلمات التالية:

معلمات نقطة نهاية تبادل الرمز المميز
client_id سلسلة تحدد أصل الطلب على أنه Google. يجب تسجيل هذه السلسلة في نظامك كمعرّف فريد لـ Google.
client_secret سلسلة سرية قمت بتسجيلها مع Google لخدمتك.
grant_type نوع الرمز الذي يتم تبادله. انها إما authorization_code أو refresh_token .
code عندما grant_type=authorization_code ، هذه المعلمة هي رمز تتلقاها Google إما من تسجيل الدخول الخاص بك أو رمزية مقابل نقطة النهاية.
redirect_uri عندما grant_type=authorization_code ، هذه المعلمة هي URL المستخدمة في طلب الترخيص الأولي.
refresh_token عندما grant_type=refresh_token ، هذه المعلمة هي التحديث رمز تتلقاها Google من هاتفك نقطة النهاية الصرف رمزية.
تبادل رموز التفويض لرموز الوصول وتحديث الرموز المميزة

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

لهذه الطلبات، وقيمة grant_type هي authorization_code ، وقيمة code هو قيمة رمز التفويض الذي منحته إياه سابقا إلى Google. فيما يلي مثال لطلب تبادل رمز ترخيص لرمز وصول ورمز تحديث مميز:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI

لتبادل رموز التفويض لوصول رمز والتحديث المنوال، يا رمزية يستجيب صرف نقطة النهاية ل POST طلبات عن طريق تنفيذ الخطوات التالية:

  1. تحقق من أن client_id يحدد الطلب الأصلي باعتباره الأصل المصرح لهم، وأن client_secret يطابق القيمة المتوقعة.
  2. تحقق من أن رمز التفويض صالح وغير منتهي الصلاحية ، وأن معرّف العميل المحدد في الطلب يطابق معرّف العميل المرتبط برمز التفويض.
  3. تأكد من أن URL المحدد من قبل redirect_uri المعلمة مطابق لقيمة المستخدمة في طلب الترخيص الأولي.
  4. إذا لم تتمكن من التحقق من كل من المعايير المذكورة أعلاه، إرجاع HTTP 400 طلب غير صحيح خطأ مع {"error": "invalid_grant"} بوصفه الهيئة.
  5. بخلاف ذلك ، استخدم معرف المستخدم من رمز التفويض لإنشاء رمز تحديث مميز ورمز وصول. يمكن أن تكون هذه الرموز أي قيمة سلسلة ، ولكن يجب أن تمثل بشكل فريد المستخدم والعميل الذي يمثل الرمز المميز لهما ، ويجب ألا تكون قابلة للتخمين. بالنسبة لرموز الوصول ، قم أيضًا بتسجيل وقت انتهاء صلاحية الرمز المميز ، والذي يكون عادةً بعد ساعة من إصدار الرمز المميز. لا تنتهي صلاحية رموز التحديث.
  6. إرجاع الكائن JSON التالية في الجسم للاستجابة HTTPS:
    {
"token_type": "Bearer",
"access_token": "ACCESS_TOKEN",
"refresh_token": "REFRESH_TOKEN",
"expires_in": SECONDS_TO_EXPIRATION
}

يخزن Google رمز الوصول ورمز التحديث المميز للمستخدم ويسجل انتهاء صلاحية رمز الوصول. عند انتهاء صلاحية رمز الوصول ، تستخدم Google رمز التحديث المميز للحصول على رمز وصول جديد من نقطة نهاية تبادل الرمز المميز.

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

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

لهذه الطلبات، وقيمة grant_type و refresh_token ، وقيمة refresh_token هي قيمة التحديث رمز لك الممنوحة سابقا إلى Google. فيما يلي مثال لطلب تبادل رمز تحديث لرمز وصول:

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

client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&grant_type=refresh_token&refresh_token=REFRESH_TOKEN

لتبادل وتحديث رمزية لرمز وصول، يا رمزية يستجيب صرف نقطة النهاية ل POST طلبات عن طريق تنفيذ الخطوات التالية:

  1. تحقق من أن client_id يحدد الطلب الأصلي وجوجل، وأن client_secret يطابق القيمة المتوقعة.
  2. تحقق من أن رمز التحديث صالح ، وأن معرّف العميل المحدد في الطلب يطابق معرّف العميل المرتبط برمز التحديث.
  3. إذا لم تتمكن من التحقق من كل من المعايير المذكورة أعلاه، إرجاع HTTP 400 طلب غير صحيح خطأ مع {"error": "invalid_grant"} بوصفه الهيئة.
  4. بخلاف ذلك ، استخدم معرف المستخدم من رمز التحديث لإنشاء رمز وصول. يمكن أن تكون هذه الرموز أي قيمة سلسلة ، ولكن يجب أن تمثل بشكل فريد المستخدم والعميل الذي يمثل الرمز المميز لهما ، ويجب ألا تكون قابلة للتخمين. بالنسبة لرموز الوصول ، قم أيضًا بتسجيل وقت انتهاء صلاحية الرمز المميز ، عادةً بعد ساعة من إصدار الرمز المميز.
  5. أعد كائن JSON التالي في نص استجابة HTTPS:
    {
"token_type": "Bearer",
"access_token": " ACCESS_TOKEN ",
"expires_in": SECONDS_TO_EXPIRATION
}
التعامل مع طلبات معلومات المستخدم

و نقطة النهاية المعلومات حول المستخدم موردا محمية أوث 2.0 المطالبات عودة عن المستخدم المرتبطة. يعد تنفيذ واستضافة نقطة نهاية معلومات المستخدم أمرًا اختياريًا ، باستثناء حالات الاستخدام التالية:

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

رؤوس طلب نقطة نهاية userinfo
Authorization header رمز الوصول من نوع Bearer.

على سبيل المثال، إذا كان لديك المعلومات حول المستخدم نقطة النهاية هي متوفرة في https://myservice.example.com/userinfo ، قد طلب تبدو كما يلي:

GET /userinfo HTTP/1.1
Host: myservice.example.com
Authorization: Bearer ACCESS_TOKEN

لكي تتعامل نقطة نهاية معلومات المستخدم مع الطلبات ، قم بالخطوات التالية:

  1. استخراج رمز الوصول من رأس التفويض وإرجاع المعلومات للمستخدم المرتبط برمز الوصول.
  2. إذا كان رمز وصول غير صالح، بإرجاع خطأ غير مصرح HTTP 401 مع استخدام WWW-Authenticate رأس استجابة. وفيما يلي مثال على استجابة خطأ المعلومات حول المستخدم:
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: error="invalid_token",
error_description="The Access Token expired"
    إذا 401 يتم إرجاع غير مصرح بها، أو أي استجابة خطأ فاشلة أخرى خلال عملية الربط، سوف يكون من الخطأ غير قابل للاسترداد، سيتم تجاهل الرموز التي تم استردادها وسيكون المستخدم لبدء عملية الربط مرة أخرى.

  3. إذا كان رمز وصول غير صالحة، وعودة وHTTP 200 استجابة مع كائن JSON التالية في الجسم للاستجابة HTTPS: 

    {
"sub": "USER_UUID",
"email": "EMAIL_ADDRESS",
"given_name": "FIRST_NAME",
"family_name": "LAST_NAME",
"name": "FULL_NAME",
"picture": "PROFILE_PICTURE",
}
    إذا كان لديك المعلومات حول المستخدم نقطة النهاية عوائد استجابة نجاح HTTP 200، واسترجاع رمز ويتم تسجيل الدعاوى المرفوعة ضد جوجل الخاص بالمستخدم الحساب.

    استجابة نقطة نهاية userinfo
    sub معرّف فريد يعرّف المستخدم في نظامك.
    email عنوان البريد الإلكتروني للمستخدم.
    given_name اختياري: الاسم الأول للمستخدم.
    family_name اختياري: اسم العائلة للمستخدم.
    name اختياري: الاسم الكامل للمستخدم.
    picture اختياري: الصورة الشخصية للمستخدم.

التحقّق من صحة عملية التنفيذ

يمكنك التحقق من صحة التطبيق الخاص بك باستخدام ملعب أوث 2.0 الأداة.

في الأداة ، قم بالخطوات التالية:

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

يمكنك التحقق من صحة التطبيق الخاص بك باستخدام حساب Google ربط تجريبي الأداة.

في الأداة ، قم بالخطوات التالية:

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