Authentication (authN) — ¿quién sos?

Mostrar tu pasaporte en el aeropuerto — probar que realmente sos la persona que decís ser.

Este es el concepto de Authentication (authN), y significa probar la identidad: un login, una passkey, un token que dice «esta realmente es Alice». Normalmente ocurre una vez por sesión. Si la errás, un impostor entra haciéndose pasar por otra persona. Pero probar quién sos no dice nada sobre qué te está permitido hacer — esa es la otra pregunta, completamente distinta.

Authorization (authZ) — ¿qué te está permitido hacer?

Una tarjeta llave de hotel — no prueba nada sobre tu nombre, pero abre tu habitación y no las otras, y no la oficina del gerente.

Este es el concepto de Authorization (authZ): decidir qué tiene permitido hacer una identidad — leer esto, editar aquello, nunca tocar el panel de admin. A diferencia de la authN, hay que verificarla en cada request, porque un solo usuario logueado puede tocar cien cosas distintas. Saber quién es alguien no es permiso para hacer nada en particular.

Dos capas — nunca las colapses

Un club nocturno: el patovica revisa tu documento en la puerta una vez, y el barman igual revisa que tengas la edad cada vez que pedís un trago. Dos chequeos, dos momentos.

El error clásico es fusionar las dos — probar la identidad una vez y confiar en eso para siempre, o meter cada permiso dentro de un token de login y nunca volver a verificar. La authN ocurre en la puerta; la authZ ocurre en cada puerta de adentro. Mantenelas separadas, y verificá la segunda constantemente.

Don't Roll Your Own Auth — nunca la armes por tu cuenta

No soldás tu propia bóveda de banco con chapa en el garaje — comprás una construida y probada por gente que no hace otra cosa.

Esta es la práctica de Don't Roll Your Own Auth. La identidad es el cimiento sobre el que se apoya todo lo demás, y es tremendamente fácil equivocarse de forma sutil. Usá estándares y librerías probadas — protocolos establecidos, una librería o proveedor de auth curtido en batalla — no un esquema ingenioso que inventaste vos. La historia de la seguridad está llena de auth casera que parecía andar bien hasta que de golpe dejó de hacerlo.

El mapa: 22 conceptos en seis grupos

Un llavero: primero ves todo el manojo, después aprendés qué llave abre qué puerta.

Los conceptos del curso se agrupan en seis grupos. Cada uno responde su propia pregunta: qué son las dos «auth», cómo probar la identidad, cómo seguir logueado, cómo dar acceso sin contraseña, cómo decidir permisos, y cómo suele romperse todo.

Cada concepto de abajo recibe el mismo tratamiento: su nombre en inglés (el término con el que vas a buscar en la documentación), una imagen de la vida real, un diagrama y una ficha con campos. Al final, una hoja de referencia con todos los conceptos.

Password Hashing — contraseñas, el default débil

Una palabra secreta compartida con el portero — sirve hasta que alguien la escucha, la adivina, o la usás en todos lados.

Las contraseñas son universales y el factor común más débil: se reutilizan, se adivinan, se les hace phishing. Si hay que usarlas, la regla innegociable es nunca guardarlas como texto. Guardá un hash lento y con sal (Argon2, bcrypt) — eso es Password Hashing — para que una base de datos robada no entregue las contraseñas de todos. (Más sobre esto en el capítulo de errores.)

MFA — algo que sabés, tenés, sos

Una caja de seguridad del banco necesita tu llave y la del banco. Una sola no abre nada.

MFA (Multi-Factor Authentication), o doble factor, exige una segunda prueba además de la contraseña — algo que tenés (un código de una app, una llave de seguridad) o algo que sos (una huella digital). Así, ni una contraseña robada sirve por sí sola. Un código de app autenticadora (TOTP) es sólido; los códigos por SMS son débiles (se pueden interceptar) pero mejores que nada. MFA es la mejora de seguridad más grande y barata que podés agregar.

Passkeys — el futuro sin contraseñas

Una llave que solo funciona en la única puerta para la que fue cortada — falsificá el sitio, copiá la foto de la cerradura, y la llave simplemente no gira.

Las passkeys (basadas en el estándar WebAuthn) reemplazan las contraseñas por un par de claves criptográficas atado a tu dispositivo y al sitio real, así que no hay nada que phishear, reutilizar o filtrar — y Apple, Google y Microsoft ya las usan por defecto. La clave privada nunca sale de tu dispositivo; el sitio solo ve una firma. Hacia ahí va la autenticación: nada que robar.

Stateless HTTP — HTTP no tiene memoria

Un negocio donde el empleado te olvida en cuanto te das vuelta — así que necesitás un ticket para demostrar, en tu próximo paso, que ya pagaste.

