คุณยังไม่ได้ใช้ระบบการตรวจสอบสิทธิ์ และ/หรือคุณต้อง
เพื่อให้มีบัญชี Google ตัวอย่างเช่น หากการดำเนินการของคุณเจาะจง
คุณคาดหวังได้ว่าผู้ใช้ทุกคนจะมี Google
บัญชี
คุณมีระบบการตรวจสอบสิทธิ์อยู่แล้ว และต้องการลิงก์เฉพาะผู้ใช้ที่
ลงชื่อเข้าใช้ระบบของคุณโดยใช้บัญชี Google ของเขา
โทเค็นรหัส Google: การยืนยันที่ลงนามสำหรับข้อมูลประจำตัวของผู้ใช้ที่มี
ข้อมูลโปรไฟล์ Google พื้นฐานของผู้ใช้ (ชื่อ ที่อยู่อีเมล และ
รูปโปรไฟล์) โทเค็นรหัส Google คือ
เว็บโทเค็น JSON
(JWT)
ต่อไปนี้เป็นตัวอย่างของโทเค็นที่ถอดรหัส
{"sub":1234567890,// The unique ID of the user's Google Account"iss":"https://accounts.google.com",// The token's issuer"aud":"123-abc.apps.googleusercontent.com",// Client ID assigned to your Actions project"iat":233366400,// Unix timestamp of the token's creation time"exp":233370000,// Unix timestamp of the token's expiration time"name":"Jan Jansen","given_name":"Jan","family_name":"Jansen","email":"jan@gmail.com",// If present, the user's email address"locale":"en_US"}
ฉากของระบบการลิงก์บัญชี: ฉากที่กำหนดไว้ล่วงหน้าซึ่งใช้การยืนยัน
สำหรับการลิงก์บัญชี และสามารถปรับแต่งให้เหมาะกับ Use Case ที่เฉพาะเจาะจงได้
วิธีการทำงาน
ขั้นตอนพื้นฐานสำหรับ GSI มีดังนี้
การดำเนินการของคุณขอความยินยอมจากผู้ใช้เพื่อเข้าถึงโปรไฟล์ Google
หลังจากผู้ใช้ให้ความยินยอม การดำเนินการของคุณจะได้รับโทเค็น Google ID ที่
มีข้อมูลโปรไฟล์ Google ของผู้ใช้
ตรวจสอบและถอดรหัสโทเค็นเพื่ออ่านเนื้อหาโปรไฟล์ หากคุณใช้แท็ก
ไลบรารี Actions on Google Fulfillment สำหรับ Node.js
โมเดลจะตรวจสอบและถอดรหัสโทเค็นให้คุณ
การดำเนินการของคุณใช้โทเค็นนี้เพื่อตรวจสอบว่าโปรไฟล์ Google ของผู้ใช้หรือไม่
ข้อมูลที่มีอยู่ในระบบของคุณ
หากมี แสดงว่าผู้ใช้ได้ลงชื่อเข้าใช้ระบบของคุณด้วย
บัญชี Google ผู้ใช้สามารถสนทนาต่อกับ
Assistant ที่มีข้อมูลประจำตัวที่ลิงก์กับบัญชี Google
หากไม่ได้เปิดใช้ ผู้ใช้สามารถสร้างบัญชีใหม่ในระบบโดยใช้
ข้อมูลที่อยู่ในโทเค็น Google ID จากนั้นผู้ใช้สามารถ
สนทนาต่อกับ Assistant ด้วยการลิงก์บัญชีใหม่
ขั้นตอนการลงชื่อเข้าใช้ Google
ส่วนนี้จะอธิบายขั้นตอนต่างๆ ที่อาจเกิดขึ้นกับ Google Sign-In
[null,null,["อัปเดตล่าสุด 2025-07-25 UTC"],[[["\u003cp\u003eGoogle Sign-In (GSI) offers a seamless account linking experience for users on Google Assistant, simplifying developer implementation by allowing Actions to request and utilize user profile data upon consent.\u003c/p\u003e\n"],["\u003cp\u003eGSI is recommended if you lack an existing authentication system, expect all users to have Google accounts, or aim to link users who have signed into your system using their Google accounts.\u003c/p\u003e\n"],["\u003cp\u003eThe GSI process involves obtaining user consent, receiving a Google ID token with user profile information, validating and decoding the token, and checking if the user's Google profile information exists in your system, prompting account creation if necessary.\u003c/p\u003e\n"],["\u003cp\u003eIf the user's information is found in your system, their identity is automatically linked; if not, they can create a new account within the Action using the Google ID token data.\u003c/p\u003e\n"],["\u003cp\u003eGSI streamlines account linking by potentially eliminating the need for separate logins and passwords, allowing users to leverage their existing Google accounts for a smoother experience within your Action.\u003c/p\u003e\n"]]],[],null,["Google Sign-In (GSI) for Assistant provides the most seamless linking\nexperience for users and is the easiest flow for developers to implement.\nWith GSI, your Action can request access to your user's Google profile during\na conversation and, if the user consents, receive the user's name, email address,\nand profile picture. Your Action can then use this information to check if the\nuser has a Google account in your system. If not, your Action asks the user if\nthey want to create a new account in your system based on their Google\nprofile information.\n| **Note:** Your user is either a) identified through voice recognition or b) configured on the device. If the user's voice is verified but not recognized, the user is considered a guest.\n\nGSI is the recommended account linking solution if any of the following applies:\n\n- You don't have an existing authentication system and/or you expect all your users to have a Google account. For example, if your Action is specifically targeting Assistant, you can expect all your users to have Google accounts.\n- You have an existing authentication system and only want to link users who signed into your system using their Google accounts.\n\nTo verify that GSI is the right solution for you, see the\n[Choose your account linking type](/assistant/identity/choose-type) page.\n\nKey terms\n\nBefore you read about how GSI works, familiarize yourself with the following terms:\n\n- **Google ID token:** A signed assertion of a user's identity that contains\n a user's basic Google profile information (their name, email address, and\n profile picture). A Google ID token is a\n [JSON Web Token](https://en.wikipedia.org/wiki/JSON_Web_Token)\n (JWT).\n\n The following is an example of a decoded token:\n\n```carbon\n{\n \"sub\": 1234567890, // The unique ID of the user's Google Account\n \"iss\": \"https://accounts.google.com\", // The token's issuer\n \"aud\": \"123-abc.apps.googleusercontent.com\", // Client ID assigned to your Actions project\n \"iat\": 233366400, // Unix timestamp of the token's creation time\n \"exp\": 233370000, // Unix timestamp of the token's expiration time\n \"name\": \"Jan Jansen\",\n \"given_name\": \"Jan\",\n \"family_name\": \"Jansen\",\n \"email\": \"jan@gmail.com\", // If present, the user's email address\n \"locale\": \"en_US\"\n}\n```\n\n- **`user.verificationStatus`:** A property set by the system to indicate if the\n current session has a verified user.\n\n- **`user.accountLinkingStatus`:** A property set by the system to indicate if the\n user in the current session has a linked identity.\n\n- **Account linking system scene:** A predefined scene that implements the confirmation\n flow for account linking, and can be customized to fit specific use cases.\n\nHow it works\n\nThe fundamental flow for GSI is as follows:\n\n1. Your Action asks the user for consent to access their Google profile.\n2. After the user gives consent, your Action receives a Google ID token that contains the user's Google profile information.\n3. Validate and decode the token to read the profile content. If you use the Actions on Google Fulfillment library for Node.js, it validates and decodes the token for you.\n4. Your Action uses this token to check if the user's Google profile\n information exists in your system.\n\n 1. If it does, the user has already signed into your system with their Google account. The user can continue the conversation with Assistant with their identity linked to their Google account.\n 2. If it doesn't, the user can create a new account in your system with\n the information contained in the Google ID token. The user can then\n continue the conversation with Assistant with their new account linked.\n\n | **Note:** New accounts do not typically have a password set. It is recommended that you add Google Sign In to other platforms to enable users to log in via Google across the surfaces of your application. Alternatively, you can email the user a link that starts your password recovery flow to allow the user to set a password for signing in on other platforms.\n\nGoogle Sign-in flows\n\nThis section describes the various flows that can occur with Google Sign-in.\n| **Note:** The following flows assume the user gives consent for your Action to access their Google profile information. If a user doesn't give consent, provide them a way to continue in your Action with an alternate, limited flow. For more information, see [Best practices](/assistant/identity/best-practices).\n\nFlow 1: User's information exists in your system\n\nThe following diagram shows the end-to-end flow that occurs with GSI when the\nuser's information already exists in your system:\n\n| **Note:** A line from *Webhook* to *User* represents a [simple response](/assistant/conversational/prompts-simple) that you create and customize. Lines drawn from *Assistant* to *User* represent prompts that are owned by Assistant and have limited options for customization (requests that require permission are always owned by Assistant). From the user's perspective, both kinds of responses are delivered from Assistant.\n\nIn this case, you transition to the account linking system scene and provide\na customized rationale. This scene asks the user for permission to\naccess their Google profile information.\n\nAfter the user consents, Assistant sends a request that contains the\nprofile information for `user@gmail.com`. In this case, the information\ncontained in the Google ID token for `user@gmail.com` matches an account in\nyour system, so the user's identity in your Action is automatically linked\nto that account. Your webhook can then read the user's usual order from\na database and respond accordingly.\n\nFlow 2: User's information does not exist in your system\n\nThe following diagram shows the end-to-end flow that occurs with GSI when\nthe user's information does not exist in your system:\n\nIn this case, the information contained in the Google ID token for\n`user@gmail.com` does not match an account in your system, so Assistant\nasks the user if they'd like to create a new account. The user can complete\nthe account creation process with voice rather than transferring to\na screened device.\n\nWhen the user agrees to create an account, your service uses the information\nin the ID token (the user's name and email address) to create an account for\nthe user. Once the account is created, the user's identity in your Action\nis linked to their new Google account.\n\nIn this case, the user does not have a usual order because they are new to\nthe service, so your Action asks what they want to order. You\ncan also ask the user if they'd like to set their most recent order\nas their usual order."]]
