Ada banyak kesalahpahaman umum seputar JWT. Salah satunya, misalnya, bahwa JWT dienkripsi (sebenarnya hanya ditandatangani dan dienkode dengan base64url). Dalam praktiknya, saya sering menemukan solusi yang agak aneh ketika hanya satu pengidentifikasi sesi yang disimpan di JWT (sebenarnya, jika Anda bekerja dengan sesi, maka Anda tidak memerlukan JWT). Alternatifnya, JWT hanya menyimpan satu ID pengguna, yang profilnya diminta dengan setiap permintaan dari database (faktanya, JWT masuk akal jika Anda ingin mengurangi jumlah permintaan ke database). Atau, yang lebih aneh lagi, JWT sendiri disimpan di database.
Salah satu alasan obyektif untuk kesalahpahaman tentang peran dan tempat JWT ini adalah karena spesifikasi JWT menjelaskan format JWT, dan tidak menjelaskan apa pun tentang bagaimana JWT harus diterapkan.
Keinginan untuk menulis tentang hal ini telah muncul sejak lama. Dan setelah melihat proyek lain dengan penggunaan JWT yang sedikit aneh, saya masih memutuskan.
Mari kita mulai dengan demistifikasi yang paling penting. JWT mungkin terlihat seperti ini:
eyJhbGciOiJSUzI1NiJ9.eyJpcCI6IjE3Mi4yMS4wLjUiLCJqdGkiOiIwNzlkZDMwMGFiODRlM2MzNGJjNWVkMTlkMjg1ZmRmZWEzNWJjYzExMmYxNDJiNmQ5M2Y3YmIxZWFmZTY4MmY1IiwiZXhwIjoxNjA3NTE0NjgxLCJjb3VudCI6MiwidHRsIjoxMH0.gH7dPMvf2TQaZ5uKVcm7DF4glIQNP01Dys7ADgsd6xcxOjpZ7yGhrgd3rMTHKbFyTOf9_EB5NEtNrtgaIsWTtCd3yWq21JhzbmoVXldJKDxjF841Qm4T6JfSth4vvDF5Ex56p7jgL3rkqk6WQCFigwwO2EJfc2ITWh3zO5CG05LWlCEOIJvJErZMwjt9EhmmGlj9B6hSsEGucCm6EDHVlof6DHsvbN2LM3Z9CyiCLNkGNViqr-jkDKbn8UwIuapJOrAT_dumeCWD1RYDL-WNHObaD3owX4iqwHss2yOFrUfdEynahX3jgzHrC36XSRZeEqmRnHZliczz99KeiuHfc56EF11AoxH-3ytOB1sMivj9LID-JV3ihaUj-cDwbPqiaFv0sL-pFVZ9d9KVUBRrkkrwTLVErFVx9UH9mHmIRiO3wdcimBrKpkMIZDTcU9ukAyaYbBlqYVEoTIGpom29u17-b05wY3y12lCA2n4ZqOceYiw3kyd46IYTGeiNmouG5Rb5ld1HJzyqsNDQJhwdibCImdCGhRuKQCa6aANIqFXM-XSvABpzhr1UmxDijzs30ei3AD8tAzkYe2cVhv3AyG63AcFybjFOU8cvchxZ97jCV32jYy6PFphajjHkq1JuZYjEY6kj7L-tBAFUUtjNiy_e0QSSu5ykJaimBsNzYFQ
Jika Anda mendekodekannya dengan base64url, mitos "kerahasiaan" segera dihancurkan:
{"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)
Bagian pertama dalam kurung kurawal disebut JOSE Header dan dijelaskan di https://tools.ietf.org/html/rfc7515 . Mungkin berisi bidang, yang paling penting alg. Jika Anda menyetel {"alg": "none"} - token dianggap valid tanpa tanda tangan. Dan dengan demikian, API Anda dapat diakses oleh siapa saja dengan token yang dibuat secara manual tanpa tanda tangan. Sebagian besar perpustakaan saat ini menolak token semacam itu secara default, tetapi periksa API Anda untuk berjaga-jaga.
— . , , , jti — exp — . , JWT — .
, , . . , ( ). , , JWT.
JWT — JSON, .
"" , , JWT. ( - — ).
. ( , "" ) , , .
. , . "" API . JWT , — JWT .
, JWT — , , - , .
, , JWT . ( Redis) . — , .
. JWT , JWT ( )? , "-" . "-" .
"-" . "-" , . , , , - .
Ada satu masalah yang cukup menarik dengan pembatalan token "bersyarat". Jika dirilis tanpa batas waktu, jika terjadi pembatalan, mereka juga harus disimpan tanpa batas. Jika Anda melepaskannya untuk jangka waktu tertentu, maka logout akan terjadi dari sesi "abadi", jika selama validitas token tidak ada panggilan API.
apapacy@gmail.com
9 Desember 2020