تم إيقاف إجراءات المحادثات نهائيًا في 13 حزيران (يونيو) 2023. لمزيد من المعلومات، يُرجى الاطّلاع على
إنهاء إجراءات المحادثة.
اختيار نوع ربط الحساب (Dialogflow)
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
النوع الأمثل لربط الحساب للإجراء الخاص بك هو النوع الذي يقدّم
أبسط تجربة للمستخدمين ويتناسب مع احتياجات تطبيقك أو
نشاطك التجاري. ويعتمد اختيار نوع الربط في معظم الأحيان على العوامل التالية:
- ما إذا كنت تريد السماح بإنشاء الحساب عبر الصوت
- ما إذا كنت تريد أن يتمكن المستخدمون من تسجيل الدخول إلى خدمتك باستخدام حساب غير تابع لشركة Google
- ما إذا كان بإمكان الخدمة تخزين المعلومات السرية أم لا
(أي سر العميل)
لمعرفة نوع ربط الحساب المثالي، اتّبِع الخطوات التالية:
- فكّر في الأسئلة الواردة في القسم
تحديد نوع تسجيل الدخول المفضّل لديك.
- راجِع شجرة القرار لاختيار نوع الربط.
- انتقل إلى القسم الذي يتوافق مع النوع الأولي الذي
اخترته لتحسين كيفية عمله بشكل أكبر.
تحديد نوع تسجيل الدخول المفضّل لديك
قبل استشارة شجرة القرار، ضع في اعتبارك الأسئلة التالية:
- هل تتوقع أن يكون لدى جميع المستخدمين حساب على Google؟
- إذا كان الإجراء الخاص بك يستهدف "مساعد Google" فقط، من المتوقّع أن يكون لدى جميع المستخدمين حساب Google. إذا كان الإجراء الخاص بك يستهدف منصات غير "مساعد Google"، لا يمكنك توقّع أن يكون لدى جميع المستخدمين حساب Google.
- إذا كانت خدمتك تضم مستخدمين حاليين، من المحتمل أنّ البعض لا يملكون حسابًا على Google أو لم يسجّلوا الدخول إلى الخدمة باستخدام حساب على Google.
- إذا كان لديك بروتوكول OAuth، هل يمكن توسيعه ليتوافق مع بروتوكول Google؟
- للتوافق مع بروتوكول Google، يجب أن تكون قادرًا على إضافة وظيفتي
intent=get
وintent=create إلى نقطة نهاية تبادل الرموز المميّزة. تتيح هذه الوظيفة لـ Google التحقق مما إذا كان المستخدم موجودًا بالفعل في الخلفية وتقديم طلب لإنشاء حساب جديد على خدمتك، على التوالي.
اتبع شجرة القرار أدناه لتحديد نوع ربط الحساب المثالي لك ولمستخدميك:
بعد اختيار نوع الربط، يمكنك المتابعة إلى القسم المقابل أدناه لمعرفة المزيد حول طريقة عمله واتخاذ قرارات إضافية بشأن آلية عمل ربط الحسابات في الإجراء الخاص بك.
OAuth وتسجيل الدخول بحساب Google
يضيف نوع ربط OAuth و"تسجيل الدخول بحساب Google" GSI إلى ميزة ربط الحساب المستنِد إلى بروتوكول OAuth، ما يوفّر مزايا GSI (مثل الربط الصوتي لمستخدمي Google) مع تفعيل ربط الحساب للمستخدمين الذين سجّلوا في خدمتك باستخدام حساب غير تابع لشركة Google. ويكون هذا النوع من الربط مفيدًا بشكل خاص للمستخدمين النهائيين لأنّه يوفّر تدفقًا سلسًا
لمستخدمي Google مع إجراء احتياطي للمستخدمين غير التابعين لشركة Google. لمزيد من المعلومات
حول كيفية عمل نوع ربط OAuth وGSI، يُرجى الاطّلاع على
دليل مفهوم تسجيل الدخول باستخدام بروتوكول OAuth وتسجيل الدخول بحساب Google.
تحسين نوع الربط بين OAuth و"تسجيل الدخول بحساب Google"
عند استخدام نوع ربط حساب OAuth وGSI في الإجراء، يمكنك تحديد الإجابات عن الأسئلة التالية في وحدة تحكُّم المهام لتحديد آلية العمل:
هل تريد تفعيل ميزة إنشاء حساب Voice أو السماح فقط بإنشاء الحساب على موقعك الإلكتروني؟
بشكل عام، يجب تمكين إنشاء الحساب عبر الصوت حتى يتمكن
المستخدمون الذين يستخدمون جهازًا لا يتم فحصه من إنشاء حساب بدون الحاجة إلى
نقل الحساب إلى جهاز آخر. إذا لم تسمح بإنشاء الحساب عبر الصوت، سيفتح "مساعد Google" عنوان URL للموقع الإلكتروني الذي قدّمته للمصادقة
ووجّه المستخدم إلى هاتف لمواصلة عملية ربط الحساب.
ومع ذلك، يجب عدم السماح بإنشاء الحساب عبر الصوت في أي من الحالات التالية:
- يجب أن تتوفّر لديك إمكانية التحكّم الكامل في عملية إنشاء الحساب. على سبيل المثال، قد تحتاج إلى عرض بنود الخدمة للمستخدم أثناء إنشاء الحساب أو أي نوع آخر من الإشعارات.
- وتريد التأكد من أن المستخدمين الذين لديهم حساب معك يسجِّلون الدخول باستخدام هذا الحساب. على سبيل المثال، قد تريد أن يواصل المستخدمون استخدام حساباتهم الحالية إذا كنت تقدّم برنامج ولاء ولا تريد أن يخسر المستخدمون النقاط المتراكمة في حساباتهم.
هل تريد استخدام مسار رمز التفويض أو التدفق الضمني؟
يختلف تدفق رمز التفويض عن التدفق الضمني في أن تدفق رمز التفويض يتطلب نقطة نهاية ثانية، وهي نقطة نهاية تبادل الرمز المميّز. تستخدم نقطة النهاية هذه الرموز المميّزة لإعادة التحميل لإنشاء رموز دخول جديدة قصيرة الأجل بدون مطالبة المستخدم بتسجيل الدخول مرة أخرى.
وعلى العكس من ذلك، إذا استخدمت التدفق الضمني، فستعرض على Google رمز دخول طويل الأمد
لا يلزم عادةً إعادة إنشائه. لمزيد من المعلومات عن رمز التفويض والتدفقات الضمنية، يُرجى الاطّلاع على دليل مفهوم OAuth وتسجيل الدخول بحساب Google.
تنصح Google باستخدام مسار رمز التفويض في الإجراء
لأنه أكثر أمانًا. ومع ذلك، يمكنك استخدام المسار الضمني بدلاً من ذلك إذا
لم تتمكّن الخدمة من تخزين معلومات سرية (أي سر العميل).
على سبيل المثال، يجب عليك استخدام التدفق الضمني للعملاء العامين مثل تطبيقات الصفحة الواحدة (SPA).
بعد النظر في نقاط القرار هذه، راجع شجرة القرار التالية:
تسجيل الدخول بحساب Google
باستخدام نوع ربط GSI، يمكن للإجراء الخاص بك طلب الوصول إلى الملف الشخصي للمستخدم في Google أثناء المحادثة واستخدام معلومات الملف الشخصي للتحقق مما إذا كان المستخدم موجودًا في الواجهة الخلفية لخدمتك. إذا لم يكن المستخدم موجودًا، يمكنه إنشاء حساب جديد في نظامك باستخدام معلومات الملف الشخصي على Google.
بالنسبة إلى GSI، يجب تمكين إنشاء الحساب عبر الصوت، مما يتيح للمستخدم إكمال العملية بأكملها عبر الصوت. لمزيد من المعلومات حول GSI، راجِع
دليل مفهوم تسجيل الدخول بحساب Google.
OAuth
من خلال نوع ربط OAuth، يسجِّل المستخدم الدخول باستخدام مسار OAuth 2 العادي.
يتوافق نوع ربط OAuth مع مسارَي OAuth 2.0 المتوافقَين مع معايير الصناعة: تدفقَي الرمز الضمني والتفويض.
لا تنصح Google باستخدام نوع ربط OAuth وحده، لأنّه يتطلّب نقل
المستخدم من الصوت إلى الشاشة لإكمال عملية تسجيل الدخول إذا كان المستخدم على
جهاز لا يفحص الشاشة. يمكنك استخدام هذا المسار في حال كان لديك تطبيق حالي لخادم OAuth 2، ولا يمكنك توسيع نقطة نهاية تبادل الرموز المميّزة لإتاحة استخدام بروتوكولات Google للربط التلقائي وإنشاء الحسابات من الرمز المميّز للمعرّف. لمزيد من المعلومات، راجِع دليل مفهوم OAuth.
تحسين التدفق
عند استخدام نوع ربط حساب OAuth في الإجراء الخاص بك، يجب تحديد الإجابة عن السؤال التالي في وحدة تحكّم الإجراءات لتحديد طريقة عمله:
هل تريد استخدام مسار رمز التفويض أو التدفق الضمني؟
يتوافق نوع ربط OAuth مع مسارَي OAuth 2.0 المتوافقَين مع معايير الصناعة: تدفقَي الرمز الضمني والتفويض. يختلف تدفق رمز التفويض
والتدفق الضمني في أنّ تدفق رمز التفويض يتطلب
نقطة نهاية ثانية، وهي نقطة نهاية تبادل الرمز المميّز. تستخدم نقطة النهاية هذه الرموز المميّزة لإعادة التحميل لإنشاء رموز دخول جديدة قصيرة الأجل بدون مطالبة المستخدم بتسجيل الدخول مرة أخرى.
وعلى العكس من ذلك، إذا استخدمت التدفق الضمني، فستعرض على Google رمز دخول طويل الأمد
لا يلزم عادةً إعادة إنشائه. لمزيد من المعلومات عن رمز التفويض والتدفقات الضمنية، يُرجى الاطِّلاع على دليل مفهوم OAuth.
تنصح Google باستخدام مسار رمز التفويض في الإجراء
لأنه أكثر أمانًا. ومع ذلك، يمكنك استخدام المسار الضمني بدلاً من ذلك إذا
لم تتمكّن الخدمة من تخزين معلومات سرية (أي سر العميل).
على سبيل المثال، يجب عليك استخدام التدفق الضمني للعملاء العامين مثل تطبيقات الصفحة الواحدة (SPA).
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eThis guide helps you choose the best account linking type for your Google Action based on factors like user experience and security needs.\u003c/p\u003e\n"],["\u003cp\u003eThree main linking types are discussed: OAuth and Google Sign-In (recommended), Google Sign-In, and OAuth.\u003c/p\u003e\n"],["\u003cp\u003eEach type has different features and considerations, such as whether to allow voice account creation or use authorization code versus implicit flow.\u003c/p\u003e\n"],["\u003cp\u003eDecision trees and further details are provided to refine your chosen linking type for optimal implementation within your Action.\u003c/p\u003e\n"],["\u003cp\u003eOAuth and Google Sign-In offer a combined approach for both Google and non-Google user accounts, providing a smoother experience.\u003c/p\u003e\n"]]],[],null,["# Choose your account linking type (Dialogflow)\n\nThe optimal account linking type for your Action is one that provides the\nsimplest experience for your users and fits the needs of your application or\nbusiness. Choosing your linking type is mostly dependent on the following\nfactors:\n\n- Whether you want to allow account creation via voice\n- Whether you want users to be able to sign in to your service with a non-Google account\n- Whether or not your service can store confidential information (i.e., a client secret)\n\nTo figure out your ideal account linking type, follow these steps:\n\n1. Consider the questions in the [Identify your preferred sign-in type](#identify_your_preferred_sign-in_type) section.\n2. Consult the decision tree to choose your linking type.\n3. Navigate to the section that corresponds to the initial type you chose to further refine how it works.\n\nIdentify your preferred sign-in type\n------------------------------------\n\nBefore you consult the decision tree, consider the following questions:\n\n- **Do you expect all your users to have a Google account?**\n - If your Action only targets the Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond the Assistant, you cannot expect all your users to have a Google account.\n - If your service already has existing users, it's likely that some don't have a Google account or didn't sign into your service with a Google account.\n- **If you have an OAuth implementation, can it be extended to support Google\n protocol?**\n - To support Google protocol, you need to be able to add the `intent=get` and `intent=create` functionality to your token exchange endpoint. This functionality allows Google to check if the user already exists in your backend and make a request to create a new account on your service, respectively.\n\nFollow the decision tree below to identify the account linking type that's\noptimal for you and your users:\n\nOnce you select a linking type, continue to the corresponding section\nbelow to learn more about how it works and make further decisions about how\naccount linking works in your Action.\n\n### OAuth and Google Sign-In\n\nThe OAuth and Google Sign-In (GSI) linking type adds GSI on top of OAuth-based\naccount linking, which provides the benefits of GSI (for example, voice-based\nlinking for Google users) while also enabling account linking for users who\nregistered to your service with a non-Google account. This linking type is\nespecially advantageous for end users because it provides a low-friction flow\nfor Google users with a fallback for non-Google users. For more information\nabout how the OAuth and GSI linking type works, see the\n[OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n#### Refine the OAuth and Google Sign-In linking type\n\nWhen you use the OAuth and GSI account linking type in your Action, you specify\nthe answers to the following questions in the Actions console to define how\nit works:\n\n1. **Do you want to enable voice account creation or only allow account\n creation on your website?**\n\n Generally, you should enable account creation via voice so that\n users on a non-screened device can create an account without having to\n transfer to another device. If you do not allow account creation via voice, the\n Assistant opens the URL to the web site that you provided for user\n authentication and directs the user to a phone to continue the account\n linking flow.\n\n However, you should not allow account creation via voice if any of the\n following applies:\n 1. *You need full control of the account creation flow.* For example, you may need to show your terms of service to the user during account creation or some other type of notice.\n 2. *You want to ensure that users who already have an account with you\n sign in with that account.* For example, you may want users to continue using their existing accounts if you offer a loyalty program and don't want the user to lose the points accrued on their account.\n2. **Do you want to use the authorization code flow or implicit flow?**\n\n The authorization code flow and implicit flow differ in that the\n authorization code flow requires a second endpoint, the *token exchange*\n endpoint. This endpoint uses *refresh tokens* to generate new, short-lived\n access tokens without prompting the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth and Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs).\n\nAfter considering these decision points, consult the following decision tree:\n\n### Google Sign-In\n\nWith the GSI linking type, your Action can request access to your user's Google\nprofile during a conversation and use the profile information to check if the\nuser exists in your service's backend. If the user doesn't exist, they can\ncreate a new account in your system using their Google profile information.\n\nFor GSI, you must enable account creation via voice, which lets the user\ncomplete the entire flow over voice. For more information about GSI, see the\n[Google Sign-In concept guide](/assistant/df-asdk/identity/gsi-concept-guide).\n\n### OAuth\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2 flow.\nThe OAuth linking type supports two industry-standard OAuth 2.0 flows:\nthe *implicit* and *authorization* code flows.\n\nGoogle does not recommend the OAuth linking type by itself because it requires transferring\nthe user from voice to screen to complete the sign-in process if the user is on\na non-screened device. You can consider using this flow if you have an existing\nimplementation of an OAuth 2 server, and you cannot extend the token exchange\nendpoint to add support for Google's protocols for automatic linking and\naccount creation from an ID token. For more information, see the\n[OAuth concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n#### Refine the flow\n\nWhen you use the OAuth account linking type in your Action, you must\nspecify the answer to the following question in the Actions console to define\nhow it works:\n\n1. **Do you want to use the authorization code flow or implicit flow?**\n\n The OAuth linking type supports two industry-standard OAuth 2.0 flows:\n the *implicit* and *authorization* code flows. The authorization code flow\n and implicit flow differ in that the authorization code flow requires a\n second endpoint, the *token exchange* endpoint. This endpoint uses\n *refresh tokens* to generate new, short-lived access tokens without prompting\n the user to sign in again.\n\n Conversely, if you use the implicit flow, you return a long-lived access\n token to Google that usually does not need to be re-generated. For more\n information about the authorization code and implicit flows, see the\n [OAuth concept guide](/assistant/df-asdk/identity/oauth-concept-guide).\n\n Google recommends using the **authorization code flow** in your Action\n because it is more secure. However, use the **implicit flow** instead if\n your service can't store confidential information (i.e., a client secret).\n For example, you must use the implicit flow for public clients like\n single-page applications (SPAs)."]]
