Los tokens web JSON como pilares de la seguridad en la nube

El primer borrador para tokens web JSON ya tiene más de 10 años (es de diciembre de 2010). El primer borrador afirma:"JSON Web Token (JWT) define un formato de token que puede codificar reclamaciones transferidas entre dos partes. Las reclamaciones en un JWT se codifican como un objeto JSON firmado digitalmente".

En su última versión, IETF RFC 7519, se amplió a lo siguiente:"JSON Web Token (JWT) es un medio compacto y seguro para URL de representar reclamaciones que se transferirán entre dos partes. Las notificaciones en un JWT se codifican como un objeto JSON que se utiliza como carga útil de una estructura JSON Web Signature (JWS) o como texto sin formato de una estructura JSON Web Encryption (JWE), lo que permite firmar digitalmente las notificaciones o proteger su integridad. con un código de autenticación de mensajes (MAC) y/o cifrado.“

La nueva descripción insinúa dos representaciones de un JWT (a menudo pronunciado "jot"): una firma web JSON (JWS) o una estructura de cifrado web JSON (JWE). JWS se define en RFC 7515, JWE en RFC 7516. Incluso hay algunos estándares de seguridad basados en JSON relacionados, todos definidos por un grupo de trabajo llamado JOSE: JSON Object Signing and Encryption.

OAuth 2.0 es un estándar del sector para la autorización. Sin entrar en detalles, ofrece un flujo de autorización y conceptos básicos, incluidos los llamados token de acceso y token de actualización. No es un requisito utilizarlos, pero los JWT se utilizan normalmente en estos días. Como se ha dicho, el enfoque de OAuth se centra en la autorización y, a veces, también se ha utilizado indebidamente para gestionar la identificación. OpenID Connect añade esta pieza faltante en el rompecabezas e introduce la identidad o el token de identificación. El token de ID se representa como JWT.

Con esa historia y algunos estándares como base, ¿cómo podemos procesar el JWT desde arriba y qué información contiene?

El JWT anterior consta de tres partes, separadas cada una por un punto (‘.’):

1. Encabezado:: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
2. Carga útil: eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
3. Firma: _iVbBcypdse-9sjrxp9iOrGsXKBWrBB3mrHgBtukcfM

Tanto el encabezado como la carga útil están codificados en base64url y, sin tener en cuenta el posible relleno, se pueden decodificar así:

henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}

henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input

El encabezado contiene información sobre el alg(oritmo) utilizado, aquí, HS256 (HMAC SHA256). La carga útil depende del tipo de token (acceso/actualización/ID/…) y se compone de reclamaciones. Esos y otros campos predefinidos de encabezado y carga útil de JOSE son gestionados por IANA. En el ejemplo anterior, los campos y reclamaciones son asunto (ect), nombre, emitido a las (iat) y exp (fecha de caducidad).

La firma se calcula aplicando el algoritmo indicado a la concatenación del encabezado, ‘.’ y la carga útil y, a continuación, codificar en base64url el resultado. A partir de entonces, las tres partes separadas por un punto forman el JWT. Los detalles de cómo se derivan las firmas se definen en RFC 7515.

Puede acceder al JWT anterior en este depurador en línea en JTW.io. Primero, mostrará el mensaje “Firma no válida”. Puede resolverlo reemplazando el secreto predeterminado que se muestra por !!!my-really-big-256-bit-secret!!!.

Dado que IBM Cloud ofrece muchos servicios en su catálogo y es una aplicación con muchos componentes, hace un uso intensivo de tokens, incluidos los JWT. Probablemente haya utilizado la interfaz de línea de comandos (CLI) de IBM Cloud  y el comando ibmcloud IAM oauth-token:

Imprime el token de portador de OAuth (token de acceso) para la sesión CLI actual, implementados como JWT. Estos tokens de IAM se utilizan para acceder a servicios cloud habilitados para IAM. 

Si desea integrar usuarios externos en su cuenta en la nube, también se utilizan JWT. Los tokens de identidad y sus notificaciones incluidas se intercambian por autenticación para identificar al usuario. Muchas soluciones utilizan el servicio de seguridad IBM Cloud App ID. Ayuda a autenticar a los usuarios y a proteger los recursos. Aprovecha los estándares OAuth 2.0 y OpenID Connect mencionados y, por lo tanto, se ocupa de tokens de acceso, ID y actualización.

Uno de mis servicios favoritos (y el suyo) es watsonx Assistant para crear chatbots. Si desea proteger los chats web (es decir, proteger aún más los mensajes intercambiados y certificar el origen de los mensajes), los JWT vienen al rescate.

Por supuesto, hay muchos más ejemplos de cómo se utilizan los JWT para intercambiar fácilmente reclamaciones (de seguridad) y, por lo tanto, reforzar la seguridad de una solución en la nube.

Los JWT son un medio sencillo y autónomo de intercambiar reclamaciones entre dos partes. Son una estructura de datos omnipresente, en la nube y en las instalaciones. Con suerte, lo anterior fue una introducción útil para que se interese (¡si aún no lo estaba!).

Si desea examinar y jugar con los JWT usted mismo, le recomiendo una herramienta en línea como https://jwt.io/ para comenzar. Si está interesado en profundizar, utilice un monitor de red o las herramientas para desarrolladores de su navegador para tener cuidado con los JWT. Diviértase y consulte nuestros tutoriales de IBM Cloud, que incluyen muchos tutoriales relacionados con la seguridad.

Si tiene comentarios, sugerencias o preguntas sobre esta publicación, póngase en contacto conmigo en Twitter (@data_henrik) o LinkedIn.