JSON Web Tokens como componentes básicos para 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 borrador inicial establece: “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 que está 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 notificaciones 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 sugiere dos representaciones de un JWT (a menudo pronunciado "jot"), a saber, 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 más relacionados basados en JSON, todos definidos por un grupo de trabajo llamado JOSE: JSON Object Signing and cifrado.

OAuth 2.0 es un estándar de la industria 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 usarlos, pero los JWT generalmente se usan en estos días. Como se indicó, el enfoque de OAuth está en la autorización y, a veces, también se utilizó indebidamente para manejar la identificación. OpenID Connect agrega 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 algoritmo utilizado, aquí, HS256 (HMAC SHA256). La carga útil depende del tipo de token (acceso/actualización/ID/...) y se compone de notificaciones. 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 payload y luego base64url codificando 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 con !!!my-really-big-256-bit-secret!!!.

Debido a que IBM Cloud ofrece muchos servicios en su catálogo y es una aplicación de Internet con muchos componentes propios, hace un uso intensivo de tokens, incluidos los JWT. Probablemente haya utilizado la IBM Cloud Command Line Interface (CLI) y el comando ibmcloud iam oauth-tokens:

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 en la nube 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 proteger los recursos. Aprovecha los estándares OAuth 2.0 y OpenID Connect mencionados y, por lo tanto, se ocupa de los tokens de acceso, identificación y actualización.

Uno de mis servicios favoritos (y el suyo) es watsonx Assistant para crear un chatbot. 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 fácil e independiente de intercambiar reclamaciones entre dos partes. Son una estructura de datos ubicua, en la nube y on premises. 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á más interesado, use un monitor de red o las developer tools en 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 tienes feedback, sugerencias o preguntas sobre esta publicación, por favor contacta conmigo en Twitter (@data_henrik) o LinkedIn.