Login con Google OAuth para estudiantes — Profe Freddy

🔑 ¿Qué es el Login con Google?

El Login con Google permite que los usuarios accedan a tu aplicación usando su cuenta de Google, sin crear una contraseña nueva. Se basa en el estándar OAuth 2.0 y OpenID Connect (OIDC).

¿Por qué usarlo?

El usuario no necesita crear ni recordar contraseñas
La seguridad (2FA, detección de bots) la gestiona Google
Accedes al nombre, email y foto de perfil del usuario
Aumenta la conversión y reduce el abandono del registro
Protección automática contra fuerza bruta y phishing

¿Qué es OAuth 2.0?

Protocolo de autorización que permite a una app obtener acceso limitado a recursos de un usuario en otro servicio (Google, GitHub, Facebook…) sin necesitar su contraseña.

OpenID Connect (OIDC) se construye sobre OAuth 2.0 y agrega la capa de identidad del usuario (quién es, no solo qué puede hacer).

Paso 1 — Crear proyecto en Google Cloud Console

Ir a console.cloud.google.com
Crear o seleccionar un proyecto
Ir a APIs y servicios → Credenciales
Clic en "Crear credenciales" → "ID de cliente OAuth"
Tipo de aplicación: Aplicación web
Agregar http://localhost como origen autorizado (desarrollo)
Agregar tu dominio real en producción
Se generan: Client ID y Client Secret

Paso 2 — Implementar con Google Identity Services (JavaScript)

/* 1. Cargar la librería oficial de Google */
<script src="https://accounts.google.com/gsi/client" async></script>

/* 2. Elementos HTML para el botón */
<div id="g_id_onload"
     data-client_id="TU_CLIENT_ID.apps.googleusercontent.com"
     data-callback="manejarRespuesta"></div>
<div class="g_id_signin" data-type="standard"></div>

/* 3. Callback — recibe el ID Token */
function manejarRespuesta(response) {
  // response.credential es el ID Token (JWT)
  const payload = parseJwt(response.credential);
  console.log(payload.email);   // correo del usuario
  console.log(payload.name);    // nombre completo
  console.log(payload.picture);  // URL foto de perfil
  console.log(payload.sub);     // ID único del usuario
}

function parseJwt(token) {
  const base64 = token.split('.')[1];
  return JSON.parse(atob(base64));
}

Paso 3 — Verificar el token en el servidor (PHP)

// Recibir el ID Token desde el frontend (POST)
$idToken = $_POST['credential'];

// Verificar con la API de Google
$url      = "https://oauth2.googleapis.com/tokeninfo?id_token=" . urlencode($idToken);
$response = file_get_contents($url);
$data     = json_decode($response, true);

// Validar que el token sea para TU app
if (isset($data['aud']) && $data['aud'] === 'TU_CLIENT_ID.apps.googleusercontent.com') {
    $email  = $data['email'];
    $nombre = $data['name'];
    $foto   = $data['picture'];
    $sub    = $data['sub']; // ID único — úsalo como clave primaria

    session_start();
    $_SESSION['usuario'] = $email;
    // Crear o buscar el usuario en tu BD por $sub...
}

Scopes — qué información puedes solicitar

openid — Autenticación básica (siempre requerido)

email — Correo electrónico del usuario

profile — Nombre y foto de perfil

https://www.googleapis.com/auth/calendar — Google Calendar

https://www.googleapis.com/auth/drive — Google Drive

https://mail.google.com/ — Gmail

Tipos de tokens en OAuth 2.0

Token	Para qué sirve	Duración
Authorization Code	Código temporal que Google devuelve al redirigir al usuario	~10 min (un solo uso)
Access Token	Acceder a los recursos de la API (Calendar, Drive…)	~1 hora
ID Token (JWT)	Contiene la identidad del usuario (email, nombre, foto)	~1 hora
Refresh Token	Obtener nuevos access tokens sin re-autenticar al usuario	Largo plazo (revocable)

⚙️ Simulador del Flujo OAuth

Haz clic en Iniciar simulación para ver cómo funciona el proceso paso a paso.

Así luce el botón oficial de Google en tu aplicación:

👤

Tu App

→

🌐

Google OAuth

→

✅

Usuario autoriza

→

🎫

Código auth

→

🔐

Tokens

→

🏠

Sesión activa

Listo para comenzar. Haz clic en el botón de Google o en "Iniciar simulación" para ver el flujo OAuth 2.0 paso a paso.

⚖️ Pros y Contras del Login con Google

Antes de implementarlo, evalúa si es la decisión correcta para tu proyecto.

✅ Ventajas (Pros)

