Gumawa ng JWT

[ NALAGDAANG TOKEN ]
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikp1YW4gZGVsYSBDcnV6Iiwicm9sZSI6Im1lbWJlciIsImlhdCI6MTc1NjQwMDAwMCwiZXhwIjoxNzU2NDg2NDAwfQ.pnPNkoEKwYrDchfBXVPlHK_UCMeqNvIkaXCaaUJJXuw
HS256 · nilagdaan gamit ang lihim na 38 byte
AlgorithmHS256
Secret38 bytes
Haba207 chars
[ WHAT ANYONE HOLDING THIS TOKEN CAN READ ]
Header
{"alg":"HS256","typ":"JWT"}
Payload
{"sub":"1234567890","name":"Juan dela Cruz","role":"member","iat":1756400000,"exp":1756486400}

No secret was needed to produce either of those. They were read straight out of the token above.

Anyone holding this token can read the payload without the secret — base64url is an encoding, not encryption. The signature proves the token was not altered; it hides nothing.
Nilagdaan sa browser mo. Hindi kailanman ipinapadala o iniimbak ang lihim — at dahil ganoon, hindi rin kayang suriin ng pahinang ito ang token ng iba para sa iyo.
[ ANO ITO ]

Ang JWT ay pinipirmahan, hindi ini-encrypt. Ang isang pangungusap na iyon ang dahilan kung bakit ipinapakita ng pahinang ito ang na-decode na payload katabi mismo ng token.

Ang gitnang bahagi ng JWT ay base64url — isang encoding, na kayang baligtarin ninuman, at hindi cipher, na nangangailangan ng susi. Kayang basahin ng bawat may hawak ng token ang bawat claim doon. Iba at mas makitid ang ginagawa ng pirma: pinapatunayan nitong hindi binago ang token mula nang pirmahan mo. Wala itong itinatago.

Naglalagay ang mga tao ng password, numero ng pagkakakilanlan at internal na flag sa payload dahil mukhang naka-encrypt ang token — mahaba at malabong string na walang kahulugan sa mata. Ang generator na ang string lamang na iyon ang ipinapakita ay tumutulong sa mambabasang maniwala sa mali, kaya dini-decode ito pabalik ng isang ito para sa iyo at tinutukoy ang alinmang claim na mukhang lihim ang key.

Walang "none" na algorithm dito at hindi magkakaroon kailanman. Kayang pekein ninuman ang hindi ligtas na token, at ang server na tumatanggap nito ay walang anumang authentication. Ang header na sinusubukang itakda ang algorithm ay tinatanggihan sa halip na tahimik na palitan — dapat mong malaman na hindi ka makakagawa ng ganoon, hindi maniwalang nakagawa ka.

Segundo ang timestamp, hindi millisecond. Ang exp, iat at nbf ay segundo mula sa epoch; millisecond ang Date.now(). Ipasa ang isa nang diretso at mag-e-expire ang token mo pagkalipas ng mga limampung libong taon, at walang anumang magrereklamo kahit saan.

[ MGA TANONG ]

Naka-encrypt ba ang payload ng JWT?

Hindi, at ito ang maling pagkakaunawang pinagtuunan ng buong pahina. Ang payload ay base64url — encoding, hindi cipher. Kayang basahin ninumang may hawak ng token ang bawat claim dito nang walang lihim, kaya ipinapakita ng pahinang ito ang na-decode na payload sa tabi ng token sa halip na itago ito. Pinatutunayan ng lagda na hindi binago ang token; wala itong itinatago.

Ano ang hindi ko dapat ilagay sa token?

Anumang hindi mo ipi-print sa postcard. Mga password, national ID number, detalye ng card, panloob na flag na ayaw mong makita ng customer. Maglagay ng reference sa token — isang user id — at itago ang halaga sa server kung saan ito nararapat. Pinapangalanan ng pahinang ito ang anumang claim na mukhang lihim ang key, pero ang pangalan lang ang nakikita nito, hindi ang ibig mong sabihin.

Bakit walang "none" na algorithm?

Dahil kayang pekein ninuman ang JWT na walang seguridad, at ang server na tumatanggap nito ay walang anumang authentication. Ito ang pinakamadalas pagsamantalahang bahagi ng espesipikasyon. Hindi gagawa nito ang generator na ito, at tinatanggihan nito ang header na nagtatangkang magtakda ng algorithm sa halip na tahimik itong palitan — dapat mong malaman na hindi mo kaya, hindi maniwalang nagawa mo.

