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

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

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

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

• نقطة نهاية التفويض التي تعرِض واجهة مستخدم تسجيل الدخول للمستخدمين الذين لم يسجّلوا الدخول من قبل تُنشئ نقطة نهاية التفويض أيضًا код التفويض الذي ينتهي صلاحيته بعد فترة قصيرة لتسجيل موافقة المستخدمين على الوصول المطلوب.

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

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

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

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

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

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

المتطلبات

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

اقتراحات

ننصحك باتّباع الخطوات التالية:

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

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

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

4. إمكانية إلغاء الاشتراك: يجب توفير طريقة للمستخدمين للرجوع أو الإلغاء إذا اختَروا عدم الربط.

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

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

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

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

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

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

لإنشاء مشروعك من أجل استخدام ربط الحسابات:

ضبط شاشة طلب الموافقة المتعلّقة ببروتوكول OAuth

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

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

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

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

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

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

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

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

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

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

   رابط بنود خدمة التطبيق (اختياري): يجب أن يكون مستضافًا على نطاق مفوَّض.

   

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

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

تنفيذ خادم OAuth

لدعم التدفق الضمني لـ OAuth 2.0، تُجري الخدمة تفويضًا. نقطة النهاية متوفرة عبر HTTPS. نقطة النهاية هذه مسؤولة عن المصادقة الحصول على موافقة من المستخدمين للوصول إلى البيانات. نقطة نهاية التفويض توفّر واجهة مستخدم لتسجيل الدخول للمستخدمين الذين لم يسجّلوا الدخول إلى حساباتهم الموافقة على الوصول المطلوب.

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

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

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

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

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

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

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

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

1. يُرجى التحقّق من القيمتَين client_id وredirect_uri من أجل: منع منح الوصول إلى تطبيقات العميل غير المقصودة أو التي تم إعدادها بشكلٍ غير صحيح:

   • تأكَّد من أنّ client_id يتطابق مع معرّف العميل الذي أدخلته. تعيينه إلى Google.
   • تأكَّد من أنّ عنوان URL المحدّد من قِبل redirect_uri على النحو التالي:

     https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID
     https://oauth-redirect-sandbox.googleusercontent.com/r/YOUR_PROJECT_ID
     

2. تحقق مما إذا كان المستخدم قد سجّل الدخول إلى خدمتك. في حال لم يكن المستخدم مسجِّلاً الدخول أو أكمل عملية تسجيل الدخول أو الاشتراك في الخدمة.

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

4. إرسال استجابة HTTP تؤدي إلى إعادة توجيه متصفّح المستخدم إلى عنوان URL التي تحددها المعلمة redirect_uri. تضمين جميع المعلمات التالية في جزء عنوان URL:

   • access_token: رمز الدخول الذي أنشأته للتو
   • token_type: السلسلة bearer
   • state: قيمة الحالة غير المعدَّلة من القيمة الأصلية طلب

   في ما يلي مثال على عنوان URL الناتج:

   https://oauth-redirect.googleusercontent.com/r/YOUR_PROJECT_ID#access_token=ACCESS_TOKEN&token_type=bearer&state=STATE_STRING

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

Handle userinfo requests

The userinfo endpoint is an OAuth 2.0 protected resource that return claims about the linked user. Implementing and hosting the userinfo endpoint is optional, except for the following use cases:

• Linked Account Sign-In with Google One Tap.
• Frictionless subscription on AndroidTV.

After the access token has been successfully retrieved from your token endpoint, Google sends a request to your userinfo endpoint to retrieve basic profile information about the linked user.

For example, if your userinfo endpoint is available at https://myservice.example.com/userinfo, a request might look like the following:

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

For your userinfo endpoint to handle requests, do the following steps:

1. Extract access token from the Authorization header and return information for the user associated with the access token.
2. If the access token is invalid, return an HTTP 401 Unauthorized error with using the WWW-Authenticate Response Header. Below is an example of a userinfo error response:

   HTTP/1.1 401 Unauthorized
   WWW-Authenticate: error="invalid_token",
   error_description="The Access Token expired"
   

   If a 401 Unauthorized, or any other unsuccessful error response is returned during the linking process, the error will be non-recoverable, the retrieved token will be discarded and the user will have to initiate the linking process again.

3. If the access token is valid, return and HTTP 200 response with the following JSON object in the body of the HTTPS response:

   {
   "sub": "USER_UUID",
   "email": "EMAIL_ADDRESS",
   "given_name": "FIRST_NAME",
   "family_name": "LAST_NAME",
   "name": "FULL_NAME",
   "picture": "PROFILE_PICTURE",
   }

   If your userinfo endpoint returns an HTTP 200 success response, the retrieved token and claims are registered against the user's Google account.

   userinfo endpoint response
   sub	A unique ID that identifies the user in your system.
   email	Email address of the user.
   given_name	Optional: First name of the user.
   family_name	Optional: Last name of the user.
   name	Optional: Full name of the user.
   picture	Optional: Profile picture of the user.

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

您可以使用 OAuth 2.0 Playground 工具验证您的实现。

在该工具中，执行以下步骤：

1. 点击配置 settings 以打开 OAuth 2.0 配置窗口。
2. 在 OAuth flow 字段中，选择 Client-side（客户端）。
3. 在 OAuth 端点字段中，选择自定义。
4. 在相应字段中指定您的 OAuth 2.0 端点和您分配给 Google 的客户端 ID。
5. 在第 1 步部分，不要选择任何 Google 范围。请将此字段留空或输入对服务器有效的范围（如果您不使用 OAuth 范围，则可以输入任意字符串）。完成后，点击授权 API。
6. 在 Step 2 和 Step 3 部分中，完成 OAuth 2.0 流程，并验证每个步骤是否按预期运行。

您可以使用 Google 账号关联演示版工具验证您的实现。

在该工具中，执行以下步骤：

1. 点击使用 Google 账号登录按钮。
2. 选择您要关联的账号。
3. 输入服务 ID。
4. （可选）输入您要请求访问权限的一个或多个范围。
5. 点击开始演示。
6. 当系统提示时，请确认您同意或拒绝关联请求。
7. 确认您已被重定向到您的平台。