HTTP es stateless (sin estado): cada request es independiente; el servidor no recuerda que te logueaste hace un segundo. Entonces, después de la autenticación te dan algo — una cookie o un token — que mandás con cada request para decir «sigo siendo yo». Todo lo que sigue son dos formas de hacerlo. (Esto es la falta de estado del curso de protocolos.)

Session — el servidor recuerda

Un guardarropa — vos tenés un ticket numerado, y toda la información real está detrás del mostrador bajo ese número.

Con las sesiones, el servidor guarda quién sos y te da una cookie que contiene solo un id de sesión aleatorio. En cada request, busca el id. El servidor es la fuente de verdad, así que desloguear o bloquear a alguien es instantáneo — basta con borrar la sesión. El costo es que el servidor tiene que guardar y consultar ese estado. El default correcto para la mayoría de las apps web.

JWT — el token lleva la verdad

Una pulsera de festival con tu nivel de acceso ya impreso y sellado contra manipulación — el guardia revisa el sello, no una lista de invitados.

Un JWT (JSON Web Token) es un token firmado que guarda el cliente y que contiene la identidad y sus claims; el servidor solo verifica la firma, sin consultar nada. Eso lo hace stateless y fácil de escalar entre servicios — pero difícil de revocar: un token filtrado sigue siendo válido hasta que vence. Por eso se mantienen vidas cortas y se combina con un refresh token. Excelente para APIs y microservicios; exagerado para una app web simple.

httpOnly Cookie — importa dónde lo guardás

Una llave en un cajón con llave frente a una llave pegada con cinta en la puerta de entrada — la misma llave, una seguridad muy distinta.

Un token en el navegador debe ir en una cookie httpOnly (JavaScript no puede leerla), no en localStorage, donde cualquier script inyectado puede robarlo. El lugar donde se guarda es parte de la seguridad: si lo hacés mal, un solo bug de XSS le entrega todas las sesiones a un atacante. Cómo transportás y guardás la credencial es tan importante como la credencial misma.

OAuth 2.0 — dar acceso sin compartir la contraseña

Una llave de valet que arranca el auto y abre la puerta, pero no el baúl ni la guantera — entregás acceso limitado, no todo tu llavero.

Este es el protocolo OAuth 2.0. Permite que un usuario le dé a tu app acceso limitado a su cuenta en otro servicio — tu app lee su Google Calendar — sin darte nunca su contraseña de Google. El otro servicio le entrega a tu app un access token limitado por un scope («leer el calendario, nada más»). Trata de autorización delegada, no de identidad.

OIDC — OAuth2 que además dice quién sos

La llave de valet, ahora con un documento con foto sujeto a ella — no solo «qué abre esta llave», sino «y acá está a quién pertenece».

OAuth2 por sí solo te dice a qué puede acceder una app, no quién es el usuario. OpenID Connect (OIDC) agrega encima una capa fina de identidad — un ID token con claims verificados (esta es Alice, este es su email). Es lo que está detrás de «Entrar con Google» y del single sign-on (SSO). Cuando querés login social o SSO, OIDC es el estándar.

API Key — la credencial simple para máquinas

Una llave de repuesto que le das a un contratista de confianza — sin nombre, solo «quien la tenga puede entrar».

Una API key es una cadena secreta larga que identifica a un programa, no a una persona — se usa para acceso entre servicios y programático. Simple y efectiva, pero es la credencial: quien la encuentre, entra. Por eso se acota su alcance, se rota, y nunca se sube a git ni se pone en una URL. Sirve para máquinas; no reemplaza una identidad real de usuario.

Deny by Default / Least Privilege — prohibido salvo que se permita

La credencial de un empleado nuevo que no abre nada hasta que se le concede cada puerta de forma explícita — en vez de abrirlo todo hasta que alguien se acuerde de cerrar unas pocas.

La base de la autorización son dos reglas. Deny by default: todo está prohibido salvo que se permita explícitamente. Least privilege: cada identidad recibe el acceso mínimo que necesita, no más. Los sistemas abiertos por defecto filtran — siempre alguien se olvida de restringir el nuevo endpoint. Los sistemas cerrados por defecto fallan de forma segura. Empezá desde el «no» y concedé con intención.

RBAC — permisos por rol

Un teatro donde el tipo de entrada — platea, palco, pase de backstage — decide adónde podés ir, sin nombrarte a vos personalmente.

RBAC (Role-Based Access Control) agrupa permisos en roles — admin, editor, lector — y asigna usuarios a roles. Simple, legible y suficiente para la mayoría de las apps: «los editores pueden publicar, los lectores no». Se vuelve grueso cuando las reglas dependen del contexto o del registro concreto, y ahí entran los siguientes modelos.

ABAC — permisos por política

Una regla en vez de una lista — «los gerentes pueden aprobar gastos de menos de 10k, en horario laboral, desde un dispositivo de la empresa» — evaluada de nuevo cada vez.

