Skip to main content
This guide describes how to configure OAuth 2.0 / OIDC Authentication for applications running behind a Datum gateway using datumctl. The configuration uses Envoy Gateway SecurityPolicy resources and applies to Windows, macOS, and Linux.

Overview

OIDC authentication protects an application by requiring users to sign in with their Google account before requests are forwarded to the origin. Envoy Gateway handles the OAuth 2.0 flow transparently — users are redirected to Google, authenticate, and are redirected back without any changes to your application. At a high level, this setup:
  1. Creates a Google OAuth 2.0 Client in Google Cloud Console
  2. Stores the client secret in a Kubernetes Secret
  3. Labels the Secret so it is synced to edge clusters
  4. Attaches a SecurityPolicy with OIDC config to an HTTPRoute
  5. Verifies authentication behavior

Prerequisites

  • datumctl installed and authenticated
  • A valid Project
  • A Google Cloud account with a project
  • Existing:
    • Gateway
    • HTTPRoute
  • Permission to create:
    • Secret
    • SecurityPolicy
Verify access:

Critical requirement: secret syncing

Secrets and ConfigMaps referenced by gateway configurations are not automatically synced to edge clusters. To make a Secret available to edge gateways, it must include the following label:

Why this matters

  • Without this label, the gateway receives the policy but not the Secret
  • Envoy fails to load the OAuth client credentials
  • All requests return HTTP 500 instead of redirecting to Google
This requirement exists to prevent accidental replication of unrelated secrets.

Configuration steps

Step 1: Create Google OAuth 2.0 credentials

  1. Go to Google Cloud ConsoleAPIs & ServicesCredentials
  2. Select Create CredentialsOAuth 2.0 Client ID
  3. Set Application type to Web application
  4. Under Authorized redirect URIs, add:
    Replace <your-app-hostname> with the public hostname of your HTTPRoute.
  5. Select Create and copy the Client ID and Client Secret
Note: The redirect URI must exactly match the value you will configure in the SecurityPolicy. Any mismatch causes Google to reject the OAuth flow.

Step 2: Set variables

Windows (PowerShell)

macOS / Linux


Step 3: Create the client secret

The Secret must:
  • Use the key client-secret
  • Exist in the same namespace as the SecurityPolicy
  • Include the gateway-sync label

Windows (PowerShell)

macOS / Linux


Step 4: Attach OIDC authentication using a SecurityPolicy

Attach the policy to the HTTPRoute. This is the most reliable attachment point.

Windows (PowerShell)

macOS / Linux


Verification

Unauthenticated request

Expected response:
Browsers will redirect automatically to the Google sign-in page.

Authenticated session

After completing the Google sign-in flow, subsequent requests will be forwarded to your origin with a session cookie managed by Envoy.
Expected response after authentication:

Cleanup / disable OIDC authentication

Windows (PowerShell)

macOS / Linux


Troubleshooting

Common failure modes


Useful debug commands


Best practices

  • Register separate OAuth clients for each environment (dev, staging, prod)
  • Restrict authorized redirect URIs to known hostnames only
  • Limit OAuth scopes to the minimum required (openid, email)
  • Rotate the client secret periodically and re-apply the Secret
  • Use OIDC for production — Basic Auth is suited for development and demos

Summary

  • Google OAuth is configured using Envoy Gateway SecurityPolicy with an oidc block
  • The client secret is stored as a Kubernetes Secret with key client-secret
  • Secrets must be explicitly synced to edge clusters using the networking.datumapis.com/gateway-sync: "true" label
  • The redirectURL in the policy must exactly match the URI registered in Google Cloud Console
  • Attaching policies to HTTPRoute is the most reliable approach
Last modified on June 15, 2026