¿Cómo se usa el token web JSON para la autorización?

Los tokens web JSON, o JWT, constan de tres partes que son importantes para comprender cómo funcionan y por qué.

Un JWT se parece a:

CABECERO CUERPO FIRMA

La primera parte es el encabezado, que almacena información básica, como el algoritmo utilizado para codificar la firma JWT (escuchará más sobre esto cuando lleguemos a la parte firmada).

A continuación tenemos el cuerpo. El cuerpo consiste en la carga útil, que son solo datos que desea tener al verificar un usuario / token. Para este ejemplo, diremos que estamos almacenando la ID del usuario y el nivel de seguridad (lo que indicaría dónde se les permite ingresar a la aplicación).

Tanto el encabezado como el cuerpo están codificados en la codificación Base64 del usuario, por lo que toda la información que contienen es completamente pública. (Nunca almacene información confidencial en un JWT).

La parte que permite la autenticación es la firma. Esto se codifica utilizando cualquier algoritmo definido en el encabezado (y al decodificar la firma debe pasar el algoritmo manualmente, no confíe en el encabezado porque algunos paquetes tienen fallas conocidas que pueden permitir que un JWT no firmado aparezca firmado). Básicamente, usa el contenido de los dos componentes anteriores, y le aplica el algoritmo, y también proporciona un secreto para usar en el hash (esto es conocido solo por la aplicación que desea autenticar).

En esencia, firma = HASHINGALGORITHM (Base64 (HEADER) + ‘.’ + Base64 (BODY) + ‘.’ + SECRET)

Si se altera alguna parte de la secuencia anterior, también lo es el hash de firma.

Entonces, cuando el servidor recibe una solicitud, con un JWT, puede decodificar los dos primeros componentes, ya que solo está codificado en Base64. Sin embargo, la firma requiere que se use el mismo algoritmo de hash (que es de conocimiento público) y el mismo secreto (privado y solo conocido por su aplicación) para crear la misma firma, (los buenos hash no se pueden deshacer, es más fácil adivinar aleatoriamente lo que era un hash criptográficamente seguro de lo que es hacer ingeniería inversa o descifrarlo). Entonces, la firma del JWT solicitante debe ser igual al resultado de ejecutar las dos primeras partes, más el secreto proporcionado a través del mismo algoritmo. Si este es el caso, entonces el servidor puede decir con confianza que el JWT, y su contenido (cambiarlos, aunque sea fácil, alteraría el hash e invalidaría el token) son seguros y como estaban cuando su servidor los emitió.

Si desea leer más, este enlace: JWT.IO – Introducción a los tokens web JSON es un buen lugar para comenzar

JWT es solo otro token. Nada especial, en mi humilde opinión. Entonces, cuando accede a un recurso (API, sitio web o sistemas de almacenamiento como S3 o Google Drive, etc.), el recurso debe verificar dos cosas

a) ¿Es usted un usuario válido, es decir, su identidad es emitida por alguien en quien el recurso confía?

b) ¿Tiene lo necesario para realizar la operación, es decir, si comparto un enlace a Google Drive, solo puede leer pero no escribir? Si accede a cualquier API, solo puede realizar ciertas acciones (como no puede aprobar su propio aumento de salario).

Por lo tanto, cualquier información que se requiera para tomar una decisión o derivar información adicional para tomar una decisión debe integrarse en el token.

¿Qué tendrá el token? ¿Cómo se asegura de que el token sea emitido por alguien de su confianza? ¿Sigue siendo válido? comprometido por alguien en el medio (hombre en el medio),? ¿La información es confidencial? y fue enviado a través de un transporte seguro o encriptado?

Entonces, en el momento en que uno tiene que enviar más información que un número alfanumérico único que puede usar para buscar en su base de datos local para obtener privilegios de autorización, necesita algún formato común que pueda usarse para expresar esos … espere … “Reclamaciones “. 🙂 Por lo tanto, elige un formato / estándar que sea “Sopa del día” … en este caso, es “JWT”.

¿Cómo lo usas? Cuando recibe el token JWT, usa la biblioteca adecuada para decodificar lo que está en el token, asegúrese de que todavía sea válido, no se vea comprometido, descifre si está encriptado, etc. Luego, básicamente, tiene que traducirlo a su plataforma nativa como JAAS o .NET Principal u otros para que su marco pueda ayudarlo a tomar una decisión de autorización (o para un marco personalizado).

El servidor puede usar cualquier reclamo relevante dentro del token para autorización, después de que la firma haya sido verificada (autenticada).

Puede definir cualquier reclamo que necesite la primera vez que autentique al usuario y firme el token.