نوع پیوند حساب خود را انتخاب کنید (Dialogflow)
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
نوع پیوند بهینه حساب برای Action شما، نوعی است که ساده ترین تجربه را برای کاربران شما فراهم می کند و با نیازهای برنامه یا کسب و کار شما مطابقت دارد. انتخاب نوع پیوند شما بیشتر به عوامل زیر بستگی دارد:
- این که آیا می خواهید اجازه ایجاد حساب از طریق صدا را بدهید
- این که آیا می خواهید کاربران بتوانند با یک حساب غیر Google وارد سرویس شما شوند
- اینکه آیا سرویس شما می‌تواند اطلاعات محرمانه را ذخیره کند یا خیر (یعنی یک راز مشتری)
برای تعیین نوع پیوند حساب ایده آل خود، این مراحل را دنبال کنید:
- سوالات موجود در بخش Identify your preferred sign-in type را در نظر بگیرید.
- برای انتخاب نوع پیوند خود با درخت تصمیم مشورت کنید.
- به قسمتی بروید که با نوع اولیه ای که انتخاب کرده اید مطابقت دارد تا نحوه عملکرد آن را بیشتر اصلاح کنید.
نوع ورود ترجیحی خود را شناسایی کنید
قبل از مشورت با درخت تصمیم، سؤالات زیر را در نظر بگیرید:
- آیا انتظار دارید همه کاربران شما یک حساب Google داشته باشند؟
- اگر Action شما فقط Assistant را هدف قرار می دهد، می توانید انتظار داشته باشید که همه کاربران شما یک حساب Google داشته باشند. اگر Action شما پلتفرم هایی فراتر از Assistant را هدف قرار می دهد، نمی توانید انتظار داشته باشید که همه کاربران شما یک حساب Google داشته باشند.
- اگر سرویس شما قبلاً کاربران فعلی دارد، احتمالاً برخی از آنها حساب Google ندارند یا با حساب Google وارد سرویس شما نشده اند.
- اگر پیاده سازی OAuth دارید، آیا می توان آن را برای پشتیبانی از پروتکل Google گسترش داد؟
- برای پشتیبانی از پروتکل Google، باید بتوانید قابلیت
intent=get و intent=create به نقطه پایانی تبادل توکن خود اضافه کنید. این قابلیت به Google اجازه می دهد بررسی کند که آیا کاربر از قبل در باطن شما وجود دارد یا خیر و به ترتیب درخواست ایجاد یک حساب کاربری جدید در سرویس شما را بدهد.
درخت تصمیم زیر را دنبال کنید تا نوع پیوند حساب را که برای شما و کاربرانتان بهینه است شناسایی کنید:
هنگامی که یک نوع پیوند را انتخاب کردید، به بخش مربوطه در زیر ادامه دهید تا درباره نحوه عملکرد آن بیشتر بدانید و درباره نحوه عملکرد پیوند حساب در Action خود تصمیمات بیشتری بگیرید.
OAuth و Google Sign-In
نوع پیوند OAuth و Google Sign-In (GSI) GSI را به پیوند حساب مبتنی بر OAuth اضافه می کند، که مزایای GSI (به عنوان مثال، پیوند مبتنی بر صوتی برای کاربران Google) را فراهم می کند و در عین حال پیوند حساب را برای کاربرانی که ثبت نام کرده اند نیز فعال می کند. به خدمات شما با یک حساب غیر Google. این نوع پیوند مخصوصاً برای کاربران نهایی مفید است زیرا جریانی کم اصطکاک را برای کاربران Google و یک بازگشت برای کاربران غیر Google فراهم می کند. برای اطلاعات بیشتر در مورد نحوه عملکرد نوع پیوند OAuth و GSI، راهنمای مفهومی OAuth و Google Sign-In را ببینید.
نوع پیوند OAuth و Google Sign-In را اصلاح کنید
هنگامی که از نوع پیوند حساب OAuth و GSI در Action خود استفاده می کنید، پاسخ به سؤالات زیر را در کنسول Actions مشخص می کنید تا نحوه عملکرد آن را تعریف کنید:
آیا می خواهید ایجاد حساب صوتی را فعال کنید یا فقط اجازه ایجاد حساب در وب سایت خود را بدهید؟
به طور کلی، باید ایجاد حساب از طریق صدا را فعال کنید تا کاربران در یک دستگاه غیرغربال بتوانند بدون نیاز به انتقال به دستگاه دیگری یک حساب ایجاد کنند. اگر اجازه ایجاد حساب از طریق صدا را ندهید، «دستیار» URL را به وب‌سایتی که برای تأیید هویت کاربر ارائه کرده‌اید باز می‌کند و کاربر را به تلفنی هدایت می‌کند تا جریان پیوند حساب را ادامه دهد.
با این حال، در صورت وجود هر یک از موارد زیر، نباید اجازه ایجاد حساب از طریق صدا را بدهید:
- شما نیاز به کنترل کامل جریان ایجاد حساب دارید. برای مثال، ممکن است لازم باشد شرایط خدمات خود را در حین ایجاد حساب کاربری یا هر نوع اعلان دیگری به کاربر نشان دهید.
- می‌خواهید اطمینان حاصل کنید که کاربرانی که قبلاً یک حساب کاربری با شما دارند با آن حساب وارد می‌شوند. برای مثال، اگر برنامه وفاداری ارائه می‌دهید و نمی‌خواهید که کاربر امتیازهای جمع‌شده در حساب خود را از دست بدهد، ممکن است بخواهید کاربران به استفاده از حساب‌های موجود خود ادامه دهند.
آیا می خواهید از جریان کد مجوز استفاده کنید یا جریان ضمنی؟
جریان کد مجوز و جریان ضمنی از این جهت متفاوت هستند که جریان کد مجوز به یک نقطه پایانی دوم یعنی نقطه پایانی مبادله توکن نیاز دارد. این نقطه پایانی از نشانه‌های تازه‌سازی برای تولید نشانه‌های دسترسی جدید و کوتاه مدت استفاده می‌کند، بدون اینکه کاربر را وادار به ورود مجدد به سیستم کند.
برعکس، اگر از جریان ضمنی استفاده کنید، یک توکن دسترسی طولانی مدت به Google برمی‌گردانید که معمولاً نیازی به تولید مجدد ندارد. برای اطلاعات بیشتر درباره کد مجوز و جریان‌های ضمنی، به راهنمای مفهومی OAuth و Google Sign-In مراجعه کنید.
Google توصیه می‌کند از جریان کد مجوز در Action خود استفاده کنید زیرا ایمن‌تر است. با این حال، اگر سرویس شما نمی تواند اطلاعات محرمانه (به عنوان مثال، راز مشتری) را ذخیره کند، به جای آن از جریان ضمنی استفاده کنید. به عنوان مثال، شما باید از جریان ضمنی برای کلاینت های عمومی مانند برنامه های تک صفحه ای (SPA) استفاده کنید.
پس از در نظر گرفتن این نکات تصمیم گیری، به درخت تصمیم زیر مراجعه کنید:
ورود به سیستم گوگل
با نوع پیوند GSI، Action شما می‌تواند درخواست دسترسی به نمایه Google کاربر خود را در طول مکالمه کند و از اطلاعات نمایه برای بررسی وجود کاربر در باطن سرویس شما استفاده کند. اگر کاربر وجود نداشته باشد، می‌تواند با استفاده از اطلاعات نمایه Google خود یک حساب کاربری جدید در سیستم شما ایجاد کند.
برای GSI، باید ایجاد حساب از طریق صدا را فعال کنید، که به کاربر اجازه می‌دهد کل جریان را از طریق صدا تکمیل کند. برای اطلاعات بیشتر درباره GSI، راهنمای مفهومی ورود به سیستم Google را ببینید.
OAuth
با نوع پیوند OAuth، کاربر با جریان استاندارد OAuth 2 وارد سیستم می شود. نوع پیوند OAuth از دو جریان استاندارد صنعتی OAuth 2.0 پشتیبانی می کند: جریان کد ضمنی و مجوز .
Google نوع پیوند OAuth را به خودی خود توصیه نمی‌کند زیرا برای تکمیل فرآیند ورود به سیستم، اگر کاربر در دستگاهی غیرغربال‌نشده است، باید کاربر را از صدایی به صفحه دیگر منتقل کنید. اگر یک سرور OAuth 2 را اجرا می‌کنید، می‌توانید از این جریان استفاده کنید و نمی‌توانید نقطه پایانی تبادل توکن را برای افزودن پشتیبانی از پروتکل‌های Google برای پیوند خودکار و ایجاد حساب از یک نشانه ID گسترش دهید. برای اطلاعات بیشتر، راهنمای مفهومی OAuth را ببینید.
جریان را اصلاح کنید
وقتی از نوع پیوند دادن حساب OAuth در Action خود استفاده می کنید، باید پاسخ سؤال زیر را در کنسول Actions مشخص کنید تا نحوه عملکرد آن را تعریف کنید:
آیا می خواهید از جریان کد مجوز استفاده کنید یا جریان ضمنی؟
نوع پیوند OAuth از دو جریان استاندارد صنعتی OAuth 2.0 پشتیبانی می کند: جریان کد ضمنی و مجوز . جریان کد مجوز و جریان ضمنی از این جهت متفاوت هستند که جریان کد مجوز به یک نقطه پایانی دوم یعنی نقطه پایانی مبادله توکن نیاز دارد. این نقطه پایانی از نشانه‌های تازه‌سازی برای تولید نشانه‌های دسترسی جدید و کوتاه مدت استفاده می‌کند، بدون اینکه کاربر را وادار به ورود مجدد به سیستم کند.
برعکس، اگر از جریان ضمنی استفاده کنید، یک توکن دسترسی طولانی مدت به Google برمی‌گردانید که معمولاً نیازی به تولید مجدد ندارد. برای اطلاعات بیشتر در مورد کد مجوز و جریان های ضمنی، به راهنمای مفهومی OAuth مراجعه کنید.
Google توصیه می‌کند از جریان کد مجوز در Action خود استفاده کنید زیرا ایمن‌تر است. با این حال، اگر سرویس شما نمی تواند اطلاعات محرمانه (به عنوان مثال، راز مشتری) را ذخیره کند، به جای آن از جریان ضمنی استفاده کنید. به عنوان مثال، شما باید از جریان ضمنی برای کلاینت های عمومی مانند برنامه های تک صفحه ای (SPA) استفاده کنید.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده Oracle و/یا شرکتهای وابسته به آن است.
تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی.
[null,null,["تاریخ آخرین بهروزرسانی 2025-07-24 بهوقت ساعت هماهنگ جهانی."],[[["\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)."]]
