Authorizing for Web (original) (raw)

Web apps must obtain an access token to securely call Google APIs.

The Google Identity Services JavaScript library supports both authentication for user sign-in and authorization to obtain an access token for use with Google APIs. The library is intended only for use in browsers.

Authentication establishes who someone is, and is commonly referred to as user sign-up or sign-in. Authorization is the process of granting or rejecting access to data or resources. It includes obtaining and managing user consent, limiting the amount of data or resources shared with scopes, and retrieving an access token for use with Google APIs.

These guides cover authorization and data sharing topics.

How user authorization works describes the individual steps of user authorization in detail and includes user dialog examples.

If you are looking for help with authentication and how to implement user sign-up and sign-in see Sign In With Google.

This library is not intended for use with server-side JavaScript frameworks such as Node.js, instead use Google's Node.jsclient library.

What's changed

For users, the Google Identity Services library offers numerous usability improvements over earlier JavaScript libraries, including:

• Authentication for user sign-in, and authorization to obtain an access token to call Google APIs, now have two separate and distinct user flows; one forsign-in and another for consent during authorization, with separate user flows to clearly differentiate who you are, from what an app can do.
• Improved visibility and granular control of data sharing during user consent.
• Browser based pop-up dialogs to reduce friction, and which do not require users to leave your site to:
  • obtain an access token from Google, or
  • send an authorization code to your backend platform.

For developers, our focus has been to reduce complexity, improve security, and make your integration as quick and easy as possible. Some of these changes are:

• User authentication for sign-in, and authorization used to obtain an access token to call Google APIs, are two separate and distinct sets of JavaScript objects, and methods. This reduces the complexity and amount of detail required to implement authentication or authorization.
• A single JavaScript library now supports both the:
  • OAuth 2.0 implicit flow, used to obtain an access token for use in-browser
  • OAuth 2.0 authorization code flow, also known as offline access, and initiates securely delivering an authorization code to your backend platform, where it can be exchanged for an access token and refresh token. Previously, these flows were only available by using multiple libraries and through direct calls to OAuth 2.0 endpoints. A single library decreases your integration time and effort, instead of including and learning multiple libraries and OAuth 2.0 concepts you can focus on a single, unified interface.
• Indirection through getter style functions has been removed for simplicity and readability.
• When handling authorization responses you choose whether or not to use aPromise to fulfill requests, instead of that decision being made for you.
• The Google API Client Library for JavaScript has been updated with these changes:
  • the gapi.auth2 module and associated objects and methods are no longer automatically loaded for you behind the scenes, and have been replaced with more explicit Google Identity Services library objects and methods.
  • Automatic refresh of expired access tokens has been removed to improve user security and awareness. After an access token expires your app must handle Google API error responses, request, and obtain a new, valid access token.
  • To support a clear separation of authentication and authorization moments, simultaneously signing a user in to your app and to their Google Account while also issuing an access token is no longer supported. Previously, requesting an access token also signed users into their Google Account and returned a JWT ID token credential for user authentication.
• To increase user security and privacy, per user credentials issued for authorization follow the principle of least privilege by including only an access token and information required to manage it.