Lección 8 de 12 · Lectura y práctica
Auth basica (sin inventar criptografia)
Distingue autenticación y autorización en una API Express y comprueba propiedad del recurso sin crear criptografía propia.
Del concepto a la práctica
Taller de esta lección
Autenticar identifica a la persona; autorizar comprueba si puede operar sobre ese recurso. El identificador enviado en la URL nunca demuestra propiedad: la aplicación debe usar la identidad establecida por un middleware de sesión o credencial verificada.
Ejemplo resuelto
async function obtenerNota(req,res) {
if (!req.user) return res.status(401).json({ ok: false, error: { code: 'UNAUTHORIZED' } });
const note = await notes.findById(req.params.id);
if (!note || note.ownerId !== req.user.id) {
return res.status(404).json({ ok: false, error: { code: 'NOT_FOUND' } });
}
return res.json(note);
}Con nota 12 propiedad de u1, u1 recibe 200 y u2 recibe 404 según este contrato que no revela si existe.
Datos completos: nota12={ownerId:"u1",texto:"Privada A"}, nota13={ownerId:"u2",texto:"Privada B"}. La asignación manual req.user pertenece exclusivamente al fixture de test: el servidor real verifica sesión/token y no acepta x-user ni ownerId como autoridad. Si tu repositorio permite filtrar por ID y propietario en una consulta, úsalo para reducir exposición. La política404 ante acceso ajeno debe documentarse.
Pruébalo
Usa un middleware local que establezca
req.user.iden pruebas.Crea dos notas con propietarios distintos.
Comprueba acceso propio, ajeno y sin sesión.
Error frecuente: aceptar ownerId del body como autoridad. Corrige derivándolo de req.user.
Ejercicio: prueba nota 12 con u1, u2 y sin usuario.
Comprueba tu resultado
200, 404 y 401 respectivamente, sin implementar criptografía propia.
Mapa de prácticaEl control de acceso, las actualizaciones y las copias de seguridad cubren riesgos distintos. Una alerta necesita un procedimiento de respuesta para contener y recuperar el servicio. Varias capas reducen la exposición, pero ninguna garantiza seguridad absoluta.
Ver la infografía en tamaño completo ↗Dos preguntas distintas
La autenticación identifica la sesión o credencial; la autorización decide si esa identidad puede actuar sobre un recurso. Conserva la idea de hash de contraseñas, sesiones o tokens y checks de propiedad. No implementes un algoritmo de cifrado ni confíes en un userId enviado por el cliente como prueba de identidad.
Caso ficticio: consultar una nota privada
A tiene una nota y B tiene otra. La ruta recibe un identificador de nota. El middleware de sesión verificado por la aplicación establece req.user.id; esta lección no inventa ese middleware ni presenta el fragmento como una solución completa de login.
// Ejemplo de autorización, después del middleware de sesión real.
app.get("/notes/:id", requireAuth, async (req, res, next) => {
try {
const note = await notes.findById(req.params.id);
if (!note || note.ownerId !== req.user.id) {
return res.status(404).json({ error: "Nota no disponible" });
}
return res.json({ id: note.id, title: note.title });
} catch (error) {
next(error);
}
});El ejemplo devuelve la misma respuesta cuando la nota no existe o no pertenece al usuario para no revelar su existencia. Otras APIs pueden tener un contrato distinto; documenta el tuyo y pruébalo. Aplica el control también a actualización y borrado, no solo a lectura.
Dónde revisar las credenciales
- Usa una biblioteca mantenida para generar y verificar hashes; nunca almacenes contraseñas en texto plano.
- Si la sesión usa cookies, revisa HTTPS, atributos apropiados, expiración y protección frente a peticiones cruzadas.
- Si usas tokens, verifica firma, expiración y restricciones con una biblioteca; decodificar no equivale a validar.
- No registres contraseñas, cookies o tokens en logs.
- El almacenamiento y la estrategia dependen de la aplicación; este fragmento no decide todo el sistema de autenticación.
Matriz de práctica
| Petición | Qué demostrar |
|---|---|
| Sin sesión | El middleware rechaza el acceso |
| A consulta su nota | Solo recibe campos públicos previstos |
| B consulta la nota de A | No obtiene contenido ni puede modificarla |
| ID ausente | Respuesta coherente con el contrato |
| Fallo del almacenamiento | Error controlado sin datos internos |
Entrega una regla escrita, el punto del servidor donde se aplica y los resultados reales de esas pruebas en un proyecto de práctica. No consideres protegido un recurso porque el botón esté oculto o porque el navegador conserve una sesión.
Referencias para comprobar la implementación
Documentación consultada el 2 de octubre de 2026. Comprueba también las versiones y condiciones de tu proyecto.
Sigue con Node.js y APIs con Express
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.