ตัวถอดรหัส JWT

JWT Decoder ทำอะไรได้จริงๆ

JSON Web Token (JWT) ดูเหมือนสตริงอักขระสุ่มที่ยาวและทึบ แต่มันไม่ได้ถูกเข้ารหัสและไม่ใช่ cipher ลับ มันคือ container ที่กะทัดรัดและปลอดภัยสำหรับ URL ที่บรรจุข้อมูลที่มีโครงสร้างระหว่างสองฝ่าย วาง token ลงใน decoder ด้านบนแล้วมันจะแยกสตริงนั้นออกและแสดง JSON จริงๆ ข้างในให้คุณเห็น ทั้ง metadata, claims, ว่าโทเค็นนี้ออกให้ใคร และหมดอายุเมื่อใด ทุกอย่างเกิดขึ้นในเบราว์เซอร์ของคุณเลย โทเค็นไม่ถูกอัปโหลด บันทึก หรือส่งไปไหนเลย ซึ่งสำคัญมากเมื่อสิ่งที่คุณกำลังตรวจสอบคือ credential ของ session ที่ใช้งานจริง

JSON Web Token แยกออกเป็นสามส่วน Base64url ที่เรืองแสง ได้แก่ header, payload และ signature — สตริงที่มีจุดเดียว สามส่วนที่แตกต่างกัน: header, payload และ signature

สามส่วน สองจุด

JWT ที่ถูกต้องทุกอันประกอบด้วยสตริงที่ encode ด้วย Base64url สามอัน เชื่อมต่อกันด้วยจุด: header.payload.signature อักขระจุดเดียวนั้นแหละที่ทำให้ parser รู้ว่าส่วนหนึ่งจบตรงไหนและส่วนต่อไปเริ่มตรงไหน นั่นคือสาเหตุที่โทเค็นที่มีจำนวนจุดผิดถูกปฏิเสธก่อนที่จะอ่านอะไรเลย

Header คือ JSON object เล็กๆ ที่อธิบายโทเค็นเอง มันแทบทุกครั้งจะมี typ (ประเภท ปกติคือ JWT) และ alg — อัลกอริทึมการลงนาม เช่น HS256 (HMAC กับ SHA-256) หรือ RS256 (RSA กับ SHA-256) Header บอก verifier ว่า signature ถูกสร้างอย่างไร

Payload คือส่วนที่คนส่วนใหญ่สนใจ มันเป็น JSON object อีกอันที่บรรจุ claims ซึ่งเป็นคำแถลงเกี่ยวกับผู้ใช้และโทเค็น spec แบ่ง claims ออกเป็น registered (ชื่อมาตรฐานที่จองไว้), public และ private (ชื่อกำหนดเองที่คุณสร้างสำหรับ app ของคุณ) การถอดรหัส payload คือสิ่งที่เปิดเผยว่าใครล็อกอินอยู่ พวกเขามีบทบาทอะไร และ session ของพวกเขาหมดอายุเมื่อใด

Signature คือตราประทับการเข้ารหัสลับ มันถูกคำนวณจาก header และ payload ที่ encode แล้ว โดยใช้อัลกอริทึมจาก header บวกกับ secret หรือ private key เนื่องจากมันครอบคลุมทั้งสองส่วนอื่น การเปลี่ยนแปลงใดๆ ใน header หรือ payload แม้แต่ตัวอักษรเดียว ก็จะทำให้มันใช้งานไม่ได้

Claims ที่คุณจะพบบ่อยที่สุด

Registered claims เป็นชื่อสั้นสามตัวอักษรที่กำหนดโดย RFC 7519 เพื่อให้ระบบต่างๆ ทำงานร่วมกันได้ มีไม่กี่อันที่ปรากฏเกือบทุกที่:

iss — issuer: ใครสร้างโทเค็น (auth server หรือ identity provider ของคุณ)
sub — subject: principal ที่โทเค็นนี้เกี่ยวกับ โดยทั่วไปคือ user ID ที่คงที่
aud — audience: ผู้รับที่โทเค็นนี้ตั้งใจส่งให้ API ควรปฏิเสธโทเค็นที่ audience ไม่ใช่ตัวเอง
exp — expiration time: Unix timestamp หลังจากนั้นไม่ควรรับโทเค็น
iat — issued at: Unix timestamp ตอนที่สร้างโทเค็น

คุณอาจพบ nbf (not before) และ jti (token ID ที่ไม่ซ้ำกัน) ด้วย Timestamps เป็นวินาทีนับจากปี 1970 ใน UTC นั่นคือเหตุที่ decoder ที่แสดงมันเป็นวันที่ที่มนุษย์อ่านได้ช่วยประหยัดการคำนวณในหัวว่าโทเค็นหมดอายุแล้วหรือยัง

การถอดรหัสไม่ใช่การยืนยัน — นี่คือส่วนที่ทำให้คนติดกับ

ความแตกต่างนี้คือสิ่งสำคัญที่สุดที่ต้องเข้าใจเกี่ยวกับ JWT การถอดรหัสหมายถึงการอ่านเนื้อหา ไม่ต้องการคีย์ใดๆ และทุกคนที่ถือโทเค็นสามารถทำได้ เพราะ Base64url คือการ encoding ไม่ใช่การเข้ารหัส การยืนยันหมายถึงการพิสูจน์ว่าโทเค็นนั้นแท้และไม่ถูกแก้ไข โดยคำนวณ signature ใหม่ด้วย secret หรือ public key ที่ถูกต้องและยืนยันว่ามันตรงกัน

