JSON Web Token (JWT)

Los tokens web JSON (JWT) son un estándar abierto, que se define en la especificación JSON Web Token (JWT) RFC 7519. Representan con seguridad reclamaciones entre dos partes. Los reclamos pueden estar relacionados con cualquier proceso comercial, pero generalmente se usan para representar una identidad y sus asociaciones. Por ejemplo, un usuario cuya identidad representa el JWT pertenece a una función o grupo de administrador.

Para una introducción a JWT, véase JWT (RFC 7519).

Los reclamos en un JWT están codificados como un objeto JSON y normalmente están firmados digitalmente con un Código de autenticación de mensajes (MAC). El escenario más común para utilizar un JWT es la autenticación. Cuando el usuario inicia sesión, cada solicitud posterior incluye el JWT, que permite al usuario acceder a los servicios permitidos por ese token.

para ver cualCICS® Los métodos de acceso admiten JWT, consulte ¿Qué método de autenticación puedo utilizar con qué método de acceso? .

¿Por qué utilizar JWT?

Las ventajas de utilizar JWT incluyen las siguientes:
  • Son livianos y fáciles de usar para aplicaciones cliente: por ejemplo, aplicaciones móviles.
  • Son autónomos, lo que significa que el servidor Liberty JVM puede consumir el token directamente y utilizar una reclamación del token como identidad para ejecutar la solicitud.
  • Pueden estar firmados simétricamente mediante un secreto compartido mediante el algoritmo HMAC o asimétricamente mediante una clave privada.
  • Tienen un mecanismo de caducidad incorporado.
  • Se pueden ampliar para que contengan declaraciones personalizadas.
  • Son ampliamente adoptados por diferentes soluciones de inicio de sesión único y estándares bien conocidos, como Cómo funciona:OpenID Conectar .

Anatomía de un JWT

Figura 1 muestra que un JWT consta de tres partes: un encabezado, una carga útil y una firma.
Cabecera
El encabezado normalmente consta de dos partes: el tipo de token, que es JWT, y el algoritmo que se utiliza, como HMAC.SHA256 o RSASHA256 . EsBase64Url codificado para formar la primera parte del JWT.
Carga útil
La carga útil contiene las reclamaciones. Hay un conjunto de reclamaciones registradas, por ejemplo,iss (editor),exp (Tiempo de expiración),sub (sujeto), yaud (audiencia). Estos reclamos no son obligatorios, pero se recomiendan para proporcionar un conjunto de reclamos útiles e interoperables. La carga útil también puede incluir atributos adicionales que definan reclamaciones personalizadas, como la función del empleado. Normalmente, la declaración de sujeto se utiliza para crear el sujeto de usuario de OpenID Connect. Sin embargo, el servidor Liberty JVM se puede configurar para utilizar una notificación alternativa. La carga útil esBase64Url codificado para formar la segunda parte del JWT.
Firma
Para crear la parte de la firma, el encabezado codificado y la carga útil codificada se firman utilizando el algoritmo de firma del encabezado. La firma se utiliza para verificar que el emisor del JWT es quien dice ser y para garantizar que el mensaje no haya cambiado en el camino.
Figura 1. Anatomía de un JWT
Anatomía de un JWT
Figura 2 muestra un flujo de autenticación JWT típico.
  1. El usuario inicia sesión con credenciales.
  2. Cuando el usuario se autentica, se crea un JWT y se devuelve al usuario.
  3. Cuando el usuario quiere acceder a un recurso protegido, la aplicación cliente envía el JWT, normalmente en la cabecera HTTP Authorization.
  4. Luego, el servidor de aplicaciones utiliza el JWT, como por ejemploCICS , para identificar al usuario y permitir el acceso al recurso.
Figura 2. Flujo de autenticación JWT
Flujo de autenticación JWT

Soporte para JWT enCICS Libertad

Se puede utilizar un JWT para la propagación de identidades conCICS Libertad. Si el reclamo en cuestión contiene una identidad distribuida, puede configurarCICS Libertad para asignar la identidad distribuida a unRACF® identificación de usuario. Puede configurar la autenticación JWT con un servidor Liberty JVM de varias maneras diferentes, las más comunes incluyen:
  • OpenID Función Conectar cliente (OIDC)

    CICS Apoyos de la libertadOpenID Conectar1.0 . Puedes usar elopenidConnectClient-1.0 característica para configurar un servidor Liberty JVM para aceptar un JWT como token de autenticación. Para más información, ver Cómo funciona:OpenID Conectar .

  • característica JWT

    La libertadjwt-1.0 La característica proporciona un conjunto de API que puede utilizar para trabajar con JWT. Puede utilizar la función para crear o consumir un JWT.

  • Java empresarial Security API

    Enterprise Java™ Security API es una API de proveedor de servicios estándar de Enterprise Java que permite la implementación de mecanismos de autenticación y almacenes de identidades en aplicaciones web de Enterprise Java. Puede desarrollar un mecanismo de autenticación HTTP personalizado que autentique una solicitud que utilice un JWT.

  • Java Authentication Service Provider Interfacefor Containers (JASPIC)

    JASPIC es una API de proveedor de servicios estándar de Enterprise Java que permite la implementación de mecanismos de autenticación en aplicaciones web de Enterprise Java. Puede desarrollar un proveedor de autenticación JASPIC personalizado que autentique una solicitud que utilice un JWT.

  • Interceptor de asociación de confianza (TAI, Trust Association Interceptor)

    Un interceptor de asociación de confianza (TAI) es unWebSphere® API de proveedor de servicios patentada que permite la integración de servicios de seguridad de terceros. Puedes implementar un TAI que inspeccione las peticiones HTTP en busca de un token de seguridad específico, por ejemplo, un JWT, y lo valide. El servidor CICS Liberty debe configurarse para utilizar el TAI implementado.

Recomendado: Cuando utilice JWTs no encriptados, se recomienda encarecidamente que utilice HTTPS para transportar solicitudes que contengan un JWT.

Soporte para JWT enCICS

CICS solo admite JWT creados porRACF . Con esta capacidad, puede convertir las credenciales de autenticación básicas de un usuario en un JWT que luego se utiliza como token de sesión segura por tiempo limitado. Puede validar este token seguro en solicitudes posteriores utilizando elCICS comando API,VERIFY TOKEN . Este soporte también se puede utilizar para convertir un token MFA en un JWT para admitir el uso de tokens MFA en solicitudes sin estado que almacenan en caché las credenciales. Contraseñas, frases de contraseña, tokens MFA yPassTickets son todas las credenciales admitidas.

Si requiere que las peticiones HTTPS o SOAP acepten un JWT creado por RACF, necesita escribir cabeceras personalizadas.

El siguiente diagrama muestra un escenario en el que las credenciales de autenticación básicas se convierten a un JWT para solicitudes posteriores, dondeuser es el ID de usuario ypw es la contraseña.

Figura 3. Conversión de credenciales de autenticación básicas a un JWT
Este diagrama muestra un caso de uso de JWT, donde se utilizan credenciales de autenticación básicas para la primera solicitud. En las solicitudes posteriores, se utiliza un JWT que se convierte a partir de las credenciales de autenticación básicas.