🔓 Login con Google, paso a paso
Pulsas «Iniciar sesión con Google» y, sin darle tu contraseña a la app, acabas dentro. Detrás hay un baile de redirecciones y un code que se canjea por tokens — con dos defensas clave: PKCE y state. Recórrelo paso a paso (Authorization Code + PKCE).
El flujo, paso a paso
-
01 PKCE en tu app
Tu app prepara PKCE
Antes de nada, la app genera un secreto aleatorio, el code_verifier, y su huella code_challenge = SHA-256(verifier). El verifier se queda en la app; solo saldrá al final.
La huella viaja ahora; el secreto, al final. Nadie que intercepte el camino puede recomponerlo. -
02 Authorization Request mensaje
Redirección a Google
El navegador va a Google con client_id, redirect_uri, scope (qué pide), un state aleatorio y el code_challenge. Es el canal frontal (por el navegador).
Aquí no viaja ninguna contraseña ni token: solo una petición firmada por la configuración de la app. -
03 Login + consent en Google
Te autenticas y consientes
En la pantalla de Google (no en la app) inicias sesión y apruebas los permisos que pide la app: «¿Permites a esta app ver tu perfil y tu email?».
Tu contraseña la ve solo Google, nunca la app. Ese es el punto de OAuth: delegar sin compartir credenciales. -
04 Redirect + code mensaje
Vuelta con el «code»
Google redirige el navegador de vuelta a tu redirect_uri con un authorization code de un solo uso y el mismo state.
El code pasa por la URL, pero por sí solo no vale: hay que canjearlo con el verifier. No es el token. -
05 state check en tu app
La app verifica el «state»
La app comprueba que el state devuelto es exactamente el que envió al principio.
Esto ata la respuesta a tu petición: es la defensa contra CSRF (que te cuelen una autorización ajena). -
06 Token Request 🔒 mensaje
Canjea el code por tokens
Ahora por el canal trasero (servidor a servidor, o directo con PKCE): la app hace un POST al endpoint de token con el code y —por fin— el code_verifier original.
Es la primera vez que el verifier sale. Si la app tiene client_secret, también va aquí, nunca por el navegador. -
07 PKCE verify en Google
Google valida el PKCE
Google calcula SHA-256(code_verifier) y comprueba que coincide con el code_challenge del paso 2. Solo cuadra si quien canjea es quien pidió.
Aunque un atacante robara el code, sin el verifier no puede canjearlo. Eso es lo que aporta PKCE. -
08 Tokens 🔒 mensaje
Tokens: ya sabe quién eres 🔒
Google devuelve un access_token (para llamar a su API) y, en «Login con Google» (OpenID Connect), un id_token (un JWT con tu identidad). Sesión iniciada.
El id_token dice quién eres; el access_token, qué puede hacer la app. No los confundas.
Sin JavaScript verás el flujo completo como artículo. Con JS, recórrelo paso a paso (también con las flechas ← →).
🔑 PKCE: el secreto que llega tarde
La app manda primero la huella (code_challenge) y guarda el secreto (code_verifier) hasta el final. Aunque roben el code por el navegador, sin el verifier no se canjea. Imprescindible en apps móviles y SPA (sin client_secret).
🛡️ state: contra el CSRF
Un valor aleatorio que va en la ida y tiene que volver igual. Ata la respuesta a tu petición: sin él, un atacante podría hacer que inicies sesión con su cuenta (o al revés).
🎫 id_token ≠ access_token
El id_token (OpenID Connect) dice quién eres — es un JWT que tú validas. El access_token dice qué puede hacer la app contra la API. Y por eso el implicit flow (token directo en la URL) está desaconsejado: usa siempre el code.
Fuentes: RFC 6749 (OAuth 2.0) · RFC 7636 (PKCE). ¿Te ha tocado un id_token? Ábrelo y audítalo en el auditor de JWT.