Arquitectura backend de identidad digital: las decisiones que los tutoriales omiten

Cuando cursaba Ciencias de la Computación en la UBA, había materias donde llegaba con el traje puesto directo del trabajo. Una noche llegué tarde a una clase de sistemas operativos y el profesor estaba hablando de permisos y usuarios. Yo había pasado la tarde anterior rompiendo un servidor Linux de hosting por un chmod -R 777 que parecía inocente. El profesor explicaba el modelo teórico. Yo ya sabía el costo real de no entenderlo.

Pienso en eso cada vez que leo un tutorial de autenticación que termina en "¡ya tenés tu sistema de login funcionando!". Sí, funciona. Hasta que alguien cambia de rol, cierra sesión desde un dispositivo, o querés invalidar un token que emitiste hace 40 minutos.

Mi tesis: los tutoriales de auth muestran el happy path. Los problemas reales de un backend de identidad digital aparecen en tres lugares que casi nunca se cubren: la revocación de credenciales, la propagación de cambios de estado y el modelo de confianza entre servicios. Si diseñás sin pensar en esos tres, vas a rediseñar más adelante.

El error de diseño que empieza con "usemos JWT para todo"

JWT (RFC 7519) es una especificación limpia. Un token firmado, autodescriptivo, verificable sin llamar a ningún servidor. Eso es exactamente lo que lo hace peligroso si no entendés bien qué garantiza y qué no.

Lo que JWT garantiza según la spec: que el token no fue modificado (firma), que los claims son los que el emisor puso, y que podés verificarlo localmente si tenés la clave pública. Eso es todo.

Lo que JWT no garantiza: que el usuario sigue siendo válido en este momento. Si alguien es dado de baja, cambia de contraseña, o pierde permisos, el token sigue siendo criptográficamente válido hasta su expiración. RFC 7519 no define revocación porque no es su problema. El problema es nuestro.

La trampa más común que veo en diseños de sistemas de identidad:

// Patrón típico en Spring Security — parece completo, no lo es
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .oauth2ResourceServer(oauth2 -> oauth2
            .jwt(jwt -> jwt
                .decoder(jwtDecoder()) // valida firma y expiración
            )
        );
    return http.build();
}

// El decoder valida que el token esté bien firmado y no vencido.
// NO consulta si el usuario fue desactivado en los últimos 55 minutos.
// Ese gap es tu problema de diseño, no un bug del framework.

La verificación de firma es necesaria pero no suficiente. Si el token dura 60 minutos y el usuario fue suspendido al minuto 5, tenés 55 minutos de acceso no autorizado que el código de arriba no va a detener.

JWT vs sesiones con estado: la decisión real, no el debate de Twitter

El debate "JWT vs sesiones" generalmente se reduce a "stateless vs stateful", como si eso resolviera algo. No resuelve nada. El criterio que importa es cuánto control necesitás sobre la vida de una credencial.

Nota: esta tabla representa trade-offs del diseño. Los números de "escalabilidad" dependen de la infraestructura concreta; no son benchmarks universales.

Si el sistema requiere que bloquear un usuario surta efecto en menos de N segundos, JWT puro no es suficiente. Necesitás alguna forma de verificación activa: token introspection (RFC 7662), una lista negra en cache, o short-lived tokens con refresh agresivo.

El OpenID Connect Core 1.0 introduce el concepto de id_token junto con access_token y refresh_token. La separación no es arbitraria: el id_token afirma identidad, el access_token autoriza acciones, y el refresh_token controla el ciclo de vida de la sesión. Confundir los tres es otro error de diseño clásico.

Modelar el ciclo de vida de credenciales: lo que la spec dice y lo que tenés que implementar vos

OpenID Connect define el flujo de autorización, los endpoints y los claims estándar. Pero el ciclo de vida de una credencial —cómo nace, cómo cambia, cómo muere— es responsabilidad del backend que construís, no de la spec.

Un modelo mínimo que funciona en la práctica:

// Estados posibles de una credencial/sesión
public enum CredentialState {
    ACTIVE,        // emitida y válida
    SUSPENDED,     // bloqueada temporalmente (ej: sospecha de fraude)
    REVOKED,       // invalidada permanentemente
    EXPIRED        // venció por tiempo
}

