Acceso con Google, paso a paso

Esta página explica, sin dar nada por sabido, cómo conseguir las dos claves que hacen funcionar el botón «Iniciar sesión con Google» del Panel de Administración.

No hace falta saber nada de Google Cloud. Son unos diez minutos, es gratis, y no hay que dar ninguna tarjeta.

Qué vamos a hacer, en una frase

Google no deja que un programa cualquiera le pida la identidad de sus usuarios. Antes hay que registrar el programa en Google y decirle a dónde puede devolver al usuario cuando termine de identificarse. A cambio, Google entrega dos textos largos:

Lo que da Google	Qué aspecto tiene	Dónde va
Client ID	`4712...-a1b2c3.apps.googleusercontent.com`	`GOOGLE_CLIENT_ID`
Client secret	`GOCSPX-a1b2c3d4e5f6...`	`GOOGLE_CLIENT_SECRET`

Todo el trabajo consiste en conseguir esos dos textos y pegarlos en el archivo .env del sistema.

Esto no arregla el acceso del Contador

El Contador (Smart Meter) entra por otro camino —un servicio externo llamado Zertiauth— y no usa estas claves. Lo que configures aquí afecta sólo al Panel de Administración. Ver Contador / Smart Meter.

Antes de empezar

Necesitas dos cosas:

Una cuenta de Google. Cualquier @gmail.com sirve. Si es la cuenta de tu organización (Google Workspace), mejor todavía: más abajo verás por qué.
Saber en qué dirección responde tu backend. En una instalación local es http://localhost:3000. Si lo has desplegado en un servidor, es la dirección pública de la API, por ejemplo https://api.tudominio.com.

Apunta este valor, lo vas a necesitar dos veces

La dirección del backend, con /oauth/google-callback pegado al final:

http://localhost:3000/oauth/google-callback

Esto se llama la URI de retorno. Es el error número uno de esta configuración, así que ojo con el paso 4.

Paso 1 — Entrar en la consola de Google

Abre esta dirección e inicia sesión con tu cuenta de Google:

👉 https://console.cloud.google.com/

La primera vez, Google te pedirá aceptar sus condiciones y elegir un país. Si te ofrece una prueba gratuita con tarjeta de crédito, dile que no: nada de lo que vamos a hacer se cobra.

Paso 2 — Crear un proyecto

Un «proyecto» es sólo una carpeta donde Google guarda esta configuración.

Arriba del todo, junto al logotipo de Google Cloud, hay un desplegable con el nombre del proyecto actual (si acabas de entrar, pondrá algo como Selecciona un proyecto). Púlsalo.
En la ventana que se abre, arriba a la derecha: Proyecto nuevo.
Ponle un nombre que reconozcas —Zertipower, por ejemplo— y pulsa Crear.
Espera unos segundos y asegúrate de que el desplegable de arriba muestra tu proyecto nuevo. Si sigue mostrando otro, púlsalo y selecciona el tuyo.

Es el fallo tonto más habitual

Si creas el proyecto pero luego trabajas sin haberlo seleccionado, acabarás configurando el proyecto equivocado y nada funcionará. Comprueba el desplegable de arriba antes de seguir.

Paso 3 — Configurar la pantalla de consentimiento

La «pantalla de consentimiento» es lo que ve el usuario cuando Google le pregunta «¿Le das permiso a esta aplicación para ver tu nombre y tu correo?». Google obliga a configurarla antes de dejarte crear las claves.

Ve a:

👉 https://console.cloud.google.com/auth/overview

Y pulsa Empezar (o Comenzar).

Si la consola no se parece a esto

Google cambia el nombre de este apartado cada cierto tiempo. Puede aparecer como Plataforma de autenticación de Google, o dentro de APIs y servicios → Pantalla de consentimiento de OAuth. Busca esas palabras: el contenido es el mismo.

Te pedirá cuatro cosas:

Nombre de la aplicación. Lo que verá el usuario. Por ejemplo Zertipower.
Correo de asistencia. El tuyo. Sale en la pantalla de permisos.

Público (Audience). Aquí hay que elegir, y la elección importa:

