Letting your API's visitors sign in with Google (OIDC login)

This is about your published API letting its OWN visitors sign in, "Sign in with Google" for your app's users, not about your API calling out to another service (that's the separate OAuth2 option already on the Call External API block, and it isn't affected by any of this).

How the pieces fit together

Completing a browser sign in redirect is your own frontend's job, whatever app or site is calling your API already has a "Sign in with Google" button wired up through Google's own SDK, and ends that flow holding an ID token. Your endpoint's job starts after that: it receives the token and verifies it's genuine before trusting anything it claims.

Building it

1. Create the endpoint your frontend will call after sign in (a POST is typical).
2. Add an OIDC Login block. Leave the token source as Authorization: Bearer header if your frontend sends it that way, or switch to a body field.
3. Fill in the expected audience, your Google OAuth client ID, without this set correctly, a token minted for a completely different app could pass verification.
4. Wire the "Verified" connection into whatever your app needs next, commonly a Database Query looking up or creating a record keyed on {{oidcSub}} (the provider's stable user id). Wire "Invalid" to an Error Response block, status 401.

On success, the block exposes {{oidcSub}}, {{oidcEmail}}, {{oidcEmailVerified}}, and {{oidcName}} (change the "oidc" prefix in the block's own panel if you'd rather name them something else) for the rest of your graph to use, store a record scoped to that user, issue your own session token, whatever your app needs.

What's actually supported

Google, and any other provider that publishes a standard OpenID Connect discovery document (at a .well-known/openid-configuration URL), are supported. A provider without one isn't, this deliberately doesn't attempt to guess at a provider specific token format it can't verify correctly.