Hay muchos conceptos erróneos comunes en torno al JWT. Uno de ellos, por ejemplo, que el JWT está encriptado (en realidad solo está firmado y codificado con base64url). En la práctica, a menudo me encuentro con soluciones bastante extrañas cuando solo se almacena un identificador de sesión en un JWT (de hecho, si trabaja con una sesión, entonces no necesita un JWT). Alternativamente, el JWT almacena solo una ID de usuario, cuyo perfil se solicita con cada solicitud de la base de datos (de hecho, el JWT tiene sentido si desea reducir el número de solicitudes a la base de datos). O, lo que es aún más extraño, los propios JWT se almacenan en la base de datos.
Una de las razones objetivas de este malentendido de la función y el lugar del JWT es que la especificación JWT describe el formato JWT y no dice nada sobre cómo se debe aplicar el JWT.
El deseo de escribir sobre esto ha surgido durante mucho tiempo. Y después de mirar otro proyecto con un uso un poco extraño de JWT, todavía lo decidí.
Empecemos por la desmitificación más importante. El JWT podría verse así:
eyJhbGciOiJSUzI1NiJ9.eyJpcCI6IjE3Mi4yMS4wLjUiLCJqdGkiOiIwNzlkZDMwMGFiODRlM2MzNGJjNWVkMTlkMjg1ZmRmZWEzNWJjYzExMmYxNDJiNmQ5M2Y3YmIxZWFmZTY4MmY1IiwiZXhwIjoxNjA3NTE0NjgxLCJjb3VudCI6MiwidHRsIjoxMH0.gH7dPMvf2TQaZ5uKVcm7DF4glIQNP01Dys7ADgsd6xcxOjpZ7yGhrgd3rMTHKbFyTOf9_EB5NEtNrtgaIsWTtCd3yWq21JhzbmoVXldJKDxjF841Qm4T6JfSth4vvDF5Ex56p7jgL3rkqk6WQCFigwwO2EJfc2ITWh3zO5CG05LWlCEOIJvJErZMwjt9EhmmGlj9B6hSsEGucCm6EDHVlof6DHsvbN2LM3Z9CyiCLNkGNViqr-jkDKbn8UwIuapJOrAT_dumeCWD1RYDL-WNHObaD3owX4iqwHss2yOFrUfdEynahX3jgzHrC36XSRZeEqmRnHZliczz99KeiuHfc56EF11AoxH-3ytOB1sMivj9LID-JV3ihaUj-cDwbPqiaFv0sL-pFVZ9d9KVUBRrkkrwTLVErFVx9UH9mHmIRiO3wdcimBrKpkMIZDTcU9ukAyaYbBlqYVEoTIGpom29u17-b05wY3y12lCA2n4ZqOceYiw3kyd46IYTGeiNmouG5Rb5ld1HJzyqsNDQJhwdibCImdCGhRuKQCa6aANIqFXM-XSvABpzhr1UmxDijzs30ei3AD8tAzkYe2cVhv3AyG63AcFybjFOU8cvchxZ97jCV32jYy6PFphajjHkq1JuZYjEY6kj7L-tBAFUUtjNiy_e0QSSu5ykJaimBsNzYFQ
Si lo decodifica con base64url, el mito del "secreto" se destruye inmediatamente:
{"alg":"RS256"}{"ip":"172.21.0.5","jti":"079dd300ab84e3c34bc5ed19d285fdfea35bcc112f142b6d93f7bb1eafe682f5","exp":1607514681,"count":2,"ttl":10} O2Mrn%!OPzN{hk11l\9Mkd Z&ۚWJP%^DǞ8*Xև|!䵥C&D0Di?Ak nue7bݟB 6AV*9)S.jNv `EcG9ތ*6kQDv_xzߥEdgbs<wP(Ӂ"?K ?WxiHp<>,/EU]T䒼-Q+\}PfbuȦ 7�ɦZTJ jhonӜ-v 6j9ǘ :!z#fEewQ*44 bl"&t!F �*s>]+U&8z-@Fap2p\S܇}0hˣŦy*ԛb1H/A�U3bA$) j)
La primera parte entre llaves se llama JOSE Header y se describe en https://tools.ietf.org/html/rfc7515 . Puede contener campos, de los cuales el alg. Más importante. Si establece {"alg": "none"}, el token se considera válido sin una firma. Y, por lo tanto, cualquier persona que tenga un token generado manualmente sin una firma puede acceder a su API. La mayoría de las bibliotecas rechazan estos tokens de forma predeterminada, pero compruebe sus API por si acaso.
— . , , , jti — exp — . , JWT — .
, , . . , ( ). , , JWT.
JWT — JSON, .
"" , , JWT. ( - — ).
. ( , "" ) , , .
. , . "" API . JWT , — JWT .
, JWT — , , - , .
, , JWT . ( Redis) . — , .
. JWT , JWT ( )? , "-" . "-" .
"-" . "-" , . , , , - .
Hay un problema bastante interesante con la cancelación de tokens "condicionales". Si se liberan indefinidamente, en caso de cancelación, también deberán almacenarse indefinidamente. Si los libera durante un período determinado, se cerrará la sesión de la sesión "eterna", si durante la validez del token no hay ninguna llamada a la API.
apapacy@gmail.com
9 de diciembre de 2020