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 ( 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 — 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