Cómo elegir un modelo de identidad

Tres modelos, cada uno visto por separado. Si los pones uno junto al otro, queda claro qué está optimizando cada uno, porque cada uno renuncia a algo para conseguirlo.

Qué gana realmente cada uno

• Las sesiones con estado anclan todo al servidor. La identidad vive ahí, y también el control, así que son predecibles, actualizables y se pueden revocar al instante. A cambio, tienes un componente central que debe escalar y mantenerse sincronizado, y eso se vuelve más difícil con cada servidor que agregas.
• Los tokens opacos apuntan al servidor. La identidad sigue viviendo ahí, en un pequeño mapeo de token a usuario en lugar de un almacén de sesiones completo. El servidor se aliviana bastante, aunque no queda del todo libre, porque sigue habiendo una búsqueda. Un punto medio práctico.
• Los JWT llevan la idea de "sin estado" a su conclusión lógica, guardando toda la identidad dentro del token. No hay búsqueda, no hay almacén compartido, no hay coordinación, no hay carga en el servidor. Es un objeto firmado en el que el servidor confía al instante, y una verdadera pelea cuando necesitas revocar el acceso.
• La identidad delegada traslada la responsabilidad completamente fuera de tu sistema. Dejas de preocuparte por las contraseñas, pero heredas la complejidad de una relación con un proveedor que tienes que manejar bien.

Con estado es para tener control. Sin estado es para escalar. Delegada es para descargar la confianza en otro.

JunoQué gana realmente cada uno Ninguno de estos es la mejor opción. Cada uno es bueno en algo y lo paga en otro lado.

Y eso, curiosamente, es liberador: la pregunta deja de ser "cuál es la respuesta correcta" y pasa a ser "en qué se puede dar el lujo de fallar esta app".

JunoQué gana realmente cada uno Los cuatro modelos se ubican en una línea, y vale la pena verlos así. Las sesiones mantienen todo del lado del servidor; los tokens opacos mantienen un mapeo mínimo; los JWT no mantienen nada; la identidad delegada mantiene toda la cuestión en otro lugar.

Al avanzar en esa línea, vas cambiando control por escala, paso a paso. Identificar en qué paso estás suele resolver una discusión de arquitectura más rápido que enumerar características.

JunoQué gana realmente cada uno La comparación que la tabla no puede mostrar es la operativa. Las sesiones necesitan un almacén que tiene que estar siempre disponible, así que su disponibilidad se convierte en la disponibilidad de tu login.

Los JWT no necesitan almacén, pero sí necesitan gestión de claves, rotación y un plan para el día en que se filtre un secreto. La identidad delegada no necesita ninguna de las dos cosas, pero hace que tu disponibilidad dependa en parte de un proveedor.

Nada de eso aparece en una comparación de características, y todo eso aparece en un incidente. Vale la pena preguntarte, sea cual sea el modelo que elijas, cómo se vería su falla a las 3 de la mañana y a quién le llega la alerta.

Lado a lado

	Con estado	Token opaco	JWT	Delegado
Dónde vive la identidad	En el servidor	En el servidor, de forma mínima	En el token	Con el proveedor
Por cada petición	Búsqueda de sesión	Búsqueda de token	Verificación de firma	Depende de qué emitas después
Almacenamiento en el servidor	Almacén de sesiones completo	Mapeo pequeño	Ninguno	Ninguno
Revocar de inmediato	Sí	Sí	No	En parte, depende del proveedor
Escala horizontalmente	Necesita un almacén compartido	Necesita un almacén compartido	Sin problema	Sin problema
Lo que sacrificas	Coordinación	Algo de coordinación	Poder cambiar de opinión	Control

JunoLado a lado La fila de "revocar" es la primera que hay que leer. Es la diferencia que más pesa y la más difícil de cambiar después.

Si necesitas sacar a alguien ahora mismo, la respuesta implica una búsqueda en algún lado. Todo lo demás se deriva de eso.

JunoLado a lado Fíjate que los tokens opacos y las sesiones comparten columna casi siempre. Ese es el panorama real: los tokens opacos son una versión más liviana de la misma idea, no una familia distinta.

La verdadera bifurcación está entre "el servidor puede buscarlo" y "el servidor no puede", y la columna de JWT es la única que queda del otro lado.

JunoLado a lado Nada de esto es fijo para siempre, y migrar es más fácil en una dirección que en la otra. Pasar de sesiones a tokens es sobre todo aditivo: emites tokens en paralelo, migras a los clientes y retiras las sesiones. Pasar de tokens de vuelta a sesiones significa construir el almacén que deliberadamente habías evitado y volver a autenticar a todo el mundo.

Así que, cuando la decisión está pareja, el modelo que conserva una búsqueda es el error más barato. Siempre puedes quitar el estado más adelante; volver a agregarlo es la migración que nadie planifica.

Cuándo conviene cada uno