Opción	Quién puede entrar	Cuándo elegirla
Interno	Sólo cuentas de tu organización de Google Workspace	Si tenéis Workspace. Es la opción recomendada. No hay que añadir a nadie a mano.
Externo	Cualquier cuenta de Google… pero sólo las que añadas como usuarios de prueba	Si usas un `@gmail.com` normal. Google no te dará a elegir «Interno».

Datos de contacto. Otra vez tu correo, para avisos de Google.

Acepta las condiciones y pulsa Crear.

Si has elegido «Externo», añade tu cuenta como usuario de prueba

Este paso se olvida constantemente y provoca que Google bloquee el acceso con un mensaje que no explica nada.

En el menú de la izquierda, entra en Público (Audience).
Baja hasta Usuarios de prueba (Test users).
Pulsa Add users / Añadir usuarios, escribe la dirección de correo con la que vas a entrar, y Guardar.

Repite esto por cada persona que vaya a usar el acceso con Google.

No pulses «Publicar aplicación» a la ligera

Mientras la aplicación esté en pruebas, sólo entran los correos de esa lista. Eso es una protección, no un estorbo.

Si la publicas, cualquier persona del mundo con una cuenta de Google podrá entrar — y este sistema crea la cuenta automáticamente en el primer acceso, con permisos amplios. Léete el aviso del final de esta página antes de publicar nada.

Paso 4 — Crear el cliente de OAuth

Ahora sí, las claves.

En el menú de la izquierda, entra en Clientes (Clients). O ve directo a 👉 https://console.cloud.google.com/auth/clients
Arriba: Crear cliente (Create client).
Tipo de aplicación: elige Aplicación web (Web application). No «Escritorio», no «Android». Aplicación web.
Nombre: lo que quieras, sólo lo ves tú. Panel Zertipower, por ejemplo.
Baja hasta URI de redireccionamiento autorizados (Authorized redirect URIs) y pulsa Añadir URI.
Pega exactamente esto (el valor que apuntaste al principio):
```
http://localhost:3000/oauth/google-callback
```
Pulsa Crear.

El error número uno: poner aquí la dirección del Panel

La URI de retorno es la del backend (puerto 3000), no la del Panel (puerto 4201). El usuario acaba en el Panel, sí, pero Google habla primero con el backend, y es el backend quien luego lo manda al Panel.

Si pones http://localhost:4201/... o cualquier otra cosa, Google responderá redirect_uri_mismatch y no habrá manera.

Tiene que coincidir carácter por carácter

Google compara el texto entero, sin perdonar nada:

http:// y https:// son distintos.
localhost y 127.0.0.1 son distintos.
El puerto cuenta: :3000 no es lo mismo que sin puerto.
Una barra / de más al final lo rompe.

Este valor tiene que ser idéntico al de la variable GOOGLE_CALLBACK_URL del sistema. Si no has tocado nada, es el de arriba.

Paso 5 — Copiar las dos claves

Al pulsar Crear, Google abre una ventana con Client ID y Client secret. Son los dos textos que necesitas.

Cópialos ahora, a un bloc de notas, los dos.
Hay un botón de copiar junto a cada uno; úsalo, no los transcribas a mano.

Si cierras la ventana sin copiar el secreto

No pasa nada grave, pero el secreto ya no se puede volver a ver. Entra en Clientes, pulsa tu cliente, y en Secretos del cliente crea uno nuevo con Añadir secreto. El Client ID sí se puede consultar siempre.

Paso 6 — Poner las claves en el sistema

Hay dos maneras. La primera es más cómoda.

Opción A — Que te lo pregunte el instalador

Vuelve a ejecutar el instalador. Detecta que faltan y te las pide, sin tocar el resto de la configuración:

./setup.sh

En Windows, setup.bat.

Opción B — Editarlo a mano

Abre el archivo .env que hay junto al docker-compose.yml —si no existe, créalo— y añade estas dos líneas con tus valores:

GOOGLE_CLIENT_ID='4712...-a1b2c3.apps.googleusercontent.com'
GOOGLE_CLIENT_SECRET='GOCSPX-a1b2c3d4e5f6...'