เครื่องมือนี้ถอดรหัส มันแสดงให้คุณเห็นว่าโทเค็นบอกว่าอะไร ไม่ใช่ว่าโทเค็นน่าเชื่อถือหรือไม่ โทเค็นอาจถูกปลอมแปลง หมดอายุ หรือนำมาใช้ซ้ำ และยังถอดรหัสออกมาเป็น JSON ที่ดูดีได้ อย่าตัดสินใจด้านการอนุญาตโดยอาศัยเพียง decoded claims เท่านั้น ในสภาพแวดล้อม production คุณยืนยัน signature ฝั่งเซิร์ฟเวอร์ ตรวจสอบ exp และยืนยันว่า iss และ aud ตรงกับที่คาดหวัง โดยใช้ library ที่ผ่านการตรวจสอบ ไม่ใช่การเปรียบเทียบสตริงแบบทำเอง

โทเค็นที่เรืองแสงกำลังถูกคลี่ออกและตรวจสอบข้างๆ ตราประทับ signature ทองที่พิสูจน์ความแท้จริง — ใครก็อ่านโทเค็นได้ มีเพียงผู้ถือคีย์เท่านั้นที่พิสูจน์ได้ว่ามันแท้จริง

Payload ไม่ใช่ตู้นิรภัย

เนื่องจาก payload ถูก encode ด้วย Base64url เท่านั้น ใครก็ตามที่ดักจับโทเค็นสามารถอ่านได้ ดังนั้นให้ถือว่าทุกอย่างในนั้นเป็นสาธารณะ อย่าใส่รหัสผ่าน หมายเลขบัตรเครดิตเต็ม คีย์ลับ หรือข้อมูลส่วนตัวสำคัญใดๆ ใน JWT claims ถ้าคุณถอดรหัสได้ที่นี่ด้วยคลิกเดียว คนอื่นที่ได้รับสำเนามันก็ทำได้เช่นกัน Signature ปกป้องจากการแก้ไข ไม่ใช่จากการอ่าน หากคุณต้องการซ่อนเนื้อหา payload จริงๆ นั่นเป็นงานของ JWE (โทเค็นที่ถูกเข้ารหัส) ซึ่งเป็น specification คนละอัน

ความเป็นส่วนตัวและเครื่องมือที่เกี่ยวข้อง

การตรวจสอบโทเค็นเป็นการกระทำที่ละเอียดอ่อน ดังนั้น decoder นี้จึงทำงาน client-side ทั้งหมด การ parse เป็น JavaScript ธรรมดาในแท็บของคุณและไม่มีอะไรออกจากเครื่อง การวางโทเค็น session ลงในเครื่องมือที่ทำงานบนเซิร์ฟเวอร์หมายถึงการมอบ credential ที่ใช้งานได้ให้กับบุคคลที่สาม ซึ่งนั่นคือสิ่งที่คุณควรหลีกเลี่ยง สำหรับ encoding ที่อยู่ข้างใต้ ดูเครื่องมือ Base64 ของเรา และสำรวจเครื่องมือสำหรับนักพัฒนาส่วนที่เหลือสำหรับ utility บนอุปกรณ์อื่นๆ

คำถามที่พบบ่อย

JWT ถูกเข้ารหัสหรือไม่?

ไม่ JWT มาตรฐาน encode ด้วย Base64url ไม่ได้ถูกเข้ารหัส ใครก็ตามที่มีโทเค็นสามารถอ่าน header และ payload ได้ ใช้ JWE หากคุณต้องการซ่อนเนื้อหา

เครื่องมือนี้ยืนยัน signature หรือไม่?

ไม่ มันถอดรหัสและแสดง header และ payload เท่านั้น การยืนยัน signature ต้องใช้ issuer secret หรือ public key และควรทำบนเซิร์ฟเวอร์ของคุณ

ปลอดภัยไหมที่จะวาง token ของฉันที่นี่?

ใช่ การถอดรหัสทำงานทั้งหมดในเบราว์เซอร์ของคุณโดยใช้ JavaScript ในเครื่อง โทเค็นไม่ถูกอัปโหลด เก็บ หรือส่งไปยังเซิร์ฟเวอร์ใดๆ

iss, sub, aud, exp และ iat หมายความว่าอะไร?

พวกมันคือ registered claims: issuer, subject, audience, expiration time และ issued-at time สามตัวที่เกี่ยวกับเวลาใช้ Unix timestamps เป็นวินาที

ฉันสามารถเชื่อถือ claims ที่แสดงหลังจากถอดรหัสได้ไหม?

ไม่ใช่ตามลำพัง Decoded claims อาจมาจากโทเค็นที่ถูกปลอมแปลงหรือหมดอายุ ยืนยัน signature และตรวจสอบ expiration ฝั่งเซิร์ฟเวอร์เสมอก่อนเชื่อถือ

ทำไมโทเค็นของฉันถึงมีสามส่วนคั่นด้วยจุด?

พวกมันคือ header, payload และ signature แต่ละอัน encode ด้วย Base64url และเชื่อมด้วยจุด จุดบอก parser ว่าแต่ละส่วนเริ่มและจบตรงไหน