Il existe de nombreuses idées fausses sur le JWT. L'un d'eux, par exemple, que le JWT est chiffré (en fait seulement signé et codé avec base64url). En pratique, je rencontre souvent des solutions assez étranges lorsqu'un seul identifiant de session est stocké dans un JWT (en fait, si vous travaillez avec une session, alors vous n'avez pas besoin d'un JWT). Alternativement, le JWT ne stocke qu'un seul ID utilisateur, dont le profil est demandé à chaque requête de la base de données (en fait, le JWT a du sens si vous souhaitez réduire le nombre de requêtes à la base de données). Ou, encore plus étrange, les JWT eux-mêmes sont stockés dans la base de données.
L'une des raisons objectives de ce malentendu sur le rôle et la place du JWT est que la spécification JWT décrit le format JWT et ne dit rien sur la manière dont le JWT doit être appliqué.
L'envie d'écrire à ce sujet est née depuis longtemps. Et après avoir regardé un autre projet avec une utilisation un peu étrange de JWT, j'ai quand même décidé.
Commençons par la démystification la plus importante. Le JWT pourrait ressembler à ceci:
eyJhbGciOiJSUzI1NiJ9.eyJpcCI6IjE3Mi4yMS4wLjUiLCJqdGkiOiIwNzlkZDMwMGFiODRlM2MzNGJjNWVkMTlkMjg1ZmRmZWEzNWJjYzExMmYxNDJiNmQ5M2Y3YmIxZWFmZTY4MmY1IiwiZXhwIjoxNjA3NTE0NjgxLCJjb3VudCI6MiwidHRsIjoxMH0.gH7dPMvf2TQaZ5uKVcm7DF4glIQNP01Dys7ADgsd6xcxOjpZ7yGhrgd3rMTHKbFyTOf9_EB5NEtNrtgaIsWTtCd3yWq21JhzbmoVXldJKDxjF841Qm4T6JfSth4vvDF5Ex56p7jgL3rkqk6WQCFigwwO2EJfc2ITWh3zO5CG05LWlCEOIJvJErZMwjt9EhmmGlj9B6hSsEGucCm6EDHVlof6DHsvbN2LM3Z9CyiCLNkGNViqr-jkDKbn8UwIuapJOrAT_dumeCWD1RYDL-WNHObaD3owX4iqwHss2yOFrUfdEynahX3jgzHrC36XSRZeEqmRnHZliczz99KeiuHfc56EF11AoxH-3ytOB1sMivj9LID-JV3ihaUj-cDwbPqiaFv0sL-pFVZ9d9KVUBRrkkrwTLVErFVx9UH9mHmIRiO3wdcimBrKpkMIZDTcU9ukAyaYbBlqYVEoTIGpom29u17-b05wY3y12lCA2n4ZqOceYiw3kyd46IYTGeiNmouG5Rb5ld1HJzyqsNDQJhwdibCImdCGhRuKQCa6aANIqFXM-XSvABpzhr1UmxDijzs30ei3AD8tAzkYe2cVhv3AyG63AcFybjFOU8cvchxZ97jCV32jYy6PFphajjHkq1JuZYjEY6kj7L-tBAFUUtjNiy_e0QSSu5ykJaimBsNzYFQ
Si vous le décodez avec base64url, le mythe du "secret" est immédiatement détruit:
{"alg":"RS256"}{"ip":"172.21.0.5","jti":"079dd300ab84e3c34bc5ed19d285fdfea35bcc112f142b6d93f7bb1eafe682f5","exp":1607514681,"count":2,"ttl":10} O2Mrn%!OPzN{hk11l\9 Mkd Z&ۚWJP%^DǞ8*Xև|!䵥C&D0Di?Ak nue7bݟB 6AV*9)S.jNv `EcG9ތ*6kQDv_xzߥEdgbs<wP( Ӂ"?K ?WxiHp<>,/EU]T䒼-Q+\}P fbuȦ 7 ɦZTJ jhonӜ-v 6j9ǘ :!z#fEewQ*44 bl"&t!F *s>]+U&8z-@Fap2p\S܇}0hˣŦy*ԛb1H/A U3bA$) j)
La première partie entre accolades s'appelle l'en-tête JOSE et est décrite à l' adresse https://tools.ietf.org/html/rfc7515 . Peut contenir des champs, dont le plus important alg. Si vous définissez {"alg": "none"} - le jeton est considéré comme valide sans signature. Et ainsi, toute personne disposant d'un jeton généré manuellement sans signature peut accéder à votre API. La plupart des bibliothèques rejettent actuellement ces jetons par défaut, mais vérifiez vos API au cas où.
— . , , , jti — exp — . , JWT — .
, , . . , ( ). , , JWT.
JWT — JSON, .
"" , , JWT. ( - — ).
. ( , "" ) , , .
. , . "" API . JWT , — JWT .
, JWT — , , - , .
, , JWT . ( Redis) . — , .
. JWT , JWT ( )? , "-" . "-" .
"-" . "-" , . , , , - .
Il y a un problème assez intéressant avec l'annulation des jetons "conditionnels". S'ils sont libérés indéfiniment, en cas d'annulation, ils devront également être stockés indéfiniment. Si vous les libérez pendant une certaine période, la déconnexion se produira à partir de la session "éternelle", si pendant la validité du jeton il n'y a pas d'appel à l'API.
apapacy@gmail.com
9 décembre 2020