// Al emitir, registrás el estado inicial
public record CredentialRecord(
    String jti,              // JWT ID — claim estándar de RFC 7519 §4.1.7
    String userId,
    CredentialState state,
    Instant issuedAt,
    Instant expiresAt,
    String deviceFingerprint  // contexto de emisión
) {}

El campo jti (JWT ID) está definido en RFC 7519 §4.1.7. Es un identificador único por token. Si lo persistís, tenés la base para una lista negra eficiente: cuando querés revocar, guardás el jti en Redis con TTL igual al tiempo restante de vida del token. Cada request verifica contra esa lista. Costo: una consulta a cache por request. Beneficio: revocación real en tiempo aproximadamente real.

// Verificación adicional sobre la firma de JWT
// Después de que Spring Security valida la firma:
@Component
public class RevocationFilter extends OncePerRequestFilter {

    private final RevocationCache revocationCache;

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain) throws IOException, ServletException {

        String jti = extractJti(request); // extraé del token ya validado

        // Consultá la lista negra antes de procesar el request
        if (jti != null && revocationCache.isRevoked(jti)) {
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            return; // cortá acá, no sigas la cadena
        }

        filterChain.doFilter(request, response);
    }
}

Este patrón no elimina el estado: lo minimiza. En lugar de sesión completa, guardás solo lo que necesitás para invalidar. Es un trade-off consciente, no una solución mágica.

Los errores de diseño que solo aparecen cuando el sistema crece

1. Tokens de larga duración como atajo

Un access_token con expiración de 24 horas es una sesión con peor interfaz. Tenés todo el costo del manejo de estado de usuario sin el beneficio del control granular. La recomendación general en sistemas de identidad —respaldada por el modelo de OIDC— es access tokens cortos (minutos, no horas) con refresh tokens controlados.

2. No modelar el dispositivo como entidad

Si un usuario tiene tres sesiones activas desde tres dispositivos y cierra sesión desde uno, ¿qué pasa con los otros dos? Si el diseño no modela el dispositivo como entidad, esa pregunta no tiene respuesta. En sistemas de identidad digital donde la credencial tiene valor legal o económico, esto no es opcional.

3. Propagar cambios de perfil sin propagar cambios de estado

Un patrón común: el servicio de usuarios actualiza el email, el backend de auth no se entera hasta que vence el token. Si el claim email vive solo en el JWT y no hay forma de invalidar el token previo, el usuario opera con datos stale por el tiempo de vida restante. El diseño tiene que definir qué claims son "live" (verificados en cada request) y cuáles son "frozen" (confiados al momento de emisión).

Este problema está relacionado con algo que cubrí en el post sobre firma digital: formato, certificado y política de validación — la confianza en una afirmación tiene un timestamp, y ese timestamp importa.

4. Asumir que el Authorization Server es el único punto de verdad

En sistemas distribuidos, un servicio puede recibir un token válido pero necesitar contexto que el token no trae. El error de diseño es resolver esto con tokens cada vez más gordos (más claims, más info embebida). La solución más robusta es separar autenticación de autorización: el token prueba identidad, el servicio decide permisos con su propio modelo. Ver también: system prompts para agentes en producción — el mismo problema de "quién confía en quién" aparece en otro dominio.

Checklist de decisión: antes de elegir JWT puro, sesiones, u OIDC completo

Antes de comprometerte con una arquitectura de identidad, respondé estas preguntas. No como ejercicio académico, sino como gate de diseño:

• ¿Necesitás revocación inmediata? Si sí → JWT puro sin mecanismo adicional no alcanza.
• ¿Tenés más de un dispositivo por usuario? Si sí → modelá sesiones por dispositivo, no por usuario.
• ¿Los permisos pueden cambiar en tiempo de vida del token? Si sí → necesitás introspección activa o tokens muy cortos.
• ¿Quién verifica el token? Si son múltiples servicios → JWKS endpoint, rotación de claves planificada.
• ¿Tenés auditoría requerida por dominio (legal, financiero, etc.)? Si sí → jti persistido, no opcional.
• ¿El refresh token puede usarse desde cualquier dispositivo? Si sí → diseño potencialmente inseguro. Considerá rotation + binding.

Este checklist no reemplaza un threat model, pero evita los errores de diseño más comunes antes de escribir una línea de código.

