Chọn loại liên kết tài khoản
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Loại liên kết tài khoản tối ưu cho Hành động của bạn là loại liên kết mang lại trải nghiệm đơn giản nhất cho người dùng và phù hợp với nhu cầu của ứng dụng hoặc doanh nghiệp. Việc chọn loại liên kết chủ yếu phụ thuộc vào các yếu tố sau:
- Bạn có muốn cho phép tạo tài khoản qua giọng nói hay không
- Bạn có muốn người dùng có thể đăng nhập vào dịch vụ của bạn bằng
tài khoản không phải của Google hay không
- Dịch vụ của bạn có thể lưu trữ thông tin mật hay không (ví dụ: mật khẩu ứng dụng khách)
Để xác định loại liên kết tài khoản lý tưởng, hãy làm theo các bước sau:
- Hãy cân nhắc các câu hỏi trong phần Xác định loại thông tin đăng nhập ưu tiên.
- Tham khảo cây quyết định để chọn loại liên kết.
- Di chuyển đến phần tương ứng với loại ban đầu mà bạn đã chọn để tinh chỉnh thêm cách hoạt động.
Xác định kiểu đăng nhập bạn ưu tiên
Trước khi bạn tham khảo cây quyết định, hãy cân nhắc các câu hỏi sau:
- Bạn có muốn tất cả người dùng của mình đều có Tài khoản Google không?
- Nếu Hành động của bạn chỉ nhắm đến Trợ lý, thì bạn có thể yêu cầu tất cả người dùng đều có Tài khoản Google. Nếu Hành động của bạn nhắm đến các nền tảng ngoài Trợ lý, thì bạn không thể kỳ vọng tất cả người dùng đều có Tài khoản Google.
- Nếu dịch vụ của bạn đã có người dùng hiện tại, thì có thể một số người chưa có Tài khoản Google hoặc chưa đăng nhập vào dịch vụ của bạn bằng Tài khoản Google.
- Nếu triển khai OAuth, bạn có thể mở rộng phạm vi triển khai để hỗ trợ giao thức Google
không?
- Để hỗ trợ giao thức Google, bạn cần thêm chức năng
intent=get và intent=create vào điểm cuối trao đổi mã thông báo. Chức năng này cho phép Google kiểm tra xem người dùng đã tồn tại trong phần phụ trợ hay chưa và lần lượt đưa ra yêu cầu tạo một tài khoản mới trên dịch vụ của bạn.
Hãy theo dõi cây quyết định dưới đây để xác định loại liên kết tài khoản phù hợp nhất cho bạn và người dùng của bạn:
Sau khi chọn một loại hình liên kết, hãy tiếp tục chuyển đến phần tương ứng ở bên dưới để tìm hiểu thêm về cách hoạt động của loại hình đó và đưa ra quyết định khác về cách hoạt động của việc liên kết tài khoản trong Hành động của bạn.
Liên kết "Đơn giản hoá" trong tính năng Đăng nhập bằng Google dựa trên OAuth
Loại liên kết Đơn giản hoá này bổ sung tính năng Đăng nhập bằng Google (GSI) ngoài tính năng liên kết tài khoản dựa trên OAuth, mang lại các lợi ích của GSI (ví dụ: liên kết dựa trên giọng nói cho người dùng Google), đồng thời cho phép liên kết tài khoản đối với những người dùng đã đăng ký dịch vụ của bạn bằng Tài khoản không phải của Google. Loại liên kết này đặc biệt có lợi cho người dùng cuối vì nó cung cấp một luồng nhanh chóng cho người dùng Google với tính năng dự phòng cho người dùng không phải người dùng Google. Để biết thêm thông tin về cách hoạt động của Đường liên kết được tinh giản, hãy xem Hướng dẫn về khái niệm liên kết "Đơn giản hoá" liên kết với tính năng Đăng nhập bằng Google dựa trên OAuth.
Tinh chỉnh loại liên kết "Đơn giản hoá" đăng nhập bằng Google để đăng nhập bằng OAuth
Khi sử dụng loại liên kết Đơn giản hoá trong Hành động của mình, bạn chỉ định câu trả lời cho các câu hỏi sau trong bảng điều khiển Actions để xác định cách hoạt động:
Bạn muốn bật tính năng tạo tài khoản bằng giọng nói hay chỉ cho phép tạo tài khoản trên trang web của mình?
Nhìn chung, bạn nên bật tính năng tạo tài khoản qua giọng nói để người dùng trên một thiết bị không được sàng lọc có thể tạo tài khoản mà không phải chuyển sang một thiết bị khác. Nếu bạn không cho phép tạo tài khoản thông qua giọng nói, Trợ lý sẽ mở URL đến trang web mà bạn đã cung cấp để xác thực người dùng, rồi chuyển hướng người dùng đến điện thoại để tiếp tục quy trình liên kết tài khoản.
Tuy nhiên, bạn không nên cho phép tạo tài khoản thông qua giọng nói nếu thuộc một trong những trường hợp sau đây:
- Bạn cần có toàn quyền kiểm soát quy trình tạo tài khoản. Ví dụ: bạn có thể cần hiển thị điều khoản dịch vụ của mình cho người dùng trong quá trình tạo tài khoản hoặc một số loại thông báo khác.
- Bạn muốn đảm bảo rằng những người dùng đã có tài khoản của bạn sẽ đăng nhập bằng tài khoản đó. Ví dụ: có thể bạn muốn người dùng tiếp tục
sử dụng các tài khoản hiện có của họ nếu bạn cung cấp một chương trình khách hàng thân thiết và không
muốn người dùng mất số điểm đã tích luỹ trên tài khoản của họ.
Bạn muốn sử dụng quy trình mã uỷ quyền hay quy trình ngầm ẩn?
Quy trình mã uỷ quyền và quy trình ngầm ẩn khác nhau ở chỗ quy trình mã uỷ quyền yêu cầu có một điểm cuối thứ hai là điểm cuối trao đổi mã thông báo. Điểm cuối này sử dụng mã làm mới để tạo mã truy cập mới, ngắn hạn mà không cần nhắc người dùng đăng nhập lại.
Ngược lại, nếu sử dụng luồng ngầm ẩn, bạn sẽ trả về một mã truy cập dài hạn cho Google mà thường không cần được tạo lại. Để biết thêm thông tin về mã uỷ quyền và quy trình ngầm ẩn, hãy xem Hướng dẫn về khái niệm liên kết tính năng Đăng nhập bằng Google dựa trên OAuth.
Bạn nên sử dụng quy trình mã uỷ quyền trong Hành động của mình vì cách này an toàn hơn. Tuy nhiên, hãy sử dụng luồng ngầm ẩn thay thế nếu dịch vụ của bạn không thể lưu trữ thông tin bảo mật (ví dụ: mật khẩu ứng dụng khách).
Ví dụ: bạn phải sử dụng luồng ngầm ẩn cho các ứng dụng công khai như
ứng dụng trang đơn (SPA).
Sau khi xem xét những điểm quyết định này, hãy tham khảo cây quyết định sau:
Đăng nhập bằng Google
Với loại liên kết Đăng nhập bằng Google (GSI), Hành động của bạn có thể yêu cầu quyền truy cập vào hồ sơ Google của người dùng trong khi trò chuyện và dùng thông tin hồ sơ để kiểm tra xem người dùng có trong phần phụ trợ của dịch vụ hay không. Nếu người dùng không tồn tại, họ có thể tạo một tài khoản mới trong hệ thống của bạn bằng cách sử dụng thông tin hồ sơ trên Google của họ.
Đối với GSI, bạn phải bật tính năng tạo tài khoản qua giọng nói để người dùng có thể hoàn tất toàn bộ quy trình qua giọng nói. Để biết thêm thông tin về GSI, hãy xem Hướng dẫn về khái niệm liên quan đến tính năng Đăng nhập bằng Google.
Liên kết OAuth
Với loại liên kết OAuth, người dùng đăng nhập theo quy trình OAuth 2.0 tiêu chuẩn.
Loại liên kết OAuth hỗ trợ 2 quy trình OAuth 2.0 tiêu chuẩn ngành:
quy trình mã ngầm ẩn và uỷ quyền.
Google không đề xuất loại liên kết OAuth vì loại này yêu cầu chuyển người dùng từ giọng nói sang màn hình để hoàn tất quy trình đăng nhập nếu người dùng đang sử dụng một thiết bị không được sàng lọc. Bạn có thể cân nhắc sử dụng quy trình này nếu đã triển khai máy chủ OAuth 2.0 hiện tại, đồng thời không thể mở rộng điểm cuối trao đổi mã thông báo để thêm tính năng hỗ trợ cho các giao thức của Google nhằm tự động liên kết và tạo tài khoản từ mã thông báo nhận dạng. Để biết thêm thông tin, hãy xem bài viết Hướng dẫn về khái niệm liên kết OAuth.
Tinh chỉnh quy trình
Khi sử dụng loại liên kết OAuth trong Hành động của mình, bạn phải chỉ định câu trả lời cho câu hỏi sau trong bảng điều khiển Actions để xác định cách hoạt động của hành động đó:
Bạn muốn sử dụng quy trình mã uỷ quyền hay quy trình ngầm ẩn?
Loại liên kết OAuth hỗ trợ 2 quy trình OAuth 2.0 tiêu chuẩn ngành:
quy trình mã ngầm ẩn và uỷ quyền. Quy trình mã uỷ quyền và luồng ngầm ẩn khác nhau ở chỗ quy trình mã uỷ quyền yêu cầu một điểm cuối thứ hai là điểm cuối trao đổi mã thông báo. Điểm cuối này sử dụng mã làm mới để tạo mã truy cập mới, ngắn hạn mà không cần nhắc người dùng đăng nhập lại.
Ngược lại, nếu sử dụng luồng ngầm ẩn, bạn sẽ trả về một mã truy cập dài hạn cho Google mà thường không cần được tạo lại. Để biết thêm thông tin về mã uỷ quyền và quy trình ngầm ẩn, hãy xem bài viết Hướng dẫn về khái niệm liên kết OAuth.
Bạn nên sử dụng quy trình mã uỷ quyền trong Hành động của mình vì cách này an toàn hơn. Tuy nhiên, hãy sử dụng luồng ngầm ẩn thay thế nếu dịch vụ của bạn không thể lưu trữ thông tin bảo mật (ví dụ: mật khẩu ứng dụng khách).
Ví dụ: bạn phải sử dụng luồng ngầm ẩn cho các ứng dụng công khai như
ứng dụng trang đơn (SPA).
Trừ phi có lưu ý khác, nội dung của trang này được cấp phép theo Giấy phép ghi nhận tác giả 4.0 của Creative Commons và các mẫu mã lập trình được cấp phép theo Giấy phép Apache 2.0. Để biết thông tin chi tiết, vui lòng tham khảo Chính sách trang web của Google Developers. Java là nhãn hiệu đã đăng ký của Oracle và/hoặc các đơn vị liên kết với Oracle.
Cập nhật lần gần đây nhất: 2025-07-25 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-07-25 UTC."],[[["\u003cp\u003eThe optimal account linking type for your Google Action depends on user experience, whether you allow voice account creation, accept non-Google accounts, and if your service can handle confidential information.\u003c/p\u003e\n"],["\u003cp\u003eA decision tree helps you determine the best account linking type: OAuth-based Google Sign-in "Streamlined", Google Sign-in, or standard OAuth linking.\u003c/p\u003e\n"],["\u003cp\u003eStreamlined linking combines Google Sign-in benefits with support for non-Google accounts, offering flexibility and a smooth user experience.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Sign-in allows voice account creation and leverages users' Google profiles but may not be ideal if you require extensive control over the account creation process.\u003c/p\u003e\n"],["\u003cp\u003eStandard OAuth linking, while functional, might necessitate switching between voice and screen, potentially hindering user experience.\u003c/p\u003e\n"]]],["Account linking type selection depends on voice account creation, non-Google sign-in, and secure storage capabilities. To choose, consider if users have Google accounts and if existing OAuth can support Google protocol. Streamlined linking combines Google Sign-In (GSI) with OAuth, offering voice account creation unless full control or existing account sign-in is required. Authorization code flow is preferred for security unless a service can't store confidential information, in which case the implicit flow is necessary. GSI requires voice account creation. OAuth linking by itself isn't recommended.\n"],null,["# Choose your account linking type\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 Assistant, then you can expect all your users to have a Google account. If your Action targets platforms beyond 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-based Google Sign-in \"Streamlined\" linking\n\nThe Streamlined linking type adds Google Sign-in (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 Streamlined linking works, see the\n[OAuth-based Google Sign-in \"Streamlined\" linking concept guide](/assistant/identity/gsi-oauth-concept-guide).\n\n#### Refine OAuth-based Google Sign-in \"Streamlined\" linking type\n\nWhen you use the Streamlined 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,\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-based Google Sign-In \"Streamlined\" linking concept guide](/assistant/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 Google Sign-in (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/identity/gsi-concept-guide).\n\n### OAuth linking\n\nWith the OAuth linking type, the user signs in with the standard OAuth 2.0 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.0 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 linking concept guide](/assistant/identity/oauth-concept-guide).\n\n#### Refine the flow\n\nWhen you use the OAuth 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 linking concept guide](/assistant/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)."]]