✔Sin contraseñas que recordar — el usuario entra con su cuenta de Google existente, cero fricción.
✔Seguridad delegada a Google — 2FA, detección de bots, alertas de actividad sospechosa y protección contra phishing quedan en manos de Google.
✔Tu app no almacena contraseñas — cero riesgo de filtración de hashes en tu base de datos.
✔Datos verificados del usuario — email, nombre y foto de perfil ya confirmados por Google.
✔Implementación rápida — con Google Identity Services (GIS) solo se necesitan ~10 líneas de código en el frontend.
✔Gratuito — dentro de las cuotas generosas de la API de Google (millones de solicitudes).
✔Mayor conversión — los formularios de registro tradicionales tienen alta tasa de abandono; un solo clic mejora la conversión.
✔Multiplataforma — funciona en web, Android, iOS y aplicaciones de escritorio.

❌ Desventajas (Contras)

✘Dependencia de Google — si Google cae o depreca su API, tu login falla. No controlas el uptime.
✘Privacidad del usuario — Google registra qué usuarios acceden a tu app y con qué frecuencia.
✘No todos tienen cuenta Google — usuarios mayores, en países con restricciones (China) o que prefieren privacidad quedan excluidos.
✘Configuración inicial confusa — Google Cloud Console puede intimidar a principiantes (proyectos, credenciales, orígenes autorizados…).
✘Límite de 100 usuarios en modo "Testing" — hasta que Google verifique tu app, solo los testers registrados pueden iniciar sesión.
✘Gestión de tokens — el Access Token expira en ~1 hora; necesitas lógica de refresh tokens para sesiones largas.
✘Bloqueado en algunas redes — firewalls corporativos, escolares o nacionales (China, Irán) pueden bloquear accounts.google.com.
✘SDKs adicionales en móviles — en Android e iOS se necesita integrar el SDK de Google Sign-In, que agrega dependencias al proyecto.

💡 ¿Cuándo SÍ usar Google Login?

Apps B2C con audiencia amplia, plataformas educativas, herramientas SaaS donde la mayoría de usuarios ya usan Google Workspace. Ideal cuando la conversión y la experiencia de usuario son prioridad.

⚠️ ¿Cuándo NO usarlo solo?

Apps para usuarios en China u otros países con bloqueo a Google. Sistemas donde la privacidad extrema es requisito. Plataformas para personas mayores sin cuenta Google. En estos casos, ofrece también login tradicional con email y contraseña.

🚧 ¿Por qué bloquean el Login con Google?

Hay dos tipos de bloqueos: técnicos (errores de configuración que tú puedes corregir) y externos (redes, políticas o países que bloquean Google). Aquí está cada uno con su solución.

🔧 Bloqueos técnicos — los puedes corregir

1. HTTP en lugar de HTTPS

Google OAuth solo funciona en producción con https://. Con http:// da el error "Not a valid origin".

