# Sign in with Google features

The following are the main features of Sign in with Google. You can use the
[code generator](https://developers.google.com/identity/gsi/web/tools/configurator) to generate code to embed One Tap, Automatic sign-in and
the Sign in with Google button into your web pages.

Users can globally opt-out of third-party sign-in on browsers which
[support FedCM](https://developers.google.com/identity/gsi/web/guides/supported-browsers). When users opt-out, One Tap and automatic sign-in are
unavailable and are not displayed.

## One Tap

When users visit your website, if there is an active Google session in the
browser, Sign in with Google may prompt users to sign in or sign up on
your website with their Google Account. With just one tap (for a single
Google session case) or two taps (when there are multiple Google sessions),
users can finish the federated sign-in or sign-up flow. The One Tap UX allows
for smooth user entry points, since all the UX flows are performed in an
iframe embedded in your web pages.

![One Tap pop-up requesting both consent and signing the user in](https://developers.google.com/static/identity/gsi/web/images/one-tap-ui-fedcm.png)

Users may choose to [globally opt-out One Tap](https://developers.google.com/identity/gsi/web/guides/features#globally_opt_out). In this case the Google
Account does not display One Tap. If all active Google Accounts are
opted out, the One Tap UI is not shown.

> [!NOTE]
> **Note:** Due to [Intelligent Tracking Prevention](https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/) (ITP), an additional [welcome page](https://developers.google.com/identity/gsi/web/guides/features#upgraded_ux_on_itp_browsers) is displayed for ITP browsers, like Chrome on iOS, Safari, and FireFox. Developers can opt-out from this feature on one or multiple ITP browsers. More details at [One Tap Support on ITP browsers](https://developers.google.com/identity/gsi/web/guides/itp).

> [!IMPORTANT]
> **Key Point:** Refer to [Understand the One Tap user experience](https://developers.google.com/identity/gsi/web/guides/features) for more details about the One Tap UX.

You are recommended to put One Tap on both your main login dialog and
leaf pages. Developers prefer One Tap for many reasons:

- increased user conversion rates. Learn more about how some of our partners have successfully used One Tap to improve their sign up and sign in experiences in our [case studies](https://developers.google.com/identity/sign-in/case-studies).
- allows sign in and sign up without redirecting users to a dedicated sign in and sign up page.
- allows users to sign in and sign up in the context of your website without having to navigate away from their current journey.
- mitigate duplicate accounts with personalized prompts and [automatic sign-in](https://developers.google.com/identity/gsi/web/guides/offerings) on return visits.

> [!WARNING]
> **Warning:** The One Tap UI should be displayed automatically on page load or other window events, instead of being triggered by a user gesture. Otherwise, you may get a broken UX. Users may not see any UI after a user gesture, due to [globally opt-out](https://developers.google.com/identity/gsi/web/guides/features#globally_opt_out), [cool-down](https://developers.google.com/identity/gsi/web/guides/features#exponential_cooldown), or no Google session.

## Automatic sign-in

With One Tap, you can also enable the cancelable automatic sign-in, which
enables a streamlined UX for returning users. No user gesture is needed for
returning users to automatically sign in to your website. Automatic sign-in
is triggered when there is only one active Google Account that has previously
granted consent to share their account profile with your app.

Users have the ability to cancel the auto sign-in process for a short period
of time, ensuring user control and transparency. If users cancel automatic
sign-in, Sign in with Google remembers the decision for one day before it
enables automatic sign in again. The cancelable feature allows users to have
more control on the automatic sign in process.

When FedCM is enabled, there is a 10 minute cooling off period between automatic
sign-in events. If automatic sign-in is triggered during this time users
follow the One Tap sign-in flow instead of the automatic sign-in flow.

Sign in with Google for Web doesn't support silent sign in, in which case a
credential is returned without any UI displayed. End users always see some UI,
manual or automatic sign in, when a login credential is returned from Google to
the relying party. This improves user privacy and control.

![Sign in with Google One Tap automatic sign-in prompt](https://developers.google.com/static/identity/gsi/web/images/auto-sign-in-fedcm.png)

Whether to enable automatic sign-in is a decision you need to make based on the
UX of your own website.

> [!NOTE]
> **Note:** Automatic sign-in can be enabled only on the One Tap flow, not on the Sign in with Google button flow.

> [!IMPORTANT]
> **Key Point:** Refer to [Automatic sign-in and sign-out](https://developers.google.com/identity/gsi/web/guides/automatic-sign-in-sign-out) for more details.

## Sign in with Google button

In contrast to One Tap, the Sign in with Google button flow must be triggered by
a user gesture. To that end, Sign in with Google only provides the API to
render a button, but not the API to programmatically initiate the button flow.
As a developer, all you need to do is render the Sign in with Google button
on your web pages. When to trigger the button UX flow is handled
by the library transparently.

![Unpersonalized sign-in button](https://developers.google.com/static/identity/gsi/web/images/standard-button-white.png)

Put it another way, the Sign in with Google button must be generated by the
Google Identity Services JavaScript library now. The button rendering API
lets you customize the color, shape, text and size to meet the branding
requirements of your website, whereas still stick to Google's guidelines.
With consistent buttons across websites, users quickly recognize, trust and
use these buttons.

> [!NOTE]
> **Note:** Sign in with Google doesn't provide an API to programmatically initiate the button flow.

> [!WARNING]
> **Warning:** Using your own button is not supported, since there is no API to initiate the button flow when your button is clicked.

User profile information may also be used to render the button. A personalized
button displays only when there is at least one active Google session that
has authenticated a user on your website before. A personalized button reminds
end users that they have used Sign in with Google before, and thus helps
to prevent unnecessary duplicate account creation on your website.
This is especially helpful to end users who visit your website only
occasionally. They may forget the login methods they used.

![Personalized sign-in button](https://developers.google.com/static/identity/gsi/web/images/personalized-button-single.png)

> [!IMPORTANT]
> **Key Point:** Refer to [Understand the personalized button](https://developers.google.com/identity/gsi/web/guides/personalized-button) for more details about the personalized button.

In addition to personalized button, the Sign in with Google button supports
Google Accounts with [Family Link](https://families.google/familylink/) and adhere to [Google Workspace](https://workspace.google.com/)
policies set by the organization's administrator.

The Sign in with Google button flow supports pop-up and redirect UX modes.

- In the pop-up UX, once the Sign in with Google button is clicked, a new pop-up window is opened on top of your web page. The button UX flow is rendered in a pop-up window.
- In the redirect UX, a full page redirect happens after the Sign in with Google button is clicked. The button UX flow is rendered in the same window. However users cannot see your web page any more when the button UX displays.

## Revoke user consent

User consent to share an ID token can be revoked. Sign in with Google provides
an API to programmatically revoke user consent.

Unlike the [`revoke()`](https://developers.google.com/identity/oauth2/web/reference/js-reference#google.accounts.oauth2.revoke) method in the Google Identity Services
authorization API, you don't need an access token to revoke the user consent.
However, you do need to provide the **email address** or **Google user ID** of
the target Google session, and there should be an active Google session for
that account in the browser.

The revocation API revokes the ID token sharing and any other authorization
scopes if granted previously. This is always the case no matter which
revocation API you use.

> [!IMPORTANT]
> **Key Point:** The revocation API doesn't show any UI. Refer to [Revoking user consent](https://developers.google.com/identity/gsi/web/guides/revoke) for more details.

## Code generator

The [code generator](https://developers.google.com/identity/gsi/web/tools/configurator) is a developer tool that can help you to generate the
client side integration code. With the Sign in with Google HTML API, it's
possible that you don't need any JavaScript code for the client-side
integration.

![Code generator step 1: setup](https://developers.google.com/static/identity/gsi/web/images/code-generator-1.png)

For developers who choose to use the JavaScript API, you're recommended to use
the code generator to interactively design your buttons. You can also generate
the HTML code first, then copy the code into corresponding fields in the
JavaScript API.

> [!IMPORTANT]
> **Key Point:** Use the [code generator](https://developers.google.com/identity/gsi/web/tools/configurator) to generate the client side integration code.