Skip to content

Authentication SOP

Fresh -- Updated March 2026 from official Google Cloud documentation.

Purpose

Configure authentication for Google Cloud APIs using the appropriate method for your use case.

Prerequisites

  • A Google Cloud project with APIs enabled
  • gcloud CLI installed and initialized
  • Understanding of your deployment environment (local dev, GCE, GKE, external)

Authentication Methods Comparison

MethodUse CaseSecurity Level
Application Default Credentials (ADC)Most workloads, recommended defaultHigh
Service Account KeysNon-GCP environments, CI/CDMedium (key must be secured)
OAuth 2.0User-facing apps needing user contextHigh
API KeysPublic data access, quota trackingLow (no identity)
Workload Identity FederationAWS, Azure, on-prem workloadsHigh

Procedure

Method 1: Application Default Credentials (ADC)

ADC is the recommended approach. Client libraries find credentials automatically.

For local development:

bash
gcloud auth application-default login

This opens a browser for OAuth consent and stores credentials at:

  • Linux/macOS: ~/.config/gcloud/application_default_credentials.json
  • Windows: %APPDATA%\gcloud\application_default_credentials.json

For production on GCE/GKE/Cloud Run:

No setup needed. The service's default service account is used automatically.

For production outside GCP:

bash
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account-key.json"

Python usage:

python
from google.cloud import storage

# ADC is used automatically -- no credentials needed in code
client = storage.Client()

Method 2: Service Account Keys

Create a service account:

bash
gcloud iam service-accounts create my-sa \
  --display-name="My Service Account"

Grant roles:

bash
gcloud projects add-iam-policy-binding my-project \
  --member="serviceAccount:my-sa@my-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

Create and download a key:

bash
gcloud iam service-accounts keys create key.json \
  --iam-account=my-sa@my-project.iam.gserviceaccount.com

WARNING

Service account key files are sensitive credentials. Store them securely. Never commit them to version control. Rotate keys regularly.

Method 3: OAuth 2.0

Set up OAuth consent screen in the Cloud Console:

https://console.cloud.google.com/apis/credentials/consent

Create OAuth client ID:

bash
# Via Console: APIs & Services > Credentials > Create Credentials > OAuth client ID

Use in application:

python
from google_auth_oauthlib.flow import InstalledAppFlow

SCOPES = ['https://www.googleapis.com/auth/cloud-platform']

flow = InstalledAppFlow.from_client_secrets_file('client_secret.json', SCOPES)
credentials = flow.run_local_server(port=0)

Method 4: API Keys

Create an API key:

bash
gcloud services api-keys create --display-name="My API Key"

Use in requests:

bash
curl "https://translation.googleapis.com/language/translate/v2?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"q":"Hello","target":"es"}'

DANGER

API keys do NOT identify a user. They only identify the calling project for billing and quota. Never use API keys for operations that require authorization.

Method 5: Workload Identity Federation

For workloads running on AWS, Azure, or on-premises:

bash
# Create a workload identity pool
gcloud iam workload-identity-pools create my-pool \
  --location="global" \
  --display-name="My Pool"

# Create a provider for AWS
gcloud iam workload-identity-pools providers create-aws my-aws-provider \
  --location="global" \
  --workload-identity-pool="my-pool" \
  --account-id="AWS_ACCOUNT_ID"

Authentication Decision Diagram

Verification Checklist

  • [ ] gcloud auth application-default print-access-token returns a valid token
  • [ ] API calls authenticate without 401/403 errors
  • [ ] Service account has only the minimum required roles (principle of least privilege)
  • [ ] No service account keys are committed to version control
  • [ ] Key rotation schedule is in place for any downloaded keys

See Also