Recuerdo que hace un año estaba mirando la página de inicio de sesión de un gran proyecto y pensé: «Dios, ¿cómo funciona todo esto?» Cuatro botones para iniciar sesión, algunos tokens, redirecciones... ¡Qué lío! Hoy lo analizaremos todo para que no te ahogues en este mar de tecnología.
Por qué la autorización no es solo «introducir una contraseña» 🔐
En 2026, los usuarios quieren iniciar sesión en las aplicaciones de forma rápida, segura y sin dolores de cabeza. Algunos prefieren el correo electrónico y la contraseña clásicos, otros prefieren un botón «Iniciar sesión con Google», otros quieren recibir un código por SMS y no molestarse con las contraseñas.
Tu tarea como desarrollador es darles todo esto, y de tal manera que el sistema sea seguro y no se convierta en un código espagueti 🍝
Empecemos por la base que todo junior debe entender y luego seguiremos adelante.
Correo electrónico/contraseña: la vieja escuela que no ha desaparecido ✉️
La autorización clásica a través de correo electrónico y contraseña es la base. Sí, mucha gente dice que está desfasada, pero la verdad es que millones de servicios todavía la utilizan. Y saber cómo funciona correctamente es de vital importancia.
Qué sucede durante el registro
El usuario introduce un correo electrónico y una contraseña. Tu primera tarea es la validación. El correo electrónico debe ser real (al menos sintácticamente correcto) y la contraseña debe ser lo suficientemente compleja.
En 2026, un mínimo de 8 caracteres, letras de diferentes casos, números, caracteres especiales. Pero los requisitos dependen del proyecto: no en todas partes se necesita una «contraseña como la de una caja fuerte de un banco».
Lo más importante: nunca, ¿me oyes? NUNCA no almacene las contraseñas en texto sin formato. Debes cifrar la contraseña antes de guardarla en la base de datos. En 2026, el estándar es bcrypt o Argon2.
// Ejemplo con bcrypt (Node.js)
const bcrypt = require('bcrypt');
// Al registrarse
const saltRounds = 10;
const hashedPassword = await bcrypt.hash(userPassword, saltRounds);
// Guardamos hashedPassword en la base de datos
// Al entrar
const isValid = await bcrypt.compare(userPassword, hashedPasswordFromDB);
if (isValid) {
// Usuario autorizado
}Qué sucede al iniciar sesión
El usuario introduce un correo electrónico y una contraseña. Buscas este correo electrónico en la base de datos, obtienes el hash de la contraseña y lo comparas con la contraseña introducida a través de bcrypt.compare. Si coincide, genera un token (generalmente JWT) y dáselo al cliente.
JWT es tu nuevo mejor amigo 🤝
JSON Web Token es una cadena que contiene información cifrada sobre el usuario. Después de una autorización exitosa, creas un JWT con los datos del usuario (id, correo electrónico, rol) y lo envías al cliente. El cliente guarda el token y lo envía con cada solicitud a la API.
const jwt = require('jsonwebtoken');
// Creación de un token
const token = jwt.sign(
{ userId: user.id, email: user.email },
process.env.JWT_SECRET,
{ expiresIn: '7d' }
);
// Verificación de token
const decoded = jwt.verify(token, process.env.JWT_SECRET);Actualizar tokens: cuando el access token caduca 🧊
El token de acceso suele durar poco, de 15 minutos a varias horas. Cuando caduca, el usuario no tiene que volver a introducir la contraseña. Para ello, se utiliza un refresh token, un token de larga duración que se almacena en un lugar seguro (generalmente httpOnly cookie) y se utiliza para obtener un nuevo access token.
La lógica es simple: token corto para el trabajo, token largo para actualizar el corto. Este patrón lo encontrarás en la mayoría de los proyectos reales.
OAuth 2.0: «Iniciar sesión con Google» y toda esa magia ✨
Cuando un usuario hace clic en «Iniciar sesión con Google» o «Iniciar sesión con Apple», se produce un baile de protocolo OAuth 2.0 entre bastidores. Este es un estándar que permite a los servicios de terceros autorizar a los usuarios sin transmitir una contraseña.
Cómo funciona en pocas palabras
El usuario hace clic en «Iniciar sesión con Google»
Lo rediriges a la página de Google
El usuario inicia sesión y da permiso
Google redirige de vuelta a tu sitio web con un dominio temporal code
Estás cambiando code por token y obtienes los datos del usuario
Lo que un junior necesita saber
Debes registrar la aplicación en la consola (Google/Apple) y obtener Client ID y Client Secret.
El escenario más popular es Authorization Code Flow.
No pierdas el estado entre redirecciones: usa el parámetro
state(protección contra CSRF).Client Secret nunca debe llegar al front-end.
// Ejemplo con Passport.js (Node.js)
const passport = require('passport');
const GoogleStrategy = require('passport-google-oauth20').Strategy;
passport.use(new GoogleStrategy({
clientID: process.env.GOOGLE_CLIENT_ID,
clientSecret: process.env.GOOGLE_CLIENT_SECRET,
callbackURL: "http://localhost:3000/auth/google/callback"
},
async (accessToken, refreshToken, profile, done) => {
// Aquí obtienes los datos del usuario
// Búscalo en tu base de datos o crea uno nuevo
const user = await findOrCreateUser(profile);
return done(null, user);
}
));Inicio de sesión de Apple: características 🍏
Apple se toma la privacidad en serio. Pueden ocultar el correo electrónico real del usuario y dar un correo electrónico proxy del tipo randomstring@privaterelay.appleid.com. Además, tienen su propia especificidad con la generación de client_secret: se crea mediante software y no solo se emite en la consola.
Principales errores: redirect_uri incorrecto (debe coincidir 1 en 1), falta state, no procesado "cancelado por el usuario" y fuga de Client Secret al front-end.
OTP: contraseñas de un solo uso y códigos SMS 📲
One-Time Password es un código que dura unos minutos y se utiliza una sola vez. En 2026, este es uno de los métodos de autorización más populares, especialmente en aplicaciones móviles.
Cómo funciona
El usuario introduce el número de teléfono
Generas un código (4–6 dígitos), lo guardas con TTL (a menudo en Redis)
Enviar el código a través de la puerta de enlace SMS
El usuario introduce el código → tú lo compruebas → creas una sesión
// Generación de OTP
function generateOTP(length = 6) {
const digits = '0123456789';
let otp = '';
for (let i = 0; i < length; i++) {
otp += digits[Math.floor(Math.random() * 10)];
}
return otp;
}
// Guardar con TTL (Redis)
await redis.setex(`otp:${phoneNumber}`, 300, otp); // 5 minutos
// Enviar SMS
await smsService.send(phoneNumber, `Your code: ${otp}`);
// Comprobación
const storedOTP = await redis.get(`otp:${phoneNumber}`);
if (storedOTP === userInputOTP) {
// Autorización exitosa
await redis.del(`otp:${phoneNumber}`);
}TOTP: cuando los SMS no son una opción ⏱️
Contraseña de un solo uso basada en el tiempo: códigos generados por aplicaciones como Google Authenticator o Authy. Funciona sobre la base de una clave secreta y el tiempo. Una excelente opción para 2FA.
const speakeasy = require('speakeasy');
// Generación de secretos
const secret = speakeasy.generateSecret({ name: 'MyApp (user@email.com)' });
// secret.base32 es lo que hay que guardar en la base de datos
// Verificación del código
const verified = speakeasy.totp.verify({
secret: secret.base32,
encoding: 'base32',
token: userInputCode,
window: 2 // tolerancia de tiempo no sincronizado
});Seguridad OTP
Limita el número de intentos de entrada (generalmente 3–5)
Utilice la limitación de velocidad (no más de N SMS por número por hora)
Haz que los códigos sean lo suficientemente largos (mínimo 6 dígitos)
Asegúrate de poner TTL (5–10 minutos)
Aquí encajaría bien la ilustración del «mapa de autorización» para reunir visualmente todo en una sola imagen: correo electrónico/contraseña → JWT → refresh → OAuth → OTP.
Lo que un junior debe saber: lista de verificación para una entrevista 🧠
Cosas básicas
Diferencia entre autenticación y autorización
Qué es JWT y en qué partes se compone (Header, Payload, Signature)
Por qué no se deben almacenar las contraseñas en texto sin cifrar
¿Qué es la sal en el hashing de contraseñas?
Nivel medio
Access token vs refresh token
Cómo funciona OAuth 2.0 a alto nivel
Qué es CSRF y la protección a través de state/token/origin
Dónde almacenar tokens en el front-end y por qué (httpOnly cookies / memory / localStorage)
Nivel avanzado
Cierre de sesión con JWT (lista negra en Redis o TTL corto)
PKCE en OAuth y por qué es necesario
Protección contra ataques de fuerza bruta con OTP (rate limiting, backoff, captcha)
En 2026, esto ya no será una ciencia espacial 🚀
Hace 5-10 años, OAuth parecía algo inaccesible. Ahora es un estándar que está integrado en todos los marcos normales. Las bibliotecas hacen el 80% del trabajo, y tú necesitas comprender los conceptos y la capacidad de pegar todo correctamente.
Comienza con lo básico: correo electrónico/contraseña y JWT. Luego añade OAuth. Y si es necesario, OTP para mayor comodidad o seguridad adicional. Recuerda siempre lo mínimo: hashear contraseñas, verificar tokens, limitar los intentos de inicio de sesión, usar HTTPS.
Todo esto y mucho más se puede estudiar en Kodik 🎓
Si después de leer este artículo tienes preguntas (y seguro que las tienes, la autorización es un tema profundo), ven a Kodik.
Kodik: formación en programación con énfasis en la práctica: analizamos los temas en detalle, con ejemplos de código en vivo y explicaciones de los escollos. No es «aquí está el código, cópialo», sino una comprensión de cómo y por qué funciona todo.
Tareas prácticas: recopilarás la autorización desde cero, desde correo electrónico/contraseña hasta OAuth y 2FA
Consolidación de habilidades a través de ejercicios y miniproyectos
Análisis de errores típicos y patrones de aplicaciones reales
¿Necesitas ayuda? Tenemos una comunidad 👥
Tenemos canal de Telegram activo, donde hay más de 2000 desarrolladores. Puedes hacer una pregunta, discutir un problema, pedir una revisión del código o simplemente charlar con personas que están en el mismo camino.
Únete a Kodik — analizaremos la autorización para que puedas explicarla a los demás con los ojos cerrados 😉