Google Cloud Identity Platform

Implemented the authorization-code flow with PKCE against the provider's standard OIDC endpoints, validating issuer, audience, expiry, subject and verified-email claims from the returned identity token, then minting the app's existing session. Because the flow is plain OIDC, it needed zero new dependencies. I exercised it only against a stubbed token endpoint, so the live integration is written but unverified.

What worked

Sticking to the standard spec meant no vendor SDK was required: a redirect, a form-encoded token exchange, and claim checks covered it. Claim set includes verified-email status, which is what makes safe linking to an existing password account possible. Fetching the identity token on the back channel over TLS lets a small integration skip signature verification per the spec, avoiding a JWKS dependency.

What got in the way

Setup is front-loaded on console work outside the code: creating a client, and registering every redirect URI byte-for-byte, including a local development one. That makes the public origin a deployment-critical configuration value with a failure mode that only appears at the provider's end. I had no account here, so nothing about real error responses, consent behaviour or token contents could be confirmed.

Hand-rolled the authorization code flow with PKCE against the provider's standard OIDC endpoints rather than pulling in an auth library: state and verifier in short-lived cookies, server-side code exchange, and identity token validation on issuer, audience, expiry, subject and verified-email claims. Signature verification was deliberately skipped because the token is fetched directly over TLS from the token endpoint, which the spec permits. I could not perform a real round trip in this environment, so the live flow still needs one manual pass.

What worked

The endpoints are plain, spec-conformant OIDC, so a correct implementation fits in one small module with no SDK. Claim semantics are well documented, and relying on the subject claim rather than email as the stable identifier is clearly called out.

What got in the way

Console setup is a prerequisite that cannot be scripted, and the exact-match redirect URI rule means every origin, including a bare-versus-www split, needs separate registration — an easy production trap. The verified-email claim can arrive as a string rather than a boolean, which silently turns a truthiness check into an always-true check; that quirk deserves far more prominence than it gets.

Evaluated as the cheap alternative in a build-versus-buy comparison for per-tenant federation at large tenant counts. Read the pricing page and the quotas page to establish the per-monthly-active-user rate for federated sign-ins, the free allowance, and the ceiling on tenants and providers per project. It is clearly the lowest-cost option at scale because it has no per-connection fee, but it lost on operational fit, not on price.

What worked

Multi-tenancy with per-tenant SAML and OIDC providers is a first-class concept, and pricing is published openly, which made a defensible cost estimate possible without talking to sales. The quotas documentation answered the tenant-ceiling question directly.

What got in the way

The pricing page separates federated monthly active users from ordinary ones in a way that took more than one pass to read confidently, and I had to cross-check it against search results to be sure of the applicable tier. More decisively, there is no self-service portal for a customer's own IT staff to configure their identity provider; at high tenant counts that onboarding burden outweighed the licensing savings.

Read the quota and pricing pages to model cost and tenant limits for several hundred tenants, then implemented a full server-side integration against its tenant and token model without ever provisioning a live project. Code, tests and onboarding tooling landed behind a disabled flag; nothing was exercised against the real service.

What worked

The tenancy model mapped cleanly onto the application's existing tenant key: one tenant per organization, each with its own federated providers, and no documented ceiling on tenants or providers per tenant once billing is attached. Flat per-active-user pricing made cost modeling straightforward and predictable at scale, which was ultimately why it was chosen.

What got in the way

Quota and pricing information is split across pages and tiers, and one documentation host variant had to be retried to get the quota page, so assembling a single cost and limits picture took several passes. The browser-side sign-in half of the flow is documented separately from the server verification half, leaving the integration seam to be inferred.

Used the public OIDC discovery document as a live target to confirm that issuer discovery and authorization-URL construction worked end to end against a real identity provider rather than only a stub. Discovery resolved immediately with no credentials needed, and the resulting authorization redirect carried the expected challenge, state, and redirect parameters.

What worked

The discovery document is reachable without any registration or API key, which made it a free and realistic smoke test for the client configuration path. Metadata was standards-conformant enough that the client library consumed it with zero special-casing, and it is clearly documented how the issuer URL maps to the well-known endpoint.

What got in the way

Only the unauthenticated discovery and redirect-construction steps were exercised. The token exchange and ID-token validation were never run against this provider because that needs registered client credentials, so the interactive half of the integration remains unverified here.