Las comillas simples no son decorativas

En un archivo .env, un $ o una # sin comillas cambian el significado de la línea. Pon los valores entre comillas simples y te ahorras el problema.

El .env no se sube nunca a git

Ya está en .gitignore, así que no tendrías que hacer nada. Pero si alguna vez copias este archivo a algún sitio, recuerda que el secret es una credencial real. Ver Gestión de secretos.

Paso 7 — Reiniciar y probar

El backend lee la configuración al arrancar, así que hay que reiniciarlo. No hace falta reconstruir nada:

./dev.sh up -d backend

Ahora:

Abre el Panel: http://localhost:4201
Pulsa «Iniciar sesión con Google».
Google te pedirá elegir cuenta y dar permiso. Acepta.
Deberías volver al Panel, ya dentro.

Si sale un aviso de «Google no ha verificado esta aplicación», es normal en una aplicación en pruebas: pulsa Configuración avanzada → Ir a … (no seguro). Lo dice porque la aplicación es tuya y nadie la ha revisado, no porque haya nada malo.

Si algo falla

Casi siempre es una de estas cinco. El texto que enseña Google dice cuál:

Lo que dice Google	Qué ha pasado	Cómo se arregla
Falta `client_id`, o error 400	`GOOGLE_CLIENT_ID` está vacío	Repite el paso 6: no se ha guardado
`redirect_uri_mismatch`	La URI del paso 4 no es idéntica a `GOOGLE_CALLBACK_URL`	Compáralas carácter por carácter. ¿Pusiste el puerto 4201 en vez del 3000?
`invalid_client`	El ID y el secreto no son del mismo cliente, o el secreto está mal copiado	Vuelve a copiarlos, los dos, del mismo cliente
`deleted_client`	Estás usando el identificador antiguo, que Google borró	Crea el tuyo siguiendo esta página
«Acceso bloqueado» / `access_denied`	Aplicación Externa en pruebas, y esa cuenta no está en la lista	Paso 3: añádela como usuario de prueba

Después de cambiar el .env, reinicia el backend o seguirás viendo el comportamiento anterior:

./dev.sh up -d backend

Mientras tanto, siempre puedes entrar con admin / admin123: ese acceso no depende de Google y funciona desde el primer arranque.

Dos avisos que conviene leer

Quien entra con Google se crea una cuenta solo

La primera vez que alguien entra con Google, el sistema le crea un usuario automáticamente, con el rol USER. En la base de datos de ejemplo ese rol tiene 203 permisos: no es un invitado mirando, es una cuenta con acceso a buena parte del Panel.

Por eso importa tanto la elección del paso 3:

Interno → sólo tu organización. Controlado.
Externo, en pruebas → sólo los correos de tu lista. Controlado.
Externo, publicado → cualquiera con una cuenta de Google. Descontrolado.

No publiques la aplicación salvo que de verdad quieras registro abierto, y si lo haces, revisa antes qué permisos tiene el rol USER.

En producción hace falta otro cliente

El cliente que acabas de crear apunta a localhost. Para un servidor de verdad hay que añadir —en el mismo cliente o en otro— la URI de retorno pública:

https://api.tudominio.com/oauth/google-callback

Y poner esa misma dirección en GOOGLE_CALLBACK_URL. Ten en cuenta que, fuera de localhost, Google sólo acepta https://, no http://, ni direcciones IP. Ver Desplegar en un servidor nuevo.

Qué vamos a hacer, en una frase​

Antes de empezar​

Paso 1 — Entrar en la consola de Google​

Paso 2 — Crear un proyecto​

Paso 3 — Configurar la pantalla de consentimiento​

Si has elegido «Externo», añade tu cuenta como usuario de prueba​

Paso 4 — Crear el cliente de OAuth​

Paso 5 — Copiar las dos claves​

Paso 6 — Poner las claves en el sistema​

Opción A — Que te lo pregunte el instalador​

Opción B — Editarlo a mano​

Paso 7 — Reiniciar y probar​

Si algo falla​

Dos avisos que conviene leer​

Quien entra con Google se crea una cuenta solo​

En producción hace falta otro cliente​