نظرة عامة

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

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

يمكن للمستخدمين ربط حساباتهم أو إلغاء ربطها وإنشاء حساب جديد اختياريًا على منصتك باستخدام "ربط حساب Google".

حالات الاستخدام

في ما يلي بعض أسباب تنفيذ ربط حساب Google:

  • شارك بيانات المستخدم من نظامك الأساسي مع تطبيقات Google وخدماتها.

  • شغِّل محتوى الفيديو والأفلام باستخدام Google TV.

  • إدارة أجهزة Google Smart Home والتحكّم فيها باستخدام تطبيق Google Home و"مساعد Google"و"Ok Google": تشغيل المصابيح &quot

  • يمكنك إنشاء تجارب مخصّصة باستخدام"مساعد Google"والحصول على وظائفها باستخدام ميزة"المهام في المحادثة"، "Ok Google، أريد طلب الحصول على الخدمة من Starbucks&quot.

  • تمكين المستخدمين من ربح المكافآت من خلال مشاهدة أحداث البث المباشر المؤهلة على YouTube بعد ربط حسابهم على Google بحساب شريك بمكافأة

  • التعبئة تلقائيًا للحسابات الجديدة أثناء الاشتراك من خلال البيانات التي تتم مشاركتها من خلال ملف شخصي لحساب Google

الميزات المتاحة

تتوفّر هذه الميزات من خلال ربط حساب Google:

  • يمكنك مشاركة بياناتك بسرعة وسهولة باستخدام مسار ربط بروتوكول OAuth الضمني.

  • توفير أمان محسَّن من خلال مسار رمز تفويض ربط OAuth.

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

  • يمكنك تقليل أي صعوبات قد تواجهها باستخدام App Flip. ومن تطبيق Google موثوق به، يمكنك بنقرة واحدة فتح تطبيق Android أو iOS الذي تم التحقق منه بأمان بنقرة واحدة ومن أجل منح المستخدمين موافقة الحسابات والروابط.

  • يمكنك تحسين خصوصية المستخدم عن طريق تحديد نطاقات مخصَّصة لمشاركة البيانات اللازمة فقط، وزيادة ثقة المستخدم من خلال تحديد كيفية استخدام بياناته بوضوح.

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

مسارات ربط الحسابات

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

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

ربط OAuth ('Web OAuth')

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

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

الشكل 1. ربط الحساب على هاتف المستخدم باستخدام OAuth على الويب

ربط واجهة تطبيق OAuth المستندة إلى OAuth ('App Flip')

مسار OAuth الذي يوجّه المستخدمين إلى تطبيقك للربط.

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

يتوفّر تطبيق App Flip لكل من Android وiOS.

آلية العمل:

يتحقق تطبيق Google مما إذا كان تطبيقك مثبتًا على جهاز المستخدم:

  • في حال العثور على التطبيق، يتم "قلب" المستخدم إلى تطبيقك. ويجمع تطبيقك الموافقة من المستخدم لربط الحساب بحساب Google، ثم "يقلب" &#39؛ إلى مساحة عرض Google.
  • في حال عدم العثور على التطبيق أو حدوث خطأ أثناء عملية الربط بين التطبيق والعكس، تتم إعادة توجيه المستخدم إلى تدفق بسيط أو تدفق OAuth OAuth.

الشكل 2. ربط الحساب على هاتف المستخدم باستخدام ميزة "قلب الشاشة"

الربط السلس المستند إلى OAuth ('Streamstream')

تضيف ميزة الربط السلس لتسجيل الدخول بحساب Google OAuth خدمة "تسجيل الدخول بحساب Google" في أعلى عملية ربط OAuth، ما يتيح للمستخدمين إكمال عملية الربط بدون مغادرة مساحة Google، ما يؤدي إلى تقليل المعوقات والانسحاب. الربط البسيط المستند إلى OAuth يقدّم أفضل تجربة للمستخدم من خلال تسجيل الدخول بسلاسة وإنشاء الحساب وربط الحساب من خلال الجمع بين تسجيل الدخول بحساب Google وربط OAuth. يجب أن تتوافق خدمتك مع نقاط النهاية المتوافقة مع OAuth 2.0 ونقطة انتهاء تبادل الرموز المميزة. بالإضافة إلى ذلك، يجب أن تتوافق نقطة نهاية تبادل الرموز المميّزة مع تأكيدات JSON Web Token (JWT) وتنفيذ check وcreate وget.

