# Google Cloud Authentication

## Summary


Google Cloud supports three main types of credentials by which apps can gain access to APIs and services. These are API keys, OAuth 2.0 client IDs and service accounts. This article gives an overview of these methods. It offers some guidelines on how to choose the right authentication method for an application.

Improper use of these methods or careless management of credentials can lead to a security breach. It can result in identity theft and data theft/loss. This article shares some best practices for better security.

## Discussion

### What are the different authentication methods available in Google Cloud?

Anyone with a Google account can login to Google by supplying a valid username and password. Two-Factor Authentication (2FA) enhances security by adding one more step to the authentication process. In Google, 2FA is called 2-Step Verification. For a better user experience, Google also provides Sign In with Google, One Tap and Automatic sign-in. 

Often developers want their apps to have access to Google accounts or services, for the apps themselves or on behalf of end users. Google offers two ways to achieve this: 

    + **User Account**: Represents a developer or administrator. Used when an application needs to access Google Cloud resources on behalf of the user. Managed by Google Accounts. Credentials used include API keys and OAuth 2.0 client credentials.
    + **Service Account**: Represents non-human users. Used when an application needs to access Google Cloud resources on its own without any user intervention. Managed by Google's Identity and Access Management (IAM). Credentials include service account keys. Unlike a user account, a service account doesn't have a user-facing login interface.Google Cloud APIs use OAuth 2.0 protocol to authenticate both user accounts and service accounts. 


### How do I select a suitable Google Cloud authentication method?

Many Google Cloud APIs allow anonymous access to public data. **API keys** can be used. These identify the application, not the actual user. 

If your app requires access to a user's private data, then **OAuth 2.0 client ID** can be used. In OAuth 2.0 terminology, your application is called the client. The client ID identifies the application. The user is prompted to allow Google share some of his/her data with your application. Your application can now use Google Cloud APIs on behalf of the user. 

Where user authorization is not possible, use a **service account**. For apps running inside Google Cloud, it's automatically created. Otherwise, you manually create a service account. You download the credentials as a JSON file that your app can use. Your app assumes the identity of the service account so that users are not involved. Such server-to-server interactions are sometimes called *Two-Legged OAuth (2LO)*. 


### Could you share some use cases for each Google Cloud authentication method?

Google Cloud has dozens of APIs that can be accessed via API keys or OAuth 2.0 client IDs. Some of these APIs are Google Drive, Google Calendar, GMail, YouTube Data, App Engine Admin, Cloud Datastore, Cloud Speech-to-Text, Cloud Vision, Firebase Management, and many more. 

For example, YouTube Data API can be used read metadata of any video. It's implemented via the `videos` endpoint. Since this is public data, an API key is sufficient. The same API also allows an app to manage videos and playlists that you own. This requires OAuth 2.0 client ID. 

Managing your appointments on Google Calendar or your drafts on GMail are further examples where OAuth 2.0 client ID can be used. Web/mobile apps can use OAuth 2.0 client ID for visitors to quickly create accounts on their platforms. 

Consider an external application that wants to store nightly data backups to Google Drive. A service account suits this use case. 


### Could you share some tips related to Google Cloud authentication?

API keys, OAuth 2.0 client IDs and service accounts are typically created via a web interface called *Google Cloud Console*. In all cases, the credentials fall within the scope of a project that has an associated billing account. Advanced users can look at the *API Keys API* to create or manage API keys via `gcloud` CLI. `gcloud` can also be used to manage service accounts. 

Developers can try out APIs using the Google API Explorer. This helps in understanding the APIs before doing it programmatically from application code. While it's possible to implement OAuth 2.0 flows, it's easier to use Google Cloud Client Libraries. 

When using OAuth 2.0 client IDs, code your apps to ask for minimum required permissions. This is done by setting *scopes*. Google maintains a list of available OAuth 2.0 Scopes per API. 

For local development, use `gcloud auth login` and `gcloud auth application-default login` commands. Use short-lived tokens. 


### What are some best practices when using API keys?

Don't embed API keys directly in code. Store them in environment variables or in files outside your application's version controlled source code. Do a code review to ensure API keys aren't there by mistake. 

When not used, delete API keys to minimize security attacks. Regenerate API keys periodically. 

For better security, place restrictions on the use of API keys: 

    + **Source**: Restrictions on who can use the key. Restrict by HTTP referrers, IP addresses, Android apps or iOS apps. HTTP referrers can be whitelisted by subdomains, paths, protocols (HTTP or HTTPS) and even wildcards.
    + **Target**: Restrictions on what services are allowed. For example, restrict the key to only Google Drive API.API keys are vulnerable to man-in-the-middle attacks since they're part of the request. Don't use them when API calls contain user data. 

Don't use API keys to identify users. An API key only identifies the project. Don't use API keys for secure authorization. API keys are useful to block anonymous traffic, control volume of API requests, identify usage patterns, or filter logs by the API key. 


### What are some best practices when using service accounts?

Service accounts are both a resource and an identity. As an identity, avoid granting Owner/Editor/Viewer roles to a service account. Grant instead a predefined or custom role. In general, grant only minimum necessary permissions. 

Use unique, descriptive names so that it's easier to manage multiple accounts. Delete accounts if they're unused since they present a security risk. Disable accounts before deleting them. 

Service account keys are either Google Cloud-managed or user-managed. For the latter, follow processes for key storage, distribution, revocation, rotation and recovery. 

Don't use service accounts to access data without user consent. Don't use service accounts during development. Instead authenticate using tools such as `gcloud`, `gsutil`, `terraform`, etc. In other words, use your personal credentials in a development environment. 

You can attach applications to an existing service account. On a GKE cluster, use multiple Google Cloud and Kubernetes service accounts and map them via Workload Identity. 

## Milestones

Apr  
2008

Google previews **App Engine**, a platform for developing and hosting web applications in Google-managed data centres. App Engine is therefore the first cloud service offered by Google. It marks the birth of Google Cloud. 

Oct  
2012

IETF releases **OAuth 2.0** as RFC 6749. Although OAuth 2.0 is designed for authorization and not for user authentication, Google Cloud later uses OAuth 2.0 for both authorization and authentication. 

Mar  
2011

Google launches **Google API Explorer** that allows developers to experiment with Google's APIs before implementing them in their apps. By August 2021, the Explorer supports 230 APIs. API keys and OAuth 2.0 client IDs can be used with the Explorer. 

Aug  
2021

Google launches **Google Identity Services**, a single SDK that brings together different ways of authenticating users. It provides developers frictionless flows to onboard users to their platforms. *Sign in with Google* and *One Tap* are two such flows. These use secure tokens rather than passwords. These internally use OAuth 2.0. Developers can use client libraries provided by Google to quickly implement these flows. An alternative is *Firebase Authentication*.