Permitir que los visitantes de tu API inicien sesión con Google (inicio de sesión OIDC)

Esto trata sobre que tu API publicada permita que sus PROPIOS visitantes inicien sesión, "Iniciar sesión con Google" para los usuarios de tu aplicación, no sobre que tu API llame a otro servicio (esa es la opción OAuth2 independiente que ya existe en el bloque Call External API, y no se ve afectada por nada de esto).

Cómo se encajan las piezas

Completar una redirección de inicio de sesión del navegador es trabajo de tu propio frontend, la aplicación o sitio que llama a tu API ya tiene un botón "Iniciar sesión con Google" conectado a través del propio SDK de Google, y termina ese flujo con un token de ID. El trabajo de tu endpoint empieza después de eso: recibe el token y verifica que es genuino antes de confiar en nada de lo que afirma.

Construyéndolo

1. Crea el endpoint que tu frontend llamará después del inicio de sesión (un POST es lo habitual).
2. Añade un bloque OIDC Login. Deja la fuente del token como Authorization: Bearer header si tu frontend lo envía así, o cámbiala a un campo del cuerpo.
3. Completa la audience esperada, el ID de cliente OAuth de Google, sin esto configurado correctamente, un token emitido para una aplicación completamente diferente podría pasar la verificación.
4. Conecta la salida "Verified" a lo que tu aplicación necesite a continuación, normalmente una Database Query que busca o crea un registro con clave {{oidcSub}} (el id de usuario estable del proveedor). Conecta "Invalid" a un bloque Error Response, estado 401.

Si tiene éxito, el bloque expone {{oidcSub}}, {{oidcEmail}}, {{oidcEmailVerified}}, y {{oidcName}} (cambia el prefijo "oidc" en el propio panel del bloque si prefieres nombrarlos de otra forma) para que el resto de tu grafo los use, guarda un registro con alcance a ese usuario, emite tu propio token de sesión, lo que tu aplicación necesite.

Qué es compatible realmente

Google, y cualquier otro proveedor que publique un documento de descubrimiento estándar de OpenID Connect (en una URL .well-known/openid-configuration), son compatibles. Un proveedor sin uno no lo es, esto deliberadamente no intenta adivinar un formato de token específico de un proveedor que no puede verificar correctamente.