[null,null,["最后更新时间 (UTC):2025-07-25。"],[[["\u003cp\u003eOAuth linking in Google Assistant uses OAuth 2.0 for account linking, supporting both implicit and authorization code flows.\u003c/p\u003e\n"],["\u003cp\u003eImplicit flow directly returns a long-lived access token upon successful sign-in, while the authorization code flow involves an intermediary authorization code for enhanced security.\u003c/p\u003e\n"],["\u003cp\u003eAccount linking with OAuth is recommended when you have an existing OAuth 2.0 server and cannot modify its token exchange endpoint to accommodate Google's protocols.\u003c/p\u003e\n"],["\u003cp\u003eThe authorization code flow involves an authorization endpoint for user consent and a token exchange endpoint for acquiring access and refresh tokens.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Assistant provides system properties like \u003ccode\u003euser.verificationStatus\u003c/code\u003e and \u003ccode\u003euser.accountLinkingStatus\u003c/code\u003e to indicate the user's verification and linking status, respectively.\u003c/p\u003e\n"]]],["OAuth linking utilizes the implicit and authorization code flows. In the implicit flow, after user sign-in, a long-lived access token is returned to Google, included in all subsequent requests. The authorization code flow involves Google receiving a short-lived authorization code after user sign-in, which is exchanged for an access and refresh token at the token exchange endpoint. Both flows begin with the user agreeing to link accounts and granting data access permission. After these steps, each service interaction from assistant will contain an access token.\n"],null,["# OAuth linking concept guide\n\nThe *OAuth linking* type supports two industry-standard OAuth 2.0 flows:\nthe *implicit* and *authorization code* flows. In the implicit code flow, Google\nopens your authorization endpoint in the user's browser. After successful sign-in,\nyou return a long-lived access token to Google. This access token is then included\nin every request sent from Assistant to your Action.\n\nOAuth linking is the recommended account linking solution if the following applies:\n\n- You have an existing implementation of an OAuth 2.0 server, and you cannot extend your token exchange endpoint to add support for Google's protocols for automatic linking and account creation from an ID token (i.e., add the `intent=get` and `intent=create` parameters in requests to this endpoint).\n\nTo verify that OAuth linking is the right solution for you, see the\n[Choose your account linking type](/assistant/identity/choose-type) page.\n\nKey terms\n---------\n\nBefore you read about how OAuth linking works, familiarize yourself with the following terms:\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\n- **Authorization code flow:** During this OAuth 2.0 flow, Google opens your\n authorization endpoint in the user's browser. If sign-in is successful,\n your service creates an *authorization code* and returns it to Google.\n Google sends this authorization code to your token exchange endpoint, which\n verifies the authenticity of the code and returns an access token and refresh token.\n\n This flow requires two endpoints:\n - **Authorization endpoint:** The endpoint that is responsible for finding or obtaining consent from users for data access. This endpoint does the following:\n 1. Presents the sign-in UI to your users that aren't already signed in.\n 2. Records consent to the requested access in the form of a short-lived authorization code.\n - **Token exchange endpoint:** This endpoint is used to obtain encrypted strings called *tokens* that authorize the Action user to access your service. This endpoint is responsible for two types of exchanges:\n 1. Exchanges an authorization code for a long-lived refresh token and a short-lived access token. This exchange happens when the user goes through the account linking flow.\n 2. Exchanges a long-lived refresh token for a short-lived access token. This exchange happens when Google needs a new access token because the one it had expired.\n- **Implicit code flow:** During this OAuth 2.0 flow, Google opens your authorization\n endpoint in the user's browser. If sign-in is successful, you return a\n long-lived access token to Google. This access token is then included in\n every request sent from Assistant to your Action. This flow requires\n only an authorization endpoint.\n\n- **Access token:** A token that authorizes your service to access parts of\n a user's data. Access tokens are associated with each individual user\n and should be unguessable.\n\n- **Refresh token:** A token that is exchanged for a new access token once a\n short-lived access token has expired.\n\nHow it works\n------------\n\nThis section describes the general flow for the OAuth authorization code and\nimplicit flows. The following section, [OAuth linking flows](#oauth_linking_flows),\ndescribes the various flows that can occur with OAuth.\n\nThe authorization code flow can be summarized as follows:\n\n1. Your Action asks the user if they want to link their account with your service.\n2. After the user agrees to link accounts, Google opens your authorization endpoint in the user's browser. If the flow started on a voice-only device for an Action, Google would transfer the execution to a phone.\n3. The user signs in (if not signed in already) and grants Google permission to access their data with your API (if they haven't already granted permission).\n4. Your service creates an *authorization code* and returns it to Google by redirecting the user's browser back to Google with the authorization code attached to the request.\n5. Google sends the authorization code to your token exchange endpoint, which verifies the authenticity of the code and returns an *access token* and a *refresh token*. The access token is a short-lived token that your service accepts as credentials to access APIs. The refresh token is a long-lived token that Google can store and use to acquire new access tokens when they expire.\n6. After the user has completed the account linking flow, every subsequent request sent from Assistant to your fulfillment webhook contains an access token.\n\nThe implicit code flow can be summarized as follows:\n\n1. Your Action asks the user if they want to link their account with your service.\n2. After the user agrees to link accounts, Google opens your authorization endpoint in the user's browser.\n3. The user signs in (if not signed in already) and grants Google permission to access their data with your API (if they haven't already granted permission).\n4. Your service creates an access token and returns it to Google by redirecting the user's browser back to Google with the access token attached to the request.\n5. After the user has completed the account linking flow, Google calls your service's APIs and attaches the access token with each request. Your service verifies that the access token grants Google authorization to access the API and then completes the API call.\n\nThe fundamental authorization code flow is as follows:\n\n1. Your Action asks the user if they want to link their account with your service.\n2. After the user agrees to link accounts, Google opens your authorization endpoint in the user's browser. If the flow started on a voice-only device for an Action, Google would transfer the execution to a phone.\n3. The user signs in (if not signed in already) and grants Google permission to access their data with your API (if they haven't already granted permission).\n4. Your service creates an *authorization code* and returns it to Google by redirecting the user's browser back to Google with the short-lived authorization code attached to the request.\n5. Google sends the authorization code to your token exchange endpoint, which verifies the authenticity of the code and returns an *access token* and a *refresh token*. The access token is a short-lived token that your service accepts as credentials to access APIs. The refresh token is a long-lived token that Google can store and use to acquire new access tokens when they expire.\n6. After the user has completed the account linking flow, every subsequent request sent from Assistant to your fulfillment webhook contains an access token.\n\nOAuth linking flows\n-------------------\n\nThis section goes over the various flows that can occur with OAuth linking.\n| **Note:** The following flows assume the user agrees to link their account with your service and grant Google permission to access their data with your API. 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\nEach flow contains these common steps after the user invokes your Action:\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 the flow above, you transition to the account linking system scene and provide\na customized rationale. Assistant asks the user if they want to link\ntheir account with your service and shows them a screen with the requested\npermissions. When the user consents, Google then redirects the user to your\nservice's authorization endpoint in the browser. The user signs in (or,\ndepending on your configuration, creates a new account) and grants your Action\npermission to access their data.\n\nThe flows after this point differ based on whether or not you implemented\nthe implicit flow or authorization code flow. These flows are described in\nthe following sections.\n\n### Flow 1: User signs in with implicit flow\n\n| **Note:** This diagram builds off of the **Common steps** diagram above.\n\nAfter the user logs in and their credentials are verified, your service creates\na long-lived access token and returns it to Google. At this point, the user's\nidentity in your Action is linked to the account they signed in with, and the\naccess token is attached to each API call Google makes to your service's APIs.\n\n### Flow 2: User signs in with authorization code flow\n\n| **Note:** This diagram builds off of the **Common steps** diagram above.\n\nAfter the user logs in and their credentials are verified, your service creates\nan authorization code and returns it to Google.\n\nThis authorization code is sent to your token exchange endpoint, which returns\nboth an access token and a refresh token. At this point, the user's identity\nin your Action is linked to whatever account they signed in with, and every\nsubsequent request sent from Assistant to your fulfillment contains an\naccess token."]]