En este artículo describiré el verdadero propósito de los JSON Web Tokens (JWT). Compararemos la autenticación clásica (con estado) con la autenticación moderna (sin estado). Y podrás comprender cuál es la diferencia fundamental entre ambos enfoques.

Primero, ¿qué es un JWT o JSON Web Token?. Según JWT.io un JWT es un estándar abierto que define una forma compacta y autónoma de transmitir información de forma segura entre las partes en forma de objeto JSON. Son firmados digitalmente, por lo tanto pueden ser verificados y se puede confiar en ellos.

Los JWT constan de tres partes separadas por puntos (.), que son:

• Encabezado
• Carga útil y
• Firma

Se ven de la siguiente manera:

Ahora que ya tienes una idea de qué es y cómo se ve un JWT podemos comenzar.

Nota: Si quieres saber más sobre JWTs mantente al tanto de mis próximos artículos.

Autenticación con Estado

En la antigua web, para la autenticación se trataba de puros estados. Se basaba en una entidad centralizada responsable de los tokens:

• Los tokens se emiten y almacenan en un solo servicio para futuras comprobaciones y revocaciones.

• Los clientes y los servidores conocen un único punto de validez para la verificación de tokens y la recopilación de información.

Funcionó bien en un mundo de sistemas integrados cuando los servidores representaban interfaces y existían dependencias, por ejemplo, a nivel de paquete y no entre aplicaciones implementadas de forma independiente.

Sin embargo, en un mundo donde las aplicaciones están compuestas con una multitud de micro-servicios independientes, este enfoque de autenticación con estado presenta un par de inconvenientes graves:

• Básicamente, ningún servicio puede operar sin tener una dependencia síncrona hacia el almacén central de tokens,

• Éste se convierte en un embudo de infraestructura y un único punto de falla.

De está manera, perdería el enfoque de usar micro-servicios, pues no trabajarían de forma independiente. Así, la autenticación con estado introduce un nuevo problema ¡latencia de red!. Si por un solo segundo nuestro almacén central de tokens dejara de funcionar, todos nuestros micro-servicios estarían condenados. Por eso es que se planteó un nuevo enfoque: ¡Autenticación sin estado!

Autenticación sin Estado

La autenticación sin estado describe un sistema/proceso que permite verificar tokens de una manera descentralizada. Los beneficios de trabajar con este enfoque son:

• Menos latencia a través de la verificación de tokens localmente.

• Respaldos de autorización personalizados debido a la interpretación del token localmente.

• Menor resiliencia al eliminar la sobre carga de la red.

En ocaciones, la autenticación sin estado puede absolver la necesidad de realizar un seguimiento de los tokens emitido y, por este motivo, reduce el almacenamiento de su sistema.

“Usando un JWT como portador de autorización, puede verificar sin estado si el usuario está autenticado simplemente verificando si el vencimiento en la carga útil no ha vencido y la firma es válida”. — Jonatan Nilsson

Dado que los tokens no son opacos (sin carga útil), los clientes también pueden recuperar información adicional (si está presente) sobre la identidad correspondiente directamente desde el token sin necesidad de llamar a otra API remota.

Al usar JWT, debes tener en cuenta lo siguiente:

• No hay una forma viable de invalidar/revocar un JWT, excepto sí solo lo usa como otra cadena aleatoria dentro de un sistema de autenticación con estado. Pero eso lo hablaremos en otro artículo.

• No hay forma de alterar un JWT emitido, por lo que nuevamente no es posible prolongar su fecha de vencimiento.

• Podría usar JWT si realmente lo ayudan a resolver sus problemas. No tienes que usarlos. También puedes conservar tus tokens opacos.

Si tiene más comentarios acerca del propósito de JWT o si cree que me perdí de algo importante, no dudes en comentarme o enviar un mensaje a mi twitter. Agradezco sus comentarios y su tiempo. ¡Gracias!