← Docs

Enterprise · At home

DIY: SSO & Sign-in with Google

You don’t need a corporate IdP to use Parleq’s OIDC sign-in. The same engine works for a single person on a free identity provider or a personal Google account — no per-user API keys, no long-lived cloud secret on disk.

Who this page is for: hobbyists and geeks wiring this up without an IT department — probably with an AI assistant open in another window. This stuff is fiddly, and the console UIs change constantly. So this page gives you the route map and the gotchas that burn hours; your assistant fills in the exact console-clicking for whatever the current UI looks like. The section at the bottom on working with your AI assistant is the intended workflow, not an afterthought.

Pick your path

Three routes, all roughly $0^† — Cognito’s free tier (10,000 monthly active users on the default Essentials plan), OAuth, STS, and Workforce Identity Federation carry no service charge at personal scale. You pay only for the LLM tokens you use. Start at the top.

Choose A unless you have a specific reason not to. Choose B if you want Bedrock (Claude / GPT-OSS) and are comfortable in the AWS console. Choose C only if you specifically want the federation architecture — it needs a GCP org, which is the single biggest step on this whole page.

Path A — Sign in with Google → Vertex

“Sign in with Google, dictate with Gemini.” No broker, no Workforce Identity Federation, no gcloud CLI. GCP refuses to accept Google itself as a workforce IdP, so federation can’t do this — instead Parleq’s own Google sign-in requests the cloud-platform scope, and the resulting OAuth access token is a valid Vertex bearer directly (exactly what gcloud ADC produces, done in-app). No GCP organization required.

1. 1.

   Create a GCP project and enable the Vertex AI API.

   Any project works. Enable Vertex AI API from the API Library, and note the Project ID (the ID, not the display name).

2. 2.

   Create an OAuth client — of the iOS type.

   This is the non-obvious one. Parleq’s sign-in uses a custom-scheme redirect, so create an iOS-type OAuth client (public, no secret) and use its reversed client ID as the redirect scheme. A Desktop-type client with a loopback redirect is on the roadmap but not the path today.

3. 3.

   Grant IAM on the project.

   The signing account needs roles/aiplatform.user and roles/serviceusage.serviceUsageConsumer on the project. If you’re the project Owner, you already have both.

4. 4.

   Write the config.

{
  "oidc": {
    "issuer": "https://accounts.google.com",
    "client_id": "123456789-abc.apps.googleusercontent.com",
    "scopes": ["openid", "email", "https://www.googleapis.com/auth/cloud-platform"],
    "redirect_uri": "com.googleusercontent.apps.123456789-abc:/oauth2redirect",
    "extra_auth_params": { "access_type": "offline", "prompt": "select_account consent" }
  },
  "vertex": {
    "project": "your-project",
    "region": "us-central1",
    "auth_mode": "googleOAuth"
  }
}

Why "prompt": "select_account consent" is the default to use, not just "consent": select_account prevents a dead-end where Google silently reuses whatever account is active in the browser and hard-blocks the sign-in without ever showing an account picker. consent guarantees Google re-issues a refresh token (it only does so when it shows the consent screen). Together they make sign-in reliable across the consent-screen modes below.

The consent-screen trilemma

This is the #1 source of confusion. Your OAuth consent screen is in one of three publishing states, and each has a different trade-off:

• • Testing mode — works immediately, but refresh tokens expire every 7 days. You’ll re-sign-in roughly weekly. Fine for kicking the tires.
• • Published / External — refresh tokens persist, but because cloud-platform is a restricted scope an unverified personal client shows an “unverified app” interstitial. Click Advanced → continue; harmless for a personal client. Why does a stranger who somehow got your client ID gain nothing? The tokens belong to whoever signs in, and the IAM grant is on your project — their token can’t touch it. Worst case, Google suspends a client that’s being abused.
• • Internal — the clean endgame: no warning, no token cap, no expiry, and outsiders are hard-blocked. But it requires putting the project in a Google Cloud organization (Cloud Identity Free + a domain you own), and you then sign in with an org account, not @gmail.com.

Pragmatic call: start in Testing to prove it works, then go Internal only if you already want a GCP org for other reasons. Otherwise Publish (External) and click past the warning if weekly re-sign-in annoys you — it’s your own client; see why that’s safe above.

