How to Maintain Your Skills as a Developer
20th July 2021Tips For React-Native Developers
22nd July 2021What is Google OAuth 2.0?
OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access the user account. OAuth 2.0 provides authorization flows for web and desktop applications, and mobile devices.
This informational guide is geared towards application developers and provides an overview of OAuth 2.0 roles, authorization grant types, use cases, and flows.OAuth 2.0 Roles
OAuth defines four roles:- Resource Owner
- Client
- Resource Server
- Authorization Server
We will detail each role in the following subsections.
Resource Owner: User
The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted (e.g. read or write access).
Resource / Authorization Server: API
The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.
From an application developer’s point of view, a service’s API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.
Client: Application
The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.
OAuth 2.0 Scopes for Google APIs
This document lists the OAuth 2.0 scopes that you might need to request to access Google APIs, depending on the level of access you need. Sensitive scopes require review by Google and have a sensitive indicator on the Google Cloud Platform (GCP) Console’s OAuth consent screen configuration page. Many scopes overlap, so it’s best to use a scope that isn’t sensitive. For information about each method’s scope requirements, see the individual API documentation. If your public application uses scopes that permit access to certain user data, it must complete a verification process. If you see an unverified app on the screen when testing your application, you must submit a verification request to remove it. Find out more about unverified apps and get answers to frequently asked questions about app verification in the Help Center.
AI Platform Training & Prediction API, v1
Scopes | |
---|---|
https://www.googleapis.com/auth/cloud-platform | View and manage your data across Google Cloud Platform services |
https://www.googleapis.com/auth/cloud-platform.read-only | View your data across Google Cloud Platform services |
Access Approval API, v1
Scopes | |
---|---|
https://www.googleapis.com/auth/cloud-platform | View and manage your data across Google Cloud Platform services |
More info is available here
OAuth 2.0 Policies
The applications and services you design and build with Google APIs must do more than provide value to users and businesses. We also require that they be secure and provide the appropriate level of privacy demanded by users. The following policies are part of the Google APIs Terms of Service. They apply to all developers who use OAuth 2.0, which includes OpenID Connect for authentication only. The policies below are a minimum set of requirements; we recommend that you take any additional steps necessary to ensure that your applications and systems are safe and secure.
Comply with all terms of service and policies
The use of Google API Services, which includes our implementation of OAuth 2.0, is governed by the Google APIs Terms of Service and Google API Services User Data Policy. In addition, the use of OAuth 2.0 is governed by this policy. Please read these documents carefully, as well as any other terms or policies that apply to any other Google products or services you are using. Be sure to check for updates periodically as these documents are occasionally updated.
More info on OAuth 2.0 policies is available here
How to Access OAuth 2.0?
Using OAuth 2.0 for Web Server Applications
This document explains how web server applications use Google API Client Libraries or Google OAuth 2.0 endpoints to implement OAuth 2.0 authorization to access Google APIs.
OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives.
This OAuth 2.0 flow is specifically for user authorization. It is designed for applications that can store confidential information and maintain its state. A properly authorized web server application can access an API while the user interacts with the application or after the user has left the application.
Web server applications frequently also use service accounts to authorize API requests, particularly when calling Cloud APIs to access project-based data rather than user-specific data. Web server applications can use service accounts in conjunction with user authorization.
More Detail about OAuth 2.0 for Web Server Applications here
OAuth 2.0 for Client-side Web Applications
This document explains how to implement OAuth 2.0 authorization to access Google APIs from a JavaScript web application. OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives.
This OAuth 2.0 flow is called the implicit grant flow. It is designed for applications that access APIs only while the user is present at the application. These applications are not able to store confidential information.
In this flow, your app opens a Google URL that uses query parameters to identify your app and the type of API access that the app requires. You can open the URL in the current browser window or a popup. The user can authenticate with Google and grant the requested permissions. Google then redirects the user back to your app. The redirect includes an access token, which your app verifies and then uses to make API requests.
More Detail About OAuth 2.0 for Client-side Web Applications is here
Conclusion
That concludes this OAuth 2.0 guide. You should now have a good idea of how OAuth 2 works, and when a particular authorization flow should be used.