آلية العمل:

تؤكّد Google حساب المستخدم وتُرسل إليك هذه المعلومات:

  • في حال توفُّر حساب للمستخدم في قاعدة البيانات، يربط المستخدم حسابه في Google بنجاح بحسابه على خدمتك.
  • في حال عدم توفّر حساب للمستخدم في قاعدة البيانات، يمكن للمستخدم إنشاء حساب جديد تابع لجهة خارجية باستخدام المعلومات المؤكّدة التي تقدّمها Google : البريد الإلكتروني والاسم وصورة الملف الشخصي أو اختيار تسجيل الدخول والربط باستخدام عنوان بريد إلكتروني آخر (سيتطلب هذا من المستخدم تسجيل الدخول إلى الخدمة عبر OAuth على الويب).

الشكل 3. ربط الحسابات على هاتف المستخدم من خلال الربط السلس

ما هي الخطوات التي يجب استخدامها؟

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

استخدام الرموز المميّزة

يستند ربط حساب Google إلى معيار OAuth 2.0 في المجال.

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

Token types

OAuth 2.0 uses strings called tokens to communicate between the user agent, the client application, and the OAuth 2.0 server.

Three types of OAuth 2.0 tokens can be used during account linking:

  • Authorization code. A short-lived token that can be exchanged for an access and a refresh token. For security purposes, Google calls your authorization endpoint to obtain a single use or very short-lived code.

  • Access token. A token that grants the bearer access to a resource. To limit exposure that could result from the loss of this token, it has a limited lifetime, usually expiring after an hour or so.

  • Refresh token. A long-lived token that can be exchanged for a new access token when an access token expires. When your service integrates with Google, this token is exclusively stored and used by Google. Google calls your token exchange endpoint to exchange refresh tokens for access tokens, which are in turn used to access user data.

Token handling

Race conditions in clustered environments and client-server exchanges can result in complex timing and error handling scenarios when working with tokens. For example:

  • You receive a request for a new access token, and you issue a new access token. Concurrently, you receive a request for access to your service's resource using the previous, unexpired access token.
  • Your refresh token reply is yet to be received (or is never received) by Google. Meanwhile, the previously valid refresh token is used in a request from Google.

Requests and replies can arrive in any order, or not at all due to asynchronous services running in a cluster, network behavior, or other means.

Immediate and fully consistent shared state both within, and between, your and Google's token handling systems cannot be guaranteed. Multiple valid, unexpired tokens can coexist within or across systems short period of time. To minimize negative user impact we recommend you do the following:

  • Accept unexpired access tokens, even after a newer token is issued.
  • Use alternatives to Refresh Token Rotation.
  • Support multiple, concurrently valid access and refresh tokens. For security, you should limit the number of tokens and token lifetime.
Maintenance and outage handling

During maintenance or unplanned outages Google might be unable to call your authorization or token exchange endpoints to obtain access and refresh tokens.

Your endpoints should respond with a 503 error code and empty body. In this case, Google retries failed token exchange requests for a limited time. Provided that Google is later able to obtain refresh and access tokens, failed requests are not visible to users.

Failing requests for an access token result in a visible error, if initiated by a user. Users will be required to retry linking failures if the implicit OAuth 2.0 flow is used.

Recommendations

There are many solutions to minimize maintenance impact. Some options to consider:

  • Maintain your existing service and route a limited number of requests to your newly updated service. Migrate all requests only after confirming expected functionality.

  • Reduce the number of token requests during the maintenance period:

    • Limit maintenance periods to less than the access token lifetime.

    • Temporarily increase the access token lifetime:

      1. Increase token lifetime to greater than maintenance period.
      2. Wait twice the duration of your access token lifetime, enabling users to exchange short lived tokens for longer duration tokens.
      3. Enter maintenance.
      4. Respond to token requests with a 503 error code and empty body.
      5. Exit maintenance.
      6. Decrease token lifetime back to normal.

التسجيل من خلال Google

ونحتاج إلى تفاصيل إعداد OAuth 2.0 ومشاركة بيانات الاعتماد لتفعيل ربط الحساب. ويمكنك الاطّلاع على التسجيل لمعرفة التفاصيل.