Authentication and authorization use cases

This page lists some common authentication and authorization use cases, with links to more information about how to implement each use case.

For an overview of authentication at Google, see Authentication at Google.

Authenticate to Google APIs

Google APIs require a valid access token or API key with every request. How you provide these required credentials depends on where your code is running and what types of credentials the API accepts.

Use the client libraries and Application Default Credentials

The recommended way to use Google APIs is to use a client library and Application Default Credentials (ADC). Application Default Credentials (ADC) is a strategy used by the authentication libraries to automatically find credentials based on the application environment. The authentication libraries make those credentials available to Cloud Client Libraries and Google API Client Libraries. When you use ADC, your code can run in either a development or production environment without changing how your application authenticates to Google Cloud services and APIs.

How you set up ADC depends on where your code is running. ADC supports both authenticating as a service account and authenticating as a user.

Authenticate from Google Kubernetes Engine (GKE)

You use Workload Identity Federation for GKE to enable your workloads running on GKE to securely access Google APIs. Workload Identity Federation for GKE enables a GKE service account in your GKE cluster to act as an Identity and Access Management (IAM) service account.

Authenticate from Knative serving

You authenticate your Knative serving services by using Workload Identity Federation for GKE, which enables you to access Google APIs.

Use an API that accepts API keys

API keys associate an API request with a Google Cloud project for billing and quota purposes. If an API supports API keys, an API key can be provided with the API request instead of the token. To determine whether an API supports API keys, see the documentation for your API.

Use self-signed JSON Web Tokens (JWTs)

Some Google APIs support self-signed JSON Web Tokens (JWTs) instead of access tokens. Using a self-signed JWT lets you avoid making a network request to Google's authorization server. This approach requires that you create your own signed JWT. For more information about tokens, see Token types.

Use the authentication libraries and packages

If ADC and the OAuth implementation provided by the Cloud Client Libraries or Google API Client Libraries isn't available in your environment, you can use the authentication libraries and packages.

The following authentication libraries and packages are available:

You can also implement the OAuth 2.0 flow using Google's OAuth 2.0 endpoints. This approach requires a more detailed understanding of how OAuth 2.0 and OpenID Connect work. For more information, see Using OAuth 2.0 for Web Server Applications.

Google Cloud service-specific use cases

Some Google Cloud services support authentication flows specific to that service.

Provide time-limited access to a Cloud Storage resource using signed URLs

Signed URLs provide time-limited access to a specific Cloud Storage resource.

Authenticate to GKE Enterprise clusters

You can authenticate to GKE Enterprise clusters using Google Cloud identities or by using a third-party identity provider:

Configure an API deployed with API Gateway or Cloud Endpoints for authentication

API Gateway and Cloud Endpoints support service-to-service authentication and user authentication with Firebase, Google-signed ID tokens, Okta, Auth0, and JWTs.

For information, see the product documentation:

Authentication for applications hosted on Cloud Run or Cloud Run functions

Applications hosted on Cloud Run and Cloud Run functions require OpenID Connect (OIDC) tokens, or ID tokens, for authentication.

For more information, see the product documentation for the hosting services listed below. For information about other ways to acquire an ID token, see Get an ID token. For more information about ID tokens, including validating ID tokens, see ID tokens.

Cloud Run

There are various ways to set up a Cloud Run service, depending on how the service will be invoked. You might also need to authenticate to other services from a Cloud Run service, which requires an OIDC ID token.

To authenticate users to your service from a web or mobile app, you use Identity Platform or Firebase Authentication. You can also use Identity-Aware Proxy (IAP) to authenticate internal users.

Cloud Run functions

When you invoke a function, you must authenticate your invocation. You can use user credentials or an OIDC ID token.

Authenticate application users

There are various options for authenticating the end users of your application, depending on the rest of your application environment. Use the descriptions below to help you understand the best option for your application.