ABAC (Attribute-Based Access Control) decide a partir de atributos del usuario, del recurso y del contexto — rol y monto y hora y dispositivo. Mucho más flexible que los roles fijos, y mucho más complejo. La señal para adoptarlo: estás apilando más de un par de condiciones if a medida sobre tus chequeos de rol.

Ownership Check — ¿podés tocar este registro?

Tenés un carnet de biblioteca válido (un rol), pero eso no te deja leer las notas garabateadas en el libro que otro tiene prestado.

El ownership check (autorización a nivel de objeto) es el chequeo que más se olvida: incluso un «editor» válido solo debe editar sus propios documentos, no los de todos. El rol dice «los editores pueden editar»; igual tenés que verificar que este editor es dueño de esta fila. Olvidarlo es el bug de control de acceso más común — cambiás el id en la URL y estás en los datos de otro. Verificá siempre el objeto, no solo el rol.

Broken Access Control / IDOR — olvidarse de verificar

Un edificio donde la puerta de entrada está vigilada pero todas las puertas internas están sin llave — una vez adentro, podés caminar a cualquier lado.

Broken Access Control es la vulnerabilidad web número uno: un endpoint autentica al usuario pero se olvida de verificar que esté autorizado para lo que pidió. Su forma más común es IDOR (Insecure Direct Object Reference) — cambiar /orders/123 por /orders/124 y ver el pedido de otra persona, porque el servidor nunca verificó la propiedad. Filtraciones de millones de registros se explican justo por esto. Verificá la authZ en cada request, del lado del servidor, contra el objeto real.

Plaintext / Fast Hash — guardar mal las contraseñas

Guardar las llaves de repuesto de todas las casas de la calle en un frasco de vidrio en el porche.

Guardar contraseñas en texto plano — o con un hash rápido como MD5 — significa que una sola filtración de la base expone a todos, y las contraseñas reutilizadas comprometen también las otras cuentas. Las contraseñas hay que hashearlas de forma lenta e individual (Argon2, bcrypt) para que sea caro crackearlas incluso si las roban. Que el hash sea lento es el objetivo, no un defecto.

Token Leakage — filtrar y confiar en tokens

Escribir el código de la alarma en un papelito pegado en la puerta — la cerradura está bien; vos regalaste el secreto.

Token leakage es la forma en que escapan los tokens y las claves. Se filtran por URLs (que se loguean), el localStorage del navegador (que un script puede leer) y secretos subidos a git. Y un token hay que verificarlo, no confiar en él porque apareció — uno alterado o vencido debe rechazarse. Tratá toda credencial como algo que algún día se va a filtrar: vidas cortas, rotación, y nunca en un lugar que se loguee o se raspe.

Trusting the Client — creerle a lo que dice el navegador

Un negocio que deja que los clientes escriban sus propias etiquetas de precio y nunca las verifica en la caja.

Este es el anti-patrón de confiar en el cliente. Todo lo que manda el cliente — un campo oculto de un formulario, un rol en una cookie, un flag isAdmin=false — se puede falsificar. El navegador, la app, el request: todo está bajo control del usuario. Cada chequeo real debe ocurrir en el servidor, que el usuario no puede editar. El cliente es una sugerencia; el servidor es la autoridad.

Auth Provider — usá una librería o un proveedor

No fabricás tus propios cinturones de seguridad — instalás unos certificados, diseñados por especialistas y probados en choques durante años.

Para casi todo el mundo, lo correcto es no armar la auth por tu cuenta: usá la auth de tu framework, o un auth provider (Auth0, Clerk, Supabase, Cognito y similares) que maneje el hashing, las sesiones, MFA, OAuth y los casos borde que nunca se te ocurrirían. Tu trabajo es integrarlo bien y encargarte de la autorización — la parte que solo vos conocés.

Match the mechanism to the app — elegí el mecanismo según la app

Una llave de casa, una de auto y una tarjeta de hotel son todas «llaves» — elegís según la puerta, no según la moda.

Sesiones para una app web normal (simples, revocables al instante); JWTs de vida corta más refresh cuando necesitás escala sin estado entre servicios; OIDC para login social y SSO; API keys para máquina a máquina. Sumá MFA en todos lados donde importe, sobre todo en cuentas de admin. Elegí según la forma de tu app, no según lo que suena avanzado.

Cómo se conecta todo

El camino de un huésped de hotel: un pasaporte en la recepción, una tarjeta llave en la mano, y cada puerta decide por sí misma si abre.

Los factores de login (contraseña, MFA, passkey, OIDC, API key) llevan a la authN. Su resultado viaja con cada request en una sesión o un JWT, mejor guardado en una cookie httpOnly. En cada request, la authZ decide por roles o por política — y siempre verifica la propiedad del objeto.