如果您的网站需要同时调用身份验证 API 和授权 API，您需要在不同时刻分别调用它们。在身份验证时，您的网站可以与一键式登录、自动登录和“使用 Google 账号登录”按钮集成，以便用户登录或注册您的网站。稍后，当需要从 Google 访问数据时，您可以调用授权 API 来请求用户同意并获取用于数据访问的访问令牌。这种分离符合我们建议的增量授权最佳实践，在这种应用中请求权限。
为了强制执行这种分离，Authentication API 只能返回用于登录您网站的 ID 令牌，而 Authorization API 只能返回仅用于数据访问而不登录的代码或访问令牌。
[null,null,["最后更新时间 (UTC)：2025-04-28。"],[],[],null,["Sign in with Google helps you to quickly manage user authentication on your\nwebsite. Users sign into a Google Account, provide their consent, and securely\nshare their profile information with your platform.\n\nCustomizable buttons and multiple flows are supported for user sign-up and\nsign-in.\n\nSign-up refers to the steps to obtain a Google Account holder's consent to share\ntheir profile information with your platform. Typically, a new account is\ncreated on your site using this shared data, but this is not a requirement.\n\nSign-in refers to logging users into your website using their active Google\nAccount with a [personalized sign-in button](/identity/gsi/web/guides/personalized-button) or [One Tap](/identity/gsi/web/guides/display-google-one-tap) and\n[Automatic sign-in](/identity/gsi/web/guides/automatic-sign-in-sign-out) for users already logged in to their Google Account.\n\nSee the [Case Studies](/identity/sign-in/case-studies) for some success stories\nof Sign In With Google integrations.\n\nYou can also use the [Google Identity Services authorization API](/identity/oauth2/web/guides/overview), which lets\nyou obtain an access token for use with Google APIs, or to access user data.\n\nUser privacy\n\nData from Sign in with Google is not used for ads or other non-security\npurposes.\n\nUse cases\n\nSome of the reasons to add Sign in with Google to your site are:\n\n- Add a visibly trusted and secure Sign in with Google button to an account creation or settings page.\n- Pre-populate new accounts with consensually shared data from a Google Account profile.\n- Users can sign in once to a Google Account without re-entering usernames or passwords on other sites.\n- On return visits, users can sign in automatically or with one click across an entire site.\n- Use verified Google Accounts to protect comments, voting or forms from abuse, while allowing anonymity.\n\nSupported features\n\nThese features are supported by Sign in with Google:\n\n- Sign up, to optionally create a new account auto-filled from a Google Account profile.\n- Sign in, using an account chooser to select from multiple accounts.\n- Sign in with one tap, if you've already signed in to your Google Account.\n- Sign in automatically, on return visits using your computer, phone or even multiple browser tabs.\n- Sign out, to disable automatic sign-in across all your devices.\n\nNote how account states may affect Sign in with Google:\n\n- Suspending your Google Account stops sign in to all sites using Sign in with Google.\n- Deleting your Google or partner account affects one, but not the other.\n\nCompare to OAuth and OpenId Connect\n\nOAuth and OpenId Connect are open standards that offer a wide range of\nconfigurable options to fine-tune the behavior of authentication and\nauthorization flows. Refer to Google's\n[OAuth documentation](/identity/protocols/oauth2) for more details.\n\nSign in with Google offers a single SDK to encompass several related offerings\nincluding a personalized button, One Tap, Automatic sign-in, and authorization.\nIt aims to offer an easier and more secure experience for developers than the\nstandard OAuth and OpenID Connect protocols, while providing a more seamless\nuser experience.\n\n- Sign in with Google is based on OAuth 2.0. The permissions that users granted through Sign in with Google are the same as those that they grant for OAuth, and the other way around.\n- OAuth 2.0 is also the industry-standard protocol for authorization. It provides for a set of endpoints with which relying parties integrate using HTTP.\n- Google Identity Services (GIS) APIs are available in several languages including JavaScript and HTML, that provide for both authentication and authorization.\n- GIS separates the authentication moment from the authorization moment. In the authentication moment, a quick integration can be achieved by just integrating some UI elements into your website, such as the personalized button, One Tap, and automatic sign-in. These UI elements provide a consistent authentication UX across all third party websites. In the authorization moment, GIS triggers OAuth flows to return tokens for data access on behalf of the user.\n- GIS authentication makes integration with relying parties easier, and reduces most of the OAuth and security knowledge burden on developers. You don't need to choose from various approaches to obtain access tokens or authorization code, or risk the consequences of choosing the wrong approach. While the OAuth 2.0 protocol exposes many details such as the request and response parameters of the HTTP endpoints, GIS handles these implementation details for you. Also, GIS includes some security implementations for Cross-Site Request Forgery (CSRF) protection by default.\n- With the HTML API and [Code Generator](/identity/gsi/web/tools/configurator), the GIS authentication lowers the bar for relying parties integration even further. You don't need a JavaScript developer to generate the code. This reduces the level of OAuth experience required as well as time to implement.\n- The GIS authorization UX is fully based on OAuth UX. However, the GIS JavaScript library adds some restrictions for easier and safer relying party integration.\n- GIS also provides some features beyond the OAuth protocol. For example, it integrates [Password Credential Manager API](/identity/gsi/web/guides/display-browsers-native-credential-manager) and [Federated Credential Manager API](/identity/gsi/web/guides/supported-browsers#third-party_cookies).\n\nWith Google Identity Services, developers can use a dedicated and integrated\nservice to help their users to sign in to the developer's website and apps with\nwhatever login credentials the user chooses. The mission of GIS is to support\nand streamline the UX for multiple types of credentials, to lower the technical\nbar for the relying party integration.\n\nFederated Credential Manager (FedCM)\n\nAs part of the [Privacy Sandbox](https://privacysandbox.com/intl/en_us/) initiative, Chrome is\n[phasing out support for third-party cookies](https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline). GIS [integrates](https://developers.googleblog.com/2024/02/federated-credential-management-migration-for-google-identity-services.html) the\n[FedCM API](/identity/gsi/web/guides/supported-browsers#third-party_cookies), which is a new privacy-preserving alternative to third-party\ncookies for federated identity providers. GIS begins a migration of all websites\nto FedCM on the Chrome browser in April 2024.\n| **Key Point:** For new web apps, you should always [enable FedCM](/identity/gsi/web/reference/js-reference#use_fedcm_for_prompt) when integrating GIS to your website. For existing apps, you should [migrate to FedCM](/identity/gsi/web/guides/fedcm-migration) to determine if your existing integration with GIS needs to be updated.\n\nSeparated authentication and authorization moments\n\nTo obtain an access token for use with Google APIs, or to access user data, you\nneed to call the [Google Identity Services authorization\nAPI](/identity/oauth2/web/guides/overview). It's a separate JavaScript API, but\npackaged together with the authentication API.\n\nIf your website needs to call both authentication and authorization APIs, you\nneed to call them separately at different moments. At the authentication moment,\nyour website can integrate with One Tap, automatic sign-in and the Sign In\nwith Google button to allow users to sign in or sign up to your website. At a\nlater time, when accessing data from Google is required, you call the\nauthorization API to ask for the consent and get access tokens for data access.\nThis separation complies with our recommended [incremental\nauthorization](/identity/protocols/oauth2/web-server#incrementalAuth) best\npractice, in which the permissions are requested in context.\n\nTo enforce this separation, the authentication API can only return ID tokens\nwhich are used to sign in to your website, whereas the authorization API can\nonly return code or access tokens which are used only for data access but not\nsign-in.\n\nThanks to this separation, users have consistent authentication experiences\nacross different websites, which may increase user trust and usage, and\nresult in better user conversion rates on your website. Also, due to this\nseparation, Google Identity Services reduces the level of OAuth experience\nrequired and time to implement for authentication developers.\n| **Key Point:** Google Identity Services designates Sign in with Google for the authentication moment API and features. Google Identity Services designates the [Authorization API](/identity/oauth2/web/guides/overview) for the authorization moment API and features."]]