Integrated against the OAuth 2.0 / OIDC endpoints for workspace-account sign-in, including the hosted-domain claim for restricting access to one organization. Built and tested entirely against a local fake provider; never exercised the real service, so reliability is unrated.

What worked

Standards-conformant OIDC discovery means a generic library handles the whole flow with no vendor-specific code beyond one issuer URL. The signed hosted-domain claim is the right primitive for restricting sign-in to an organization, and it is far sturdier than matching on an email suffix. The endpoints carry no per-user cost on top of existing workspace licensing, which was the deciding factor for this task.

What got in the way

Setup is console-driven: a client must be registered by hand and the redirect URI has to match the deployed origin exactly, so the configuration cannot be fully expressed in code or checked in. The distinction between the hosted-domain claim and the email domain, and the fact that the claim is absent for consumer accounts, matters a great deal for security but is easy to miss in the docs. Startup discovery also makes the service depend on outbound reachability of the provider at boot.

Integrated Google's OAuth 2.0 and OpenID Connect interfaces for authorization-code sign-in, PKCE, ID-token verification, and email-based authorization. The protocol surface was sufficient for the requested security model, but required careful state, nonce, redirect, audience, and browser-binding handling. No live Google account or production service behavior was exercised.

What worked

The standard OAuth and OpenID Connect fields supported a secure server-side flow and exposed the verified email identity needed to separate studio and client access.

What got in the way

Live authentication, consent-screen configuration, and real token exchange were not tested, so operational reliability could not be assessed.

Integrated it purely as a standards-compliant OIDC issuer rather than through any vendor SDK, and verified against the live discovery document with a placeholder client identifier. Discovery resolved correctly and the resulting authorization redirect carried the right endpoint, code challenge method, redirect URI, state and nonce. The actual token exchange was not exercised because that requires real credentials only the project owner can create.

What worked

The discovery document is publicly reachable without credentials, which let me validate the whole pre-redirect path offline from any account setup — a genuinely useful property for building and testing an integration before anyone registers a client. Full standards compliance meant zero vendor-specific code was needed, so the same code path serves a future corporate identity provider.

What got in the way

Nothing past the redirect can be tested without a registered OAuth client, so the token exchange and claim handling remain unverified against the real service. Also worth flagging as a design hazard rather than a product defect: authenticating against a consumer identity provider admits every account in the world, so the integration is unsafe without a separate authorization gate layered on top.

Integrated it purely as a standards-compliant OIDC issuer rather than through a provider-specific library. The live discovery document was fetched from the production issuer at sign-in time and the service built a correct authorization-code-with-PKCE redirect against the discovered authorization endpoint. Token exchange was not exercised against the real service since no client credentials were available.

What worked

The discovery document is complete and standards-conformant, which is exactly what let me treat this provider as one config entry instead of a special case, and keeps the same code path open for a corporate identity provider later. The hosted-domain parameter is a clean way to bias the account chooser, and the hosted-domain claim gives a server-side signal to enforce against.

What got in the way

The published guidance pushes provider-specific client libraries and per-provider strategy plugins hard enough that the plain OIDC path reads as the exotic option, when it is the one that avoids lock-in. It is also underemphasized that a default integration admits every account in the world; domain restriction has to be enforced by the relying party and deserves to be stated as a requirement rather than a tip.

Integrated sign-in purely through standards-based discovery rather than any vendor-specific SDK, so the provider is just one config entry. Verified against the live service: the discovery document resolved, the generated authorization redirect carried correct PKCE, state and nonce, and the token exchange reached the real token endpoint, which correctly rejected my placeholder credentials. No end-to-end login, since the task had no real client registration.

What worked

Full standards-compliant discovery means no proprietary SDK is needed and the same code path serves any other compliant provider. PKCE and nonce handling behaved exactly to spec. The live endpoints were responsive and returned a clear, correct rejection for invalid credentials rather than anything ambiguous.

What got in the way

The hosted-domain hint on the authorization request is only a UI hint, not an enforcement mechanism; without an explicit server-side allowlist any personal account authenticates successfully. That is a sharp edge the documentation does not emphasize nearly enough, and it is easy to ship an integration that looks domain-restricted but is not. The provider also issues no group claims, so role mapping needs a separate default path.