• Con estado brilla cuando el servidor tiene que mantener el control: cierre de sesión instantáneo, cambios de rol en tiempo real, control estricto sobre el estado del usuario. Es estable y predecible, y encaja bien en dashboards, herramientas de administración y en general donde el control importa más que la escala horizontal.
• Sin estado brilla cuando la arquitectura necesita margen para crecer. Para una API, o para cualquier cosa que escale sin coordinar el estado de las sesiones, que el cliente traiga su propio token elimina esa fricción de inmediato. Los tokens opacos mantienen las cosas simples; los JWT eliminan por completo la búsqueda.
• Delegado tiene sentido en el momento en que te das cuenta de que no quieres manejar un sistema de contraseñas para nada. O cuando la velocidad de registro importa, o cuando quieres una base más sólida que la que construirías tú mismo. Tu app deja de encargarse de probar la identidad y pasa a simplemente consumirla.

Y el cambio de perspectiva con el que vale la pena cerrar: muchas veces no eliges uno solo. Los sistemas reales los combinan, usando identidad delegada para establecer quién es alguien, una sesión para el sitio web principal y JWT para las llamadas a la API. Cada uno resuelve una parte distinta del problema.

JunoCuándo conviene cada uno Combinarlos suena a trabajo extra, pero por lo general es menos trabajo. Cada modelo se encarga de la parte en la que es bueno.

Google confirma quién eres, una sesión te mantiene conectado al sitio, un token te da acceso a la API. Tres tareas, tres herramientas.

JunoCuándo conviene cada uno Cuando los combines, anota dónde se establece la identidad y dónde se consume, porque ese es el diagrama sobre el que la gente discute sin entenderse.

El esquema típico: el proveedor autentica, tu backend emite su propia sesión o token, y todo lo que viene después confía en el tuyo y no en el del proveedor. Seguir pasando el token del proveedor de un lado a otro es justo donde las integraciones se enredan.

JunoCuándo conviene cada uno Una advertencia sobre combinarlos: cada modelo que agregas es una puerta de entrada, y todas tienen que estar alineadas. Una cuenta a la que se puede acceder tanto con contraseña como con un login delegado tiene dos niveles de fortaleza en la autenticación, y un atacante va a usar el más débil.

Aplicar MFA en el camino de la contraseña mientras un camino delegado lo evita es una versión de esto que termina saliendo a producción. Lo mismo pasa con un flujo de restablecimiento de contraseña que entrega una sesión para una cuenta que siempre inició sesión solo a través de Google.

La regla que se sostiene: cada camino de entrada a una cuenta debería ser tan fuerte como lo más fuerte que la protege, o esa protección fuerte es pura decoración.

Ponlo en práctica

Cinco sistemas. Elige un modelo para cada uno y nombra la propiedad que lo decide.

1. Un dashboard web clásico para personal interno. Los administradores necesitan cierre de sesión instantáneo, los cambios de permisos deben aplicarse de inmediato y la seguridad importa más que la escala.
2. Una API pública que da servicio a una app móvil.
3. Una arquitectura de microservicios grande donde una docena de servicios necesitan saber quién los está llamando.
4. Una app de consumo cuyo objetivo principal es un registro rápido, idealmente con Google o Apple.
5. Un proyecto personal en un solo servidor.

Compara tus respuestas

#	Modelo	La propiedad que lo decide
1	Con estado	El servidor mantiene el control. Cambias un rol o cierras la sesión de alguien y eso surte efecto en la siguiente petición. Para una app de navegador normal, las sesiones son simples y confiables
2	Sin estado, de cualquiera de los dos tipos	Cada petición trae un token que el servidor verifica y sigue adelante, sin una pila creciente de sesiones que rastrear a medida que aumenta el uso
3	Sin estado, específicamente JWT	Al ser autocontenido, cada servicio verifica por su cuenta en lugar de que todos le pregunten a un servidor central en cada llamada
4	Delegado	No hay contraseñas que manejar en absoluto, y el registro es lo más rápido posible
5	Con estado	Lo más simple que funciona. Un servidor, una tabla de sesiones pequeña, una cookie. Sin tokens, sin OAuth, nada que operar

Uno y cinco llegan a la misma respuesta desde direcciones opuestas, y esa es la parte interesante. El uno elige sesiones porque el control es lo que más importa; el cinco las elige porque no hace falta nada más. Ninguno de los dos es una decisión de escalabilidad, que es justamente lo que la gente suele asumir que impulsa esta elección.

Hacia dónde va esto ahora

Cuatro preguntas te van a acompañar a partir de ahora en cualquier sistema de login que te encuentres. ¿Dónde vive realmente la identidad? ¿Cómo sabe el servidor que esta persona es quien dice ser? ¿Qué pasa si esto se filtra, expira o es manipulado? ¿Qué modelo le conviene a esta app, y por qué?

Eso es razonamiento, no una lista de chequeo, y es lo que hace legible un sistema de autenticación que no conoces.

La siguiente sección cambia completamente de tema. Fundamentos de rate limiting deja de preguntar quién es alguien y empieza a preguntar con qué frecuencia se le permite preguntar.