JSON Web Token ( JWT , pronunciado / dʒ ɒ t / , igual que la palabra "jot" [1] ) es un estándar de Internet propuesto para crear datos con firma opcional y / o encriptación opcional cuya carga útil contiene JSON que afirma cierto número de afirmaciones . Los tokens se firman utilizando un secreto privado o una clave pública / privada.. Por ejemplo, un servidor podría generar un token que tenga el reclamo "iniciado sesión como administrador" y proporcionárselo a un cliente. El cliente podría usar ese token para demostrar que inició sesión como administrador. Los tokens se pueden firmar con la clave privada de una de las partes (generalmente la del servidor) para que la parte pueda verificar posteriormente que el token es legítimo. Si la otra parte, por algún medio adecuado y confiable, está en posesión de la clave pública correspondiente, ellos también pueden verificar la legitimidad del token. Los tokens están diseñados para ser compactos, [2] seguros para URL , [3] y utilizables especialmente en un inicio de sesión único en un navegador web. (SSO) contexto. Las reclamaciones de JWT se pueden utilizar normalmente para pasar la identidad de los usuarios autenticados entre un proveedor de identidad y un proveedor de servicios , o cualquier otro tipo de reclamaciones según lo requieran los procesos comerciales. [4] [5]
Estado | Norma propuesta |
---|---|
Publicado por primera vez | 28 de diciembre de 2010 |
Ultima versión | RFC 7519 Mayo de 2015 |
Organización | IETF |
Abreviatura | JWT |
JWT se basa en otros estándares basados en JSON : JSON Web Signature y JSON Web Encryption . [1] [6] [7]
Estructura
Encabezamiento | { "alg" : "HS256" , "typ" : "JWT" } | Identifica qué algoritmo se utiliza para generar la firma.
Los algoritmos criptográficos típicos utilizados son HMAC con SHA-256 (HS256) y firma RSA con SHA-256 (RS256). JWA (JSON Web Algorithms) RFC 7518 introduce muchos más tanto para la autenticación como para el cifrado. [8] |
---|---|---|
Carga útil | { "logInAs" : "admin" , "iat" : 1422779638 } | Contiene un conjunto de afirmaciones. La especificación JWT define siete nombres de reclamos registrados que son los campos estándar que se incluyen comúnmente en los tokens. [1] Los reclamos personalizados generalmente también se incluyen, según el propósito del token. Este ejemplo tiene el reclamo estándar emitido en el momento ( |
Firma | HMAC - SHA256 ( secreto , codificación base64url ( encabezado ) + '.' + Codificación base64url ( carga útil ) ) | Valida de forma segura el token. La firma se calcula codificando el encabezado y la carga útil utilizando la codificación Base64urlRFC 4648 y concatenando los dos juntos con un separador de punto. Luego, esa cadena se ejecuta a través del algoritmo criptográfico especificado en el encabezado, en este caso HMAC-SHA256. La codificación Base64url es similar a base64 , pero utiliza diferentes caracteres no alfanuméricos y omite el relleno. |
Las tres partes se codifican por separado utilizando la codificación Base64urlRFC 4648 y concatenados mediante puntos para producir el JWT:
token constante = codificación base64url ( encabezado ) + '.' + base64urlEncoding ( carga útil ) + '.' + base64urlEncoding ( firma )
Los datos anteriores y el secreto de "secretkey" crean el token:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLMCpyCiuzSraSYS8EXBxLmCpyCiuz
Este token resultante se puede pasar fácilmente a HTML y HTTP . [3]
Usar
En la autenticación, cuando el usuario inicia sesión con éxito con sus credenciales, se devolverá un JSON Web Token y se debe guardar localmente (generalmente en el almacenamiento local o de sesión , pero también se pueden usar cookies ), en lugar del enfoque tradicional de crear una sesión. en el servidor y devolviendo una cookie. Para los procesos desatendidos, el cliente también puede autenticarse directamente generando y firmando su propio JWT con un secreto previamente compartido y pasarlo a un servicio compatible con OAuth de la siguiente manera:
POST / oauth2 / token? Tipo de contenido: aplicación / x-www-form-urlencoded grant_type = urn: ietf: params: oauth: grant-type: jwt-bearer & assertion = eyJhb ...
Si el cliente pasa una aserción JWT válida, el servidor generará un access_token válido para realizar llamadas a la aplicación y devolverlo al cliente:
{ "access_token" : "eyJhb ..." , "token_type" : "Bearer" , "expires_in" : 3600 }
Cuando el cliente desea acceder a una ruta o recurso protegido, el agente de usuario debe enviar el JWT, generalmente en el Authorization
encabezado usando el Bearer
esquema. El contenido del encabezado puede tener el siguiente aspecto:
Autorización: Portador eyJhbGci ... < snip > ... yu5CSpyHI
Este es un mecanismo de autenticación sin estado, ya que el estado del usuario nunca se guarda en la memoria del servidor. Las rutas protegidas del servidor buscarán un JWT válido en el encabezado de Autorización y, si está presente, el usuario podrá acceder a los recursos protegidos. Como los JWT son autónomos, toda la información necesaria está allí, lo que reduce la necesidad de consultar la base de datos varias veces.
Campos estándar
Los borradores de Internet definen los siguientes campos estándar ("reclamos") que se pueden usar dentro de un conjunto de reclamos de JWT:
código | nombre | descripción |
---|---|---|
iss | Editor | Identifica al principal que emitió el JWT. |
sub | Sujeto | Identifica el sujeto del JWT. |
aud | Audiencia | Identifica los destinatarios a los que está destinado el JWT. Cada director destinado a procesar el JWT debe identificarse con un valor en el reclamo de audiencia. Si el principal que procesa el reclamo no se identifica con un valor en el aud reclamo cuando este reclamo está presente, entonces el JWT debe ser rechazado. |
exp | Tiempo de expiración | Identifica el tiempo de vencimiento en y después del cual el JWT no debe aceptarse para su procesamiento. El valor debe ser NumericDate: [9] ya sea un número entero o decimal, que represente los segundos después de 1970-01-01 00: 00: 00Z . |
nbf | No antes | Identifica la hora en la que el JWT comenzará a ser aceptado para su procesamiento. El valor debe ser NumericDate. |
iat | Emitido en | Identifica el momento en que se emitió el JWT. El valor debe ser NumericDate. |
jti | ID de JWT | Identificador único sensible a mayúsculas y minúsculas del token incluso entre diferentes emisores. |
Los siguientes campos se utilizan comúnmente en el encabezado de un JWT:
código | nombre | descripción |
---|---|---|
typ | Tipo de token | Si está presente, se recomienda configurarlo en JWT . |
cty | Tipo de contenido | Si se emplea la firma anidada o el cifrado, se recomienda configurarlo en JWT ; de lo contrario, omita este campo. [1] |
alg | Algoritmo de código de autenticación de mensajes | El emisor puede configurar libremente un algoritmo para verificar la firma en el token. Sin embargo, algunos algoritmos compatibles son inseguros. [10] |
kid | ID de clave | Una pista que indica qué clave usó el cliente para generar la firma del token. El servidor comparará este valor con una clave en el archivo para verificar que la firma es válida y el token es auténtico. |
x5c | Cadena de certificado x.509 | Una cadena de certificados en formato RFC4945 correspondiente a la clave privada utilizada para generar la firma del token. El servidor utilizará esta información para verificar que la firma sea válida y que el token sea auténtico. |
x5u | x.509 URL de la cadena de certificados | Una URL donde el servidor puede recuperar una cadena de certificados correspondiente a la clave privada utilizada para generar la firma del token. El servidor recuperará y utilizará esta información para verificar que la firma sea auténtica. |
crit | Crítico | Una lista de encabezados que el servidor debe entender para aceptar el token como válido |
Implementaciones
Existen implementaciones de JWT para muchos lenguajes y marcos, que incluyen, entre otros:
- .NET (C # VB.Net, etc.) [11]
- C [12]
- Clojure [13]
- Lisp común [14]
- Dardo [15]
- Elixir [16]
- Erlang
- Ir [17]
- Haskell [18]
- Java [19]
- JavaScript [20]
- Lua [21]
- Node.js [22]
- OCaml [23]
- Perl [24]
- PHP [25]
- PL / SQL [26]
- PowerShell [27]
- Python [28]
- Raqueta [29]
- Raku [30]
- Rubí [31]
- Óxido [32] [33]
- Scala [34]
- Rápido [35]
Vulnerabilidades
Los tokens web JSON pueden contener el estado de la sesión. Pero si los requisitos del proyecto permiten la invalidación de la sesión antes del vencimiento de JWT, los servicios ya no pueden confiar en las afirmaciones del token solo por el token. Para validar que la sesión almacenada en el token no se revoca, las afirmaciones del token se deben comparar con un almacén de datos . Esto hace que los tokens ya no sean apátridas, lo que socava la ventaja principal de los JWT. [36]
El consultor de seguridad Tim McLean informó vulnerabilidades en algunas bibliotecas JWT que usaban el alg
campo para validar tokens incorrectamente, más comúnmente al aceptar un alg=none
token. Si bien estas vulnerabilidades fueron parcheadas, McLean sugirió desaprobar el alg
campo por completo para evitar una confusión de implementación similar. [10] Aún así, alg=none
todavía se están encontrando nuevas vulnerabilidades en la naturaleza, con cuatro CVE presentados en el período 2018-2021 que tienen esta causa. [37]
Con un diseño adecuado, los desarrolladores pueden abordar las vulnerabilidades de los algoritmos tomando precauciones: [38] [39]
- Nunca deje que el encabezado JWT solo impulse la verificación
- Conozca los algoritmos (evite depender
alg
solo del campo) - Utilice un tamaño de clave apropiado
El arquitecto de seguridad de software Kurt Rodarmer señala vulnerabilidades de diseño de JWT adicionales en torno a las claves de firma criptográficas y una vulnerabilidad significativa que expone el analizador JSON de una biblioteca a un ataque abierto. [40] Este es un resultado directo de elegir JSON para expresar el encabezado del token y es más difícil de mitigar.
Ver también
- Token de acceso
Referencias
- ^ a b c d Jones, Michael B .; Bradley, Bradley; Sakimura, Sakimura (mayo de 2015). Token web JSON (JWT) . IETF . doi : 10.17487 / RFC7519 . ISSN 2070-1721 . RFC 7519 .
- ^ Nickel, Jochen (2016). Dominar la gestión de identidades y accesos con Microsoft Azure . pag. 84. ISBN 9781785887888. Consultado el 20 de julio de 2018 .
- ^ a b "JWT.IO - Introducción a los tokens web JSON" . jwt.io . Consultado el 20 de julio de 2018 .
- ^ Sevilleja, Chris. "La anatomía de un token web JSON" . Consultado el 8 de mayo de 2015 .
- ^ "Documentación de Atlassian Connect" . developer.atlassian.com . Consultado el 8 de mayo de 2015 .
- ^ "borrador-ietf-jose-json-web-signature-41 - JSON Web Signature (JWS)" . tools.ietf.org . Consultado el 8 de mayo de 2015 .
- ^ "borrador-ietf-jose-json-web-encryption-40 - JSON Web Encryption (JWE)" . tools.ietf.org . Consultado el 8 de mayo de 2015 .
- ^ "borrador-ietf-jose-json-web-algorítms-40 - JSON Web Algorithms (JWA)" . tools.ietf.org . Consultado el 8 de mayo de 2015 .
- ^ Jones, Michael B .; Bradley, Bradley; Sakimura, Sakimura (mayo de 2015). " " Exp "(Expiración de tiempo) Reclamación" . Token web JSON (JWT) . IETF . segundo. 4.1.4. doi : 10.17487 / RFC7519 . ISSN 2070-1721 . RFC 7519 .
- ^ a b McLean, Tim (31 de marzo de 2015). "Vulnerabilidades críticas en bibliotecas JSON Web Token" . Auth0 . Consultado el 29 de marzo de 2016 .
- ^ jwt- dotnet en github.com
- ^ libjwt en github.com
- ^ "liquidz / clj-jwt" . GitHub . Consultado el 7 de mayo de 2018 .
- ^ cljwt en github.com
- ^ [1] en github.com
- ^ "bryanjos / broma" . GitHub . Consultado el 7 de mayo de 2018 .
- ^ "dgrijalva / jwt-go" . GitHub . Consultado el 8 de enero de 2018 .
- ^ "jwt: codificación y decodificación de JSON Web Token (JWT)" . Hackage . Consultado el 7 de mayo de 2018 .
- ^ auth0 / java-jwt en github.com
- ^ "kjur / jsrsasign" . GitHub . Consultado el 7 de mayo de 2018 .
- ^ "SkyLothar / lua-resty-jwt" . GitHub . Consultado el 7 de mayo de 2018 .
- ^ "jsonwebtoken" . npm . Consultado el 7 de mayo de 2018 .
- ^ ocaml-jwt en github.com
- ^ Cripta :: JWT en cpan.org
- ^ lcobucci / jwt en github.com
- ^ Egan, Morten (7 de febrero de 2019), GitHub - morten-egan / jwt_ninja: Implementación PLSQL de JSON Web Tokens. , consultado el 14 de marzo de 2019
- ^ "SP3269 / posh-jwt" . GitHub . Consultado el 1 de agosto de 2018 .
- ^ "jpadilla / pyjwt" . GitHub . Consultado el 21 de marzo de 2017 .
- ^ net-jwt en pkgs.racket-lang.org
- ^ JSON-WebToken en github.com
- ^ ruby-jwt en github.com
- ^ frank_jwt en github.com
- ^ [2] en github.com
- ^ jwt-scala en github.com
- ^ [3] en github.com
- ^ Slootweg, Sven. "Deje de usar JWT para las sesiones" . joepie91 Divagaciones . Consultado el 1 de agosto de 2018 .
- ^ "CVE - Resultados de la búsqueda" . cve.mitre.org .
- ^ "Vulnerabilidades de seguridad comunes de JWT y cómo evitarlas" . Consultado el 14 de mayo de 2018 .
- ^ Andreas, Happe. "JWT: Firma vs ataques MAC" . snikt.net . Consultado el 27 de mayo de 2019 .
- ^ Rodarmer, Kurt (21 de julio de 2019). "Vulnerabilidades de seguridad oscuras de JWT" . rodarmer.com . Consultado el 25 de julio de 2019 .
enlaces externos
- RFC 7519
- jwt.io - sitio web especializado sobre JWT con herramientas y documentación, mantenido por Auth0
- Spring Boot JWT Auth : integración de la autenticación JWT con Spring Framework
- JWT Security - PDF de libro electrónico de seguridad JWT (idioma polaco)
- ¿Por qué necesitamos JWT en la web moderna ? Un artículo detallado sobre el tema con algunas consideraciones históricas.