FAQ: preguntas frecuentes sobre arquitectura de identidad digital

¿JWT siempre es mejor que las sesiones en el servidor? No. JWT es mejor cuando necesitás verificación stateless en múltiples servicios sin coordinación central. Las sesiones con estado son mejores cuando necesitás revocación inmediata, auditoría granular o control de dispositivos. La decisión correcta depende de los requisitos del sistema, no de la tendencia del momento.

¿Cómo implemento revocación de JWT sin romper la escalabilidad? El patrón más común es una lista negra en Redis con TTL igual al tiempo restante del token. Solo guardás el jti del token (claim definido en RFC 7519 §4.1.7), no el token completo. El costo es una consulta a cache por request autenticado. Si Redis no está en la stack, podés usar la misma lógica con cualquier store de baja latencia.

¿Cuál es la diferencia entre access_token, id_token y refresh_token en OIDC? Según OpenID Connect Core 1.0: el id_token es una aserción de identidad (quién sos), el access_token autoriza acciones sobre recursos (qué podés hacer), y el refresh_token permite obtener nuevos access tokens sin reautenticación. Mezclarlos —por ejemplo, usar el id_token para autorizar llamadas a una API— es un error de diseño que la spec explícitamente desaconseja.

¿Qué tamaño máximo debería tener un JWT? RFC 7519 no define un límite. El límite práctico viene de los headers HTTP (por defecto 8KB en muchos servidores). Un JWT inflado con claims innecesarios aumenta latencia en cada request. Regla de diseño: un JWT debería tener solo los claims que el receptor necesita verificar localmente. El resto lo buscás en el momento que lo necesitás.

¿Cuándo tiene sentido implementar OIDC completo versus un auth propio con JWT? OIDC completo conviene cuando tenés múltiples aplicaciones cliente, SSO entre sistemas, o necesitás interoperabilidad con proveedores externos. Auth propio con JWT puede ser suficiente para un sistema interno con un solo cliente. El costo de OIDC completo es complejidad operativa real: endpoints de discovery, JWKS rotation, session management. No lo subestimes. Relacionado: el post sobre rate limiting antes de elegir una librería aplica el mismo criterio de "¿realmente necesitás esto ahora?".

¿Qué pasa si el servidor de identidad cae y los tokens ya emitidos siguen siendo válidos? Eso es exactamente la garantía stateless de JWT: verificación sin coordinación central. Si el auth server cae, los tokens existentes siguen funcionando hasta su expiración. Eso puede ser un feature (resiliencia) o un bug (imposibilidad de invalidar rápido en una emergencia). Diseñá sabiendo que esa garantía existe en ambas direcciones.

Conclusión: la arquitectura de identidad no es un problema de librería

Lo incómodo de este tema es que no se resuelve eligiendo la librería correcta de Spring Security o el middleware de JWT más popular. Se resuelve tomando decisiones de diseño antes de escribir código: qué garantiza el token, qué no garantiza, cómo cambia el estado del usuario, y quién tiene autoridad para invalidar qué.

Mi postura es esta: si arrancás con JWT puro porque "es stateless y escala bien" sin modelar revocación, cambios de estado y confianza entre servicios, no estás construyendo un sistema de identidad. Estás construyendo autenticación básica con un formato moderno. No es lo mismo.

Lo que haría diferente al empezar: modelar primero el ciclo de vida de la credencial —estados, transiciones, quién puede triggerear cada una— antes de elegir el mecanismo de token. Después la elección JWT/OIDC/sesiones se vuelve consecuencia del diseño, no su punto de partida.

Si el sistema toca permisos que cambian, dispositivos múltiples, o auditoría legal, el jti persistido no es optimización prematura. Es el piso mínimo.

El próximo paso concreto: revisá si tu sistema actual puede responder "¿qué pasa si necesito invalidar todas las sesiones de este usuario en los próximos 30 segundos?". Si la respuesta es "esperar a que venzan los tokens", ya sabés dónde está el agujero de diseño.

Fuentes originales:

• RFC 7519 — JSON Web Token (JWT): https://www.rfc-editor.org/rfc/rfc7519
• OpenID Connect Core 1.0: https://openid.net/specs/openid-connect-core-1_0.html