Aling algorithm ang dapat kong piliin?

HS256 maliban kung may kailangang iba sa panig mo. Ang tatlo ay HMAC sa ibinahaging lihim at maayos silang tatlo; gumagamit ang HS384 at HS512 ng mas malapad na hash at gumagawa ng mas mahabang lagda, na nagpapalaki sa token nang hindi ginagawang makabuluhang mas mahirap hulaan ang maayos na piniling lihim. Ang mahinang bahagi ng JWT na nilagdaan ng HMAC ay halos laging ang lihim, hindi ang hash — kaya mas malaki ang naibibigay ng mas mahabang lihim kaysa sa mas mahabang pangalan ng algorithm.

Bakit walang RS256 na maaaring piliin?

Kailangan ng RS256 at ES256 ang paghawak ng RSA o elliptic-curve na key, at mas malaking sakop iyon kaysa sa dapat dalhin ng token generator, at mas masahol ang kalahating pamamaraan ng lagda kaysa wala. Ang tatlong inaalok dito ay ang buong pamilya ng HMAC, ginawa mula sa espesipikasyon nang walang dependency — sinusuri ang mga hash laban sa inilathalang FIPS 180-4 at RFC 4231 na test vectors.

Mag-e-expire ang token ko sa taong 57000. Ano ang nagawa ko?

Milliseconds ang ginamit mo. Ang mga timestamp ng JWT — exp, iat at nbf — ay segundo mula sa epoch, at nagbibigay ng milliseconds ang Date.now(), kaya ang halagang ipinasa nang tuwiran ay isang libong beses na masyadong malaki. Walang library na tumatanggi rito at walang mukhang mali, kaya minamarkahan ng pahinang ito ang timestamp na masyadong malaki para maging kapani-paniwalang bilang ng segundo. Hatiin sa 1000.

Gaano dapat kalakas ang signing secret?

Hindi bababa sa 32 random na bytes. Ang umaatakeng nakakuha ng isang token ay puwedeng sumubok ng hula laban dito nang offline, kasingbilis ng kaya ng hardware nila at hindi man lang hinahawakan ang server mo — kaya hindi sapat ang madaling tandaang passphrase. Gumawa ng isa sa secret key page sa halip na mag-imbento.

Puwede ko bang i-verify dito ang token ng iba?

Hindi, nilalagdaan lang nito. Sulit ding sabihin na ang pag-verify ng token ay pagsusuri ng lagda gamit ang lihim at saka pagsusuri ng mga claim — ang expiry, ang issuer, ang audience. Ang pag-decode ng token at pagbasa ng claims nito nang hindi sinusuri ang lagda ay hindi authentication, gaano man kakumbinsi ang itsura ng payload.

[ ANG KOMPUTASYON ]
Ang tatlong bahagi
Headerang algorithm at uri — base64url, nababasa
Payloadang mga claim mo — base64url, nababasa ninuman
PirmaHMAC sa unang dalawa, gamit ang lihim mo

Dalawa sa tatlo ay payak na tekstong nagbabalatkayo. Ang pangatlo lamang ang nangangailangan ng lihim.

[ ANG TALAGANG PINAPATUNAYAN NG PIRMA ]
Kaya bang basahin ng estranghero ang mga claim?Oo
Kaya bang baguhin ng estranghero?Hindi
Pribado ba ang payload?Hindi

Integridad, hindi pagiging lihim. Kung kailangan mo ang pangalawa, i-encrypt ang halaga bago ito ipasok — o mas mabuti pa, itago ito sa server at maglagay ng sanggunian sa token.

[ SUSUNOD ]
47Gumawa ng Secret KeyGumawa ng lihim na panlagdang sulit gamitin
44Base64 Encoder / DecoderAng encoding na binubuo ng JWT
43JSON FormatterAyusin ang payload bago ito lagdaan
42Gumawa ng PasswordPara sa tao at hindi para sa makina
[ MAHALAGA ]

Nilagdaan sa browser mo; hindi kailanman ipinapadala o iniimbak ang lihim. Ang JWT ay nilalagdaan, hindi ini-encrypt — ituring na pampubliko ang lahat ng nasa payload. Tool ito sa pagbuo, hindi pagsusuri sa seguridad. Walang ipinapadala sa mga server namin ang tina-type mo rito — sa browser mo tumatakbo nang buo ang pagkuwenta.