Google API, OAuth 2.0 app authentication process analysis

Google API Console
Google API Console Launched in 2010 as a web service that allows Google to integrate and manage the vast APIs provided by its clients.

Issuing OAuth 2.0 client_id
In order to use Google APIs, you first need a Google account with an individual or company (recommended for paid plans)

You can create up to 10 projects with one Google account. When you create a project project_number : receive grants (ex 257124386236) each API Person App ID is used.

Each project has a set of related configurable information resource. The most basic information is project_name , project_id , and project_number .

Each project can be shut down arbitrarily . In shutdown, all charges and traffic are interrupted. Projects older than 30 days after shutdown will be automatically deleted.

Each project n one client_id can generate. Produced immediately client_id , client_secret this issue is can query information at any time.

client_secret can be reissued. Upon re-issuance, the existing client_secret is invalidated.

Each client_id is n one redirect_uri can be set. Only full URLs with hostnames starting with http and https are allowed. IP addresses are not allowed.

The project client_id When you create a Google all of which are provided API can be used (in October 2017 a total of 177 currently).

OAuth 2.0 Scope

It provides a unique across all 177 APIs provided by Google scope. Here’s an example of the Google Drive API : The following scopes are used as parameters for authorization delegation requests to the user. Each scope is separated by a space ( % 20 ).

It is the same until , followed by the API name, the API resource name, and the dotted (.) symbol of the resource.

Google API calls

When OAuth 2.0 authentication is completed, it receives an access_token . The client needs to specify the access_token value in the header value for each API call . Here ‘s an example of calling an API that requests a list of files in Google Drive: Authorization: Bearer

Authorization: Bearer ya29.GlwzBvt__ySwgbmg-VTCevdmW9HB2I0mQS8JtaxHhDcXvK4z6K_upRpT3Bs7KrN9uPPWdqNQ96MN-k1RHEaDz7H7OyCrZp6_-DI2L41ymgsohMvPe64lFv7mwrIerQ

Online access, offline access

When a client redirects to Google‘s web page to display a page that consents to authorization, the client access_type can pass parameters to the server side . If the parameter is omitted, the default value is online set to offline and can be passed.

If set to online , it will refresh_token not be downloaded to the client . After the user’s authorization agreement access_token expires, if the client’s acquisition expires, the user must repeat the process of requesting authorization again.

If set to offline , refresh_token is given to the client . Even if the access_token expires over time, a new access_token can be issued using refresh_token downloaded by the client itself without user intervention .

In other words, Google‘s concept of online access, offline access is merely a different interpretation of refresh_token in the OAuth 2.0 specification .

The life cycle of refresh_token

Google does not set a limit on the expiration time of the refresh_token issued after the initial user’s authorization agreement . That is, it is unlimited. access_token shorten the expiration time of leaving permanent refresh_token to access_token be reissued for.

The number one issue refresh_token is canceled (the user is authorized to accept client revoke valid until).

refresh_token is not issued indefinitely. There is an issuance limit for each client and user group. When the issuance is exceeded, the oldest refresh_token expires.

Introducing the Google API Console
OAuth 2.0 Scopes for Google APIs
Using OAuth 2.0 to Access Google APIs
Using OAuth 2.0 for Web Server Applications
Auth0 – Understanding Refresh Tokens

Leave a Reply