Discontinuing authorization support for the Google Sign-In JavaScript Platform Library

March 01, 2022

Link copied to clipboard

Posted by Brian Daugherty, Product Solutions Engineer

Last year, we announced our plan to deprecate the Google Sign-In JavaScript Platform Library for web applications.

On March 31, 2023 we will fully retire the Google Sign-In JavaScript Platform Library and would like to remind you to check if this affects your web application, and if necessary, to plan for a migration.

Beginning April 30th, 2022 new applications must use the Google Identity Services library, existing apps may continue using the Platform Library until the deprecation date.

What does this mean for you?

  • Evaluate if you are affected by the deprecation and your need to Migrate to Google Identity Services.
  • Complete your migration prior to March 31, 2023. If you’re making the switch, we’ve provided a Sign In With Google migration guide to help you out.

Are you affected?

To protect users' personal information across the web, Google continues to make signing into apps and services secure by default. Delivering on this promise, we announced Google Identity Services, our family of Identity APIs that consolidate multiple identity offerings under one software development kit (SDK). Recently, we released an update to the Google Identity Services library, adding user authorization and data sharing features based on OAuth 2.0. Due to numerous security and privacy improvements, the new Identity Services library is not fully backward compatible with all features and functionality found in the older Platform Library, and so a migration to the new library and code changes are necessary.

The deprecation applies to web apps loading the Google Sign-In JavaScript Platform Library and apps using the Google API Client Library for JavaScript with access tokens.

If your web pages use the apis.google.com/js/api.js or apis.google.com/js/client.js JavaScript modules to load the Platform Library, you are affected and need to update your existing implementation to use the new Identity Services client library.

Web applications using gapi.client from the Google API Client Library implicitly load and use the Platform Library’s soon to be deprecated gapi.auth2 module when working with access tokens to call Google APIs. Updates to your web app to explicitly include the new Identity Services library, manage access token requests, and replace auth2 module references with newer equivalent methods are necessary.

Your full suite of apps and platforms may be using different methods of authentication and authorization from Google. The following are NOT affected by this deprecation announcement:

  • Android or iOS native app SDKs,
  • Backend platforms directly calling Google’s OAuth 2.0 or OpenID services.


Authorization and authentication functionalities are clearly separated in the new Identity Services library.

There are two guides to help you with migration:

(1) migrate to Google Identity Services for user authorization and obtaining access tokens for use with Google APIs, and

(2) migrating from Google Sign-In for user authentication and sign-in.

Your web application may use both authorization (to call Google APIs), and authentication (to manage user sign-in to your app). If this is the case, you’ll need to follow both migration guides to ensure separation of user authorization and authentication flows in your web application.

The migration guides are written to help you understand how the new Identity Services library differs from prior libraries, what these changes are, how to separate authentication from authorization, and how these changes affect both your users and your codebase.

Changes and benefits

Migration to our new Identity Services library includes a number of changes and benefits:

  • Pop-ups provide a more secure, reduced UX friction way to authorize your web app without having to use redirects or require users to leave your site.
  • Increased privacy and control by default: users approve individual scopes, and only when they are needed, improving how much, and when, sensitive data may be shared with your web app.
  • Separate ID token and access token credentials clearly distinguish user identity from application capabilities. Individual credentials are easier to separate, manage, or store based upon their level of risk. An identity may convey only who you are and offer a lower level of risk when compared to an access token with capabilities to read/write sensitive user data.
  • Forward compatibility with Chromium Privacy sandbox changes.

This is a brief summary of privacy, security, and usability changes found in the new Identity Services library, additional detail is available in the migration guides.

How to get help

Visit our developer site for more information and check out the google-oauth tag on Stack Overflow for technical assistance. You can also offer your suggestions and feedback by sending an email to gis-migration-feedback@google.com.