✅ Solución: usa HTTPS con certificado SSL (Let's Encrypt es gratis) o trabaja en localhost para desarrollo.

2. redirect_uri_mismatch

El error más frecuente. La URL de redirección en el código no coincide exactamente con la registrada en Google Cloud Console. Un / de más, un puerto diferente o una mayúscula lo rompe.

✅ Solución: copia la URL exacta de tu app y pégala en "URI de redireccionamiento autorizados" en Cloud Console.

3. Origen JavaScript no autorizado

El dominio desde el que llamas a la API (localhost:8080 vs localhost:3000) debe estar registrado en "Orígenes de JavaScript autorizados".

✅ Solución: agrega el origen exacto (con puerto si aplica) en Google Cloud → Credenciales → tu Client ID.

4. App no verificada por Google

Las apps en modo "Testing" solo permiten hasta 100 usuarios registrados como testers. Los demás ven: "Esta aplicación no ha sido verificada".

✅ Solución: envía tu app a verificación en Google Cloud Console → OAuth Consent Screen → "Publish App".

5. Content Security Policy (CSP) restrictiva

Si tu servidor devuelve una cabecera CSP que no incluye accounts.google.com, el script de GIS no puede cargarse.

✅ Solución: agrega script-src 'self' https://accounts.google.com y frame-src https://accounts.google.com a tu CSP.

6. Bloqueadores de popups

Extensiones o configuraciones del navegador bloquean la ventana emergente de Google, interrumpiendo el flujo de autenticación.

✅ Solución: usa el flujo de redirección (redirect flow) en lugar del popup, o informa al usuario que permita popups de tu sitio.

7. Cookies de terceros bloqueadas

Safari y Firefox bloquean las cookies de terceros por defecto, y Chrome permite bloquearlas y restringe cada vez más su uso. Algunos flujos OAuth las necesitan para mantener el estado de la sesión.

✅ Solución: usa el flujo Authorization Code con PKCE que no depende de cookies de terceros.

8. Token expirado sin refresh

El Access Token dura ~1 hora. Si no implementas la renovación con Refresh Token, el usuario pierde acceso silenciosamente.

✅ Solución: solicita el scope offline_access para obtener Refresh Token y renueva automáticamente antes de que expire.

🔒 Bloqueos externos — fuera de tu control

🏢 Firewalls corporativos

Muchas empresas bloquean accounts.google.com en su red para controlar qué servicios usan los empleados o por políticas de seguridad.

🔄 Alternativa: ofrece login con email y contraseña como opción adicional.

🏫 Redes escolares y educativas

Los colegios filtran el tráfico para evitar distracciones o proteger a menores. Frecuentemente bloquean dominios de Google o solo permiten Google Workspace educativo.

🔄 Alternativa: integra Google Workspace for Education o usa autenticación con código de estudiante.

🌐 Países con censura (China, Irán, Rusia parcial)

En China, el Great Firewall bloquea completamente todos los servicios de Google. Los usuarios en esos países no pueden usar ningún login con Google.

🔄 Alternativa: detecta la región del usuario y ofrece proveedores locales (WeChat, Weibo en China) o login tradicional.

🔐 Políticas de privacidad (GDPR, Colombia 1581)

En la UE (GDPR) y Colombia (Ley 1581), el uso de servicios de terceros como Google Login requiere consentimiento explícito del usuario y declararlo en la política de privacidad.

✅ Solución: muestra el aviso de privacidad antes de activar el botón y documenta el tratamiento de datos.

📵 Usuarios sin cuenta Google o sin internet estable

Personas mayores, usuarios en zonas rurales con conexión inestable o quienes por principio no usan Google no podrán acceder si es el único método.

🔄 Alternativa: siempre ofrece un método de login alternativo (email/contraseña u otro proveedor).

💡 Regla de oro

Nunca hagas del Login con Google tu único método de autenticación. Úsalo como opción adicional junto a login tradicional para garantizar que todos los usuarios puedan acceder.

📚 Diccionario

OAuth 2.0

Protocolo de autorización que permite acceder a recursos de un usuario en otro servicio sin compartir su contraseña.

OpenID Connect (OIDC)

Capa de identidad construida sobre OAuth 2.0 que agrega autenticación del usuario.

Client ID

Identificador público de tu aplicación en Google Cloud. Se incluye en el código del frontend (no es secreto).

Client Secret

Clave privada de tu app. Solo se usa en el backend. Nunca se expone al navegador.

Scope

Permisos que tu app solicita al usuario. Ejemplos: openid, email, profile, calendar.

Authorization Code

Código temporal que Google devuelve al redirigir al usuario a tu app. Solo se usa una vez.

Access Token

Token para acceder a los recursos autorizados de la API de Google. Expira en ~1 hora.

ID Token (JWT)

Token que contiene la información del usuario (email, nombre, foto) codificado en JSON Web Token.

Refresh Token

Token de larga duración para obtener nuevos access tokens sin que el usuario vuelva a iniciar sesión.

JWT

JSON Web Token — estándar para transmitir información de forma segura. Tiene 3 partes: header.payload.signature en Base64.

Redirect URI

URL de tu app a la que Google redirige al usuario después de autorizar. Debe registrarse en Cloud Console.

Google Cloud Console

Panel donde se configuran el proyecto, las credenciales OAuth y las APIs habilitadas.

Consent Screen

Pantalla donde Google muestra al usuario qué permisos otorgará a tu app antes de autorizar.

GIS

Google Identity Services — librería JS oficial de Google para implementar Sign-In con un solo script.

PKCE

Proof Key for Code Exchange — extensión de OAuth para apps sin client secret (SPAs, móviles).

state

Parámetro de seguridad que tu app envía y Google devuelve para prevenir ataques CSRF en el flujo OAuth.

nonce

Valor único aleatorio para prevenir ataques de replay en el ID token.

sub (Subject)

ID único del usuario en Google. No cambia aunque el usuario cambie su email — úsalo como clave primaria en tu BD.

aud (Audience)

Client ID para el que fue emitido el token. Siempre verifica que coincida con tu Client ID.

exp (Expiration)

Claim del JWT que indica en qué timestamp Unix expira el token.

🎬 Videos

1. Login con Google usando JavaScript — OAuth 2 (en español)

2. ¿Qué es OAuth 2? Explicado en español

3. Autenticación OAuth 2.0 con Google — configuración completa

4. Entendiendo OAuth en 10 minutos — conceptos clave

📝 Cuestionario

10 preguntas aleatorias del banco de 50. Calificación de 0 a 100.