Authentication service	Description
Google Identity Services	Google Identity Services includes Sign In With Google, Google's user sign-in button, and Identity Services APIs and SDK. Google Identity Services is based on the OAuth 2.0 and OpenID Connect (OIDC) protocols. If you're creating a mobile application, and you want to authenticate users using Gmail and Google Workspace accounts, Sign In With Google could be a good option. Sign In With Google also supports using Google Accounts with an existing sign-in system. More information Sign In With Google provides Gmail and Google Workspace account sign-in, and support for one-time passwords (OTP). Sign in with Google is targeted toward Google-only accounts, or Google Accounts in an existing sign-in system, for mobile applications. Sign in With Google is available for iOS, Android, and web applications.
Firebase Authentication	Firebase Authentication provides authentication services and libraries to authenticate users to your application for a wide array of user account types. If you want to accept user sign-ins from multiple platforms, Firebase Authentication could be a good option. More information Firebase Authentication provides authentication functionality for many user account types. Firebase Authentication supports password authentication and federated sign-in with Google, Facebook, Twitter, and other platforms. Identity Platform and Firebase Authentication are both based on Google Identity Services. Firebase Authentication is targeted toward consumer applications. Identity Platform is ideal for users who want to be their own identity provider, or who need the enterprise-ready functionality Identity Platform provides. For more information about the differences between these products, see Differences between Identity Platform and Firebase Authentication. The following links provide more information: Where do I start with Firebase Authentication? helps you understand some ways of using Firebase Authentication. For Python applications running in the App Engine standard environment, see Authenticating users with Firebase.
Identity Platform	Identity Platform is a customer identity and access management (CIAM) platform that helps organizations add enterprise-grade identity and access management functionality to their applications. If you're creating an application for use with a Google identity provider such as Google Workspace, or your own identity and access management service, Identity Platform could be a good option. More information Identity Platform provides a drop-in, customizable identity and authentication service for user sign-up and sign-in. Identity Platform supports multiple authentication methods: SAML, OIDC, email/password, social, phone, and custom options. Identity Platform and Firebase Authentication are both based on Google Identity Services. Firebase Authentication is targeted toward consumer applications. Identity Platform is ideal for users who want to be their own identity provider, or who need the enterprise-ready functionality Identity Platform provides. For more information about the differences between these products, see Differences between Identity Platform and Firebase Authentication.
OAuth 2.0 and OpenID Connect	OpenID Connect lets you handle and use authentication tokens with the most customization. If you want maximum control over your OAuth 2.0 implementation, and you're comfortable implementing OAuth 2.0 flows, consider this option. More information Google's OAuth 2.0 implementation conforms to the OpenID Connect specification and is OpenID Certified. OpenID Connect is an identity layer on top of the OAuth 2.0 protocol. Your application can use OpenID Connect to validate the ID token and retrieve user profile information. OAuth 2.0 can be used to implement programmatic authentication to an Identity-Aware Proxy-secured resource.
Identity-Aware Proxy (IAP)	IAP lets you control access to your application before requests reach your application resources. Unlike the other authentication services in this table, which are implemented within your application, IAP performs authentication before your application can be reached. More information With IAP, you establish a central authorization layer for applications and use signed headers to secure your app. IAP-protected applications can be accessed only by principals that have the correct IAM role. When an end user tries to access an IAP-secured resource, IAP performs authentication and authorization checks for you. IAP doesn't protect against activity within a project, such as another service in the same project. For Google identities, IAP uses ID tokens. For more information, see Programmatic authentication. For information about how IAP secures your application resources, see the IAP overview. The following language-specific tutorials are available for IAP: Authenticating users with Go Authenticating users with Node.js Authenticating users with PHP Authenticating users with Python Authenticating users with Ruby
App Engine Users API	For applications running in the App Engine standard environment, the Users API is available to provide user authentication functionality for some languages.
Authorizing access for end-user resources	If your application accesses resources that are owned by your end user, you must secure their permission to do so. This use case is sometimes called three-legged OAuth or 3LO, because there are three entities involved: the application, the authorization server, and the user.

Authentication and authorization options for Google Cloud and Google Workspace

Google Cloud and Google Workspace provide various options for setting up access, enhancing account security, and administering accounts.

Grant access to Google Cloud resources for external workloads

Workload Identity Federation lets you grant on-premises or multi-cloud workloads access to Google Cloud resources. Historically, this use case required the use of service account keys, but Workload Identity Federation avoids the maintenance and security burden of using service account keys. Workload Identity Federation supports OIDC-compatible or SAML 2.0-compatible identity providers.

Set up an identity provider

You can use Google as your identity provider, by using Cloud Identity or Google Workspace. You can also federate a Cloud Identity or Google Workspace account with an external identity provider. This approach uses SAML, enabling your employees to use their existing identity and credentials to sign in to Google services.

Set up two-factor authentication

Requiring two-factor authentication is a best practice that helps to prevent bad actors from accessing an account when they have gained access to the credentials for that account. With two-factor authentication, a second piece of information or identification from the user is required before that user is authenticated. Google's provides several solutions that support the FIDO (Fast IDentity Online) standard.

Identity Platform supports two-factor authentication for web, iOS, and Android apps.

Google Identity Services supports FIDO (Fast IDentity Online) authentication.

Google supports various hardware solutions for two-factor authentication, such as Titan Keys.

Set up certificate-based access

Part of the Chrome Enterprise Premium zero trust solution, certificate-based access limits access to only authenticated users on a trusted device, identifying devices through their X.509 certificates. Certificate-based access is also sometimes referred to as mutual Transport Layer Security (mTLS).

General account and authentication information

Get help with accessing a Google Account

If you need help with accessing or managing a Google Account, see the Google Account support page.

Handle compromised credentials

If you believe that your credentials have been compromised, there are steps you or your administrator can take to mitigate the situation. For more information, see Handling compromised Google Cloud credentials.

Get help with certificate authority issues

If you see errors related to an issue with your certificate or certificate authority (CA), including your root CA, see the Google Trust Services FAQ for more information.