Howto Google OIDC

How to set up Google Sign-In

This guide configures Google as an OIDC provider so users can sign in to Bindery with their Google account. Local password login continues to work alongside Google Sign-In.

Prerequisites:

• A Google account with access to Google Cloud Console
• Bindery v0.24.0+
• BINDERY_OIDC_REDIRECT_BASE_URL set to your public Bindery URL

---

Steps

1. Create a Google OAuth 2.0 client

1. Go to Google Cloud Console → APIs & Services → Credentials.
2. Click Create credentials → OAuth 2.0 Client ID.
3. If prompted, configure the OAuth consent screen first:
   • User type: External (or Internal if you're using Google Workspace and want to restrict to your org)
   • App name: Bindery
   • Authorized domains: add bindery.example.com
   • Scopes: add openid, email, profile
4. Back in Credentials → Create OAuth 2.0 Client ID:
   • Application type: Web application
   • Name: Bindery
   • Authorized redirect URIs: https://bindery.example.com/api/v1/auth/oidc/google/callback
5. Click Create. Copy the Client ID and Client Secret — you'll need them in step 3.

Expected result: A credential entry appears with Client ID ending in .apps.googleusercontent.com.

2. Set the redirect base URL

Bindery must know its own public URL to construct the callback link it sends to Google.

# Docker Compose / Helm values.yaml
environment:
  BINDERY_OIDC_REDIRECT_BASE_URL: "https://bindery.example.com"

Restart Bindery if you're adding this for the first time.

3. Add the Google provider in Bindery

Go to Settings → Security → OIDC Providers → Add provider, or POST directly:

curl -X POST http://bindery:8787/api/v1/settings/auth/oidc/providers \
  -H "X-Api-Key: <admin-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "google",
    "name": "Google",
    "issuer": "https://accounts.google.com",
    "client_id": "<your-client-id>.apps.googleusercontent.com",
    "client_secret": "<your-client-secret>",
    "scopes": "openid email profile"
  }'

Expected result: {"id":"google","name":"Google",...} — provider saved.

4. Verify the login button appears

1. Open a private/incognito window and navigate to https://bindery.example.com/login.
2. A Sign in with Google button should appear below (or instead of) the password form.

Expected result: Clicking the button redirects you to accounts.google.com.

5. Complete a test login

1. Click Sign in with Google and authenticate with a Google account.
2. Google redirects back to https://bindery.example.com/api/v1/auth/oidc/google/callback.
3. Bindery provisions a user account (username derived from the Google email, identity keyed on (accounts.google.com, <google-sub>)) and logs you in.
4. Confirm in Settings → Users — the new account appears with role user.

6. (Optional) Restrict to a Google Workspace domain

To allow only users from yourcompany.com, add the hd (hosted domain) parameter. There is no built-in Bindery setting for this — use allowed_groups with a claim mapper, or enforce it at the Google consent screen level by setting User type: Internal (Google Workspace only).

For external users with domain restriction, consider an intermediary like Dex (see GitHub howto) which supports hostedDomain filtering.

---

When this goes wrong

Symptom	Cause	Fix
redirect_uri_mismatch from Google	Redirect URI in Google Console doesn't match exactly	Must be https://bindery.example.com/api/v1/auth/oidc/google/callback — no trailing slash, exact scheme and domain
Login button doesn't appear	Provider not saved, or BINDERY_OIDC_REDIRECT_BASE_URL not set	Check Settings → Security → OIDC Providers; confirm the env var is set and Bindery was restarted
Error 400: redirect_uri_mismatch with path prefix	BINDERY_OIDC_REDIRECT_BASE_URL includes a path (e.g. /bindery) but the registered URI doesn't	Register https://example.com/bindery/api/v1/auth/oidc/google/callback in Google Console
Access blocked: This app's request is invalid	OAuth consent screen not configured	Complete the consent screen setup in Google Cloud Console
After login, Bindery shows 500	Issuer URL mismatch — accounts.google.com vs https://accounts.google.com	Use https://accounts.google.com (with scheme) as the issuer in the provider config
User lands back at login with no error	state cookie expired before callback — common with slow consent flows	Try again; if it recurs, check that your reverse proxy isn't stripping Set-Cookie headers from the /api/v1/auth/oidc/ path

See also: Troubleshooting — OIDC | docs/auth-oidc.md