Path B — Cognito → AWS Bedrock

A free Amazon Cognito user pool becomes your personal OIDC issuer; an IAM role trusts it via AssumeRoleWithWebIdentity. Cognito gives you an AWS-hosted public issuer with a publicly-fetchable JWKS, so the AWS leg works with nothing exposed to the internet yourself. The free tier^† covers far more monthly active users than a single person will ever use — but note the tiers: 10,000 MAU free is the default Essentials plan, the Plus plan has no free tier, and SAML/OIDC-federated users get only 50 free MAU (aws.amazon.com/cognito/pricing).

• • Create a user pool and add an app client of the public client type (no secret), with the authorization-code grant and a callback of parleq-auth://oidc/callback.
• • Scopes: ["openid", "email"]. Don’t add profile — the wizard-created client usually doesn’t enable it, and requesting it makes Cognito error-redirect instantly (the symptom is a window that flashes open and shut; see troubleshooting). Cognito also rejects offline_access but still issues a refresh token from the auth-code grant.
• • In IAM, register an OIDC identity provider for the pool issuer (https://cognito-idp.<region>.amazonaws.com/<pool-id>) with the app client ID as an audience.
• • Create a role whose trust policy admits that provider via AssumeRoleWithWebIdentity with an aud condition equal to the client ID. Attach a permissions policy granting bedrock:InvokeModel*.
• • Config: aws.auth_mode = oidc, plus aws.role_arn and aws.region.

{
  "oidc": {
    "issuer": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_EXAMPLE",
    "client_id": "EXAMPLEcognitoclientid",
    "scopes": ["openid", "email"]
  },
  "aws": {
    "region": "us-east-1",
    "auth_mode": "oidc",
    "role_arn": "arn:aws:iam::<account>:role/ParleqDictation"
  }
}

The trust-policy and permissions-policy shapes are in Enterprise SSO → AWS Bedrock setup — the same JSON, just with your Cognito issuer as the federated principal.

Path C — Cognito → GCP Workforce Federation → Vertex Advanced

This is the full federation architecture for Vertex, and the heaviest path on the page. Choose it only if you specifically want workforce federation — Path A reaches Vertex with far less ceremony. The blocker is that Workforce Identity Pools are an Organization-level GCP resource, so you need a Google Cloud org first.

• • Build the Cognito pool exactly as in Path B (it’s your issuer for both clouds).
• • Get a GCP organization: sign up for Cloud Identity Free with a domain you own and complete the DNS TXT verification. This is the real work in Path C. (Cloud Identity Free is free for up to 50 users; the domain you verify is a separate ~$10–15/yr registrar charge.^†)
• • Create a workforce pool and add an OIDC provider for the Cognito issuer. The issuer URI must be public HTTPS — a localhost IdP cannot work here even if you upload the JWKS inline. Cognito is public HTTPS, so it’s fine.
• • Grant roles/aiplatform.user to the workforce-pool principalSet (scope it tighter by attribute if you can).
• • Config: vertex.auth_mode = oidcFederation, plus vertex.workforce_provider (locations/global/workforcePools/<pool>/providers/<provider>) and vertex.project.

Full workforce-pool details (attribute mapping, the x-goog-user-project billing requirement) are in Enterprise SSO → Google Cloud Vertex AI setup.

Working with your AI assistant

This page is the map; your assistant is the turn-by-turn navigation. The console UIs move around too fast for any doc to keep exact click paths current, but an assistant can generate them for whatever you’re looking at right now.

• • Paste this page in and tell it which path (A, B, or C) you picked. Ask it to generate the exact console steps for the current UI.
• • Capture as you go: the client ID, the redirect URI, the role ARN, pool / provider resource names, and the project ID. These are the values the config wants and the values your assistant will keep asking for.
• • Paste exact error text back in. Most failures here have a precise cause; the literal error string is what lets the assistant pinpoint it.
• • Use the connection doctor. Parleq’s Settings → Company Account → Test connection tells you which hop failed (IdP / token exchange / provider) with the server’s reason — exactly the detail your assistant needs to fix it. Feed that output in verbatim.

Troubleshooting

† Third-party pricing, free tiers, and quotas are set by the providers — AWS, Google, Microsoft, Okta, and others change them without notice. Cost statements here were accurate when written; verify current rates on the provider's pricing page before you build.