Arquitectura sin estado y con estado

Se refiere al estado de la aplicación, es decir, la condición o la calidad de la misma en un momento determinado. En la autenticación sin estado, no hay ninguna sesión o usuario almacenado, que contiene solo contenido estático. Esto difiere de stateful, que es contenido dinámico.

Un proceso sin estado es un recurso aislado, que no hace referencia a ningún otro servicio o interacción con otro sistema. Opera sólo en esa parte del código, sin traer información de transacciones antiguas, ya que la autenticación sin estado no almacena este tipo de datos; cada operación se realiza desde cero.

La autenticación con estado permite que la información se use más de una vez y se ejecuta en función del contexto de transacciones anteriores. Por lo tanto, en aplicaciones donde es necesario esperar una respuesta o datos preexistentes, ya sean presentes en otro sistema o base de datos, se utiliza stateful.

Autenticación sin estado

La autenticación sin estado consiste en una estrategia en la que, después de proporcionar las credenciales, el usuario recibe un token de acceso como respuesta. Este token ya contiene toda la información necesaria para identificar al usuario que lo generó, sin necesidad de consultar continuamente el servicio que emitió el token ni una base de datos.

Este token se almacena en el lado del cliente (navegador), por lo que el servidor solo tiene la capacidad de verificar la validez del token confirmando que la carga útil y la firma coinciden.

Autenticación sin estado JWT

JSON Web Token (JWT) son ​​claves con estándares establecidos en RFC-7519, que contienen una entidad en forma de declaraciones, las cuales son independientes, sin necesidad de llamar al servidor para revalidar el token.

¿Las cadenas están codificadas en el estándar base64 usando una clave secreta, como en el ejemplo:

Ventajas y desventajas

Ventajas:

• Bajo consumo de memoria del servidor.
• Excelente en términos de escalabilidad.
• Ideal para aplicaciones distribuidas, como API y microservicios.
• Generación y distribución del token en una aplicación aislada, sin dependencia de terceros.
• Fácil interpretación y validación de los datos del usuario token.

Desventajas:

• Dificultad en el control de acceso.
• No es posible revocar el token fácilmente en ningún momento.
• Puede facilitar la entrada de terceros malintencionados, si alguien tiene acceso al token.
• La sesión no se puede cambiar hasta que caduque el token.
• El token JWT es más complejo y puede resultar innecesario en aplicaciones centralizadas, como los monolitos.

Autenticación con estado

Comúnmente utilizado en varias aplicaciones, especialmente aquellas que no requieren tanta escalabilidad, la sesión con estado se crea en el back-end de la aplicación y la referencia de la sesión se envía de regreso al usuario correspondiente. . Cada vez que el usuario realiza una solicitud, parte de la aplicación genera el token. A partir de ese momento, con cada nueva solicitud, este token será enviado nuevamente a la aplicación para revalidar el acceso. En este modelo, si hay algún cambio en los datos del usuario, el token se puede revocar fácilmente.

Estos son tokens de acceso opacos, es decir, una cadena simple en un formato propietario que no contiene ningún identificador ni datos de usuario relacionados con ese token. El destinatario debe llamar al servidor que creó el token para validarlo.

Token de ejemplo: 8c90e55a-e867-45d5-9e42-8fcbd9c30a74

Esta ID debe almacenarse en una base de datos con el usuario propietario del token.

Ventajas y desventajas

Ventajas:

• Lógica de implementación centralizada.
• Gestión y control de acceso simplificado.
• Excelente para monolitos, aplicaciones MVC y procesos internos.
• Más seguro contra terceros malintencionados.

Desventajas:

• Puede haber una sobrecarga en la API encargada de validar el token.
• Fracaso en términos de escalabilidad.
• Mayor dificultad para distribuir la autenticación entre microservicios.
• En una aplicación distribuida, si el servicio de autenticación falla, todos los demás servicios dejan de estar disponibles.
• Mayor complejidad de implementación.
• Mayor dificultad para integrarse con sistemas de terceros.

¿Cuándo utilizar cada enfoque?

Cuándo utilizar un token JWT y una autenticación sin estado

• Cuando se necesita un mayor rendimiento sin preocuparse por sobrecargar una API.
• Cuando existen varias comunicaciones distribuidas entre servicios.
• Cuando es necesario identificar qué usuario está realizando una acción en el sistema en diferentes servicios.
• Cuando no se pretenda persistir los datos de un usuario, sólo su registro inicial.
• Si es necesario generar acceso externo al servicio.
• Si es necesario manipular los datos de quien está realizando una determinada acción con el mínimo impacto en el sistema.

Cuándo utilizar un token opaco y una autenticación con estado

• Si es necesario un control total del acceso de los usuarios de un sistema, principalmente para definir la jerarquía de acceso.
• En una aplicación centralizada, sin servicios distribuidos y sin comunicación con servicios externos.

Consideraciones finales:

• En algunos lugares, como "estrés de API", el término puede reemplazarse por "sobrecarga de API" para mayor claridad.
• La sección sobre "Token JWT" podría incluir una explicación más detallada de cuáles son las "declaraciones" mencionadas en RFC-7519, si el público objetivo necesita más contexto.
• En la sección sobre autenticación con estado, la frase "una parte de la aplicación generará el token" podría aclararse explicando qué parte específica de la aplicación es responsable de esto.