JSON Web Token คืออะไร?
JSON Web Token (JWT) เป็นเปลือกขนาดกะทัดรัดที่ปลอดภัยสำหรับ URL ใช้ห่อหุ้มเพย์โหลดของเคลมขนาดเล็ก เป็นรูปแบบข้อมูลรับรองมาตรฐานสำหรับเซสชันเว็บแบบ stateless, โทเค็น ID ของ OAuth/OIDC, การยืนยันตัวตน API ระหว่างเครื่อง และลิงก์มหัศจรรย์ที่ลงนาม JWT จะประกอบด้วยสามส่วน base64url เสมอเชื่อมด้วยจุด: header.payload.signature ส่วน header และ payload เป็น JSON ส่วนลายเซ็นเป็น MAC แบบไบนารีหรือลายเซ็นดิจิทัลเหนือสองส่วนแรก
JWT ทำงานอย่างไร?
เมื่อเครื่องมือนี้ถอดรหัสโทเค็น มันจะเดินตามเส้นทางสามขั้นตอนเดียวกันกับที่ไลบรารี JWT ทุกตัวทำตาม:
- แยกโทเค็นที่จุดออกเป็นสามส่วนที่ไม่ว่างเปล่าพอดี รูปร่างอื่นใดถือว่าผิดรูปแบบ
- ถอดรหัส base64url สำหรับส่วน 0 และ 1 จากนั้น
JSON.parseแต่ละส่วน ส่วน header มีอัลกอริทึม (alg) และประเภทโทเค็น (typ) ส่วน payload มีเคลม (sub,exp,iat, คีย์ที่กำหนดเอง) - หากมีการให้ความลับ ให้คำนวณ MAC ใหม่เหนือ
<segment0>.<segment1>โดยใช้อัลกอริทึมในส่วน header เปรียบเทียบไบต์กับส่วนที่สาม - แสดงผลการตรวจสอบควบคู่กับเคลมที่ถอดรหัสแล้ว รวมถึงตัวบ่งชี้วันหมดอายุที่มนุษย์อ่านได้ซึ่งคำนวณจากเคลม
exp
ทำไมจึงถอดรหัส JWT ในเบราว์เซอร์?
การวาง JWT ที่ใช้งานจริงลงในเครื่องมือดีบักระยะไกลจะรั่วไหลข้อมูลประจำตัวไปยังบันทึก สแต็คการสังเกตการณ์ และพันธมิตรใด ๆ ที่บริการนั้นส่งข้อมูลให้ แม้ว่าเว็บไซต์ของบุคคลที่สามจะอ้างว่าไม่บันทึกโทเค็น คุณก็ไม่มีทางตรวจสอบได้ เครื่องมือนี้ถูกสร้างขึ้นเพื่อให้คุณไม่ต้องประนีประนอมแบบนั้น:
- ไม่มีเครือข่ายเลย: รันไทม์ไม่มีการเรียก
fetch,XMLHttpRequestหรือsendBeaconเปิด DevTools ขณะที่คุณถอดรหัสและตรวจสอบ — แผง Network จะยังคงเงียบ - Web Crypto แบบเนทีฟ: การตรวจสอบ HMAC ใช้
crypto.subtle.importKeyและcrypto.subtle.signซึ่งเป็นพรีมิทีฟเดียวกับที่รันไทม์ของคุณจะเรียกใช้ - การปรับใช้แบบสแตติก: ทุกหน้าเป็นไฟล์ HTML สแตติกไฟล์เดียวโดยไม่มีจุดสิ้นสุดของเซิร์ฟเวอร์ที่จะถูกบุกรุก ไม่มีโทเค็นที่จะรั่วไหลเพราะไม่มีเซิร์ฟเวอร์ที่จะรั่วไหลให้
เครื่องมือนี้ตรวจสอบอะไร และไม่ตรวจสอบอะไร?
เวอร์ชัน 1 ของเครื่องมือนี้ตรวจสอบเฉพาะลายเซ็นตระกูล HMAC-SHA เท่านั้น โดยเฉพาะ:
- รองรับ: HS256, HS384, HS512 ให้ความลับร่วมและเครื่องมือจะคำนวณและเปรียบเทียบ MAC ใหม่
- ยังไม่รองรับ: RS256/384/512 (RSA), ES256/384/512 (ECDSA), EdDSA และ PS256/384/512 (RSA-PSS) สิ่งเหล่านี้ต้องการคีย์สาธารณะในรูปแบบ PEM หรือ JWK และถูกเลื่อนไปยังรุ่นถัดไปโดยเจตนา
- ปฏิเสธ:
alg: "none"เครื่องมือถอดรหัสโทเค็นแต่ระบุอย่างชัดเจนว่าไม่ปลอดภัย — ไม่มีการตรวจสอบลายเซ็นเกิดขึ้น และระบบโปรดักชันใด ๆ ที่ยอมรับโทเค็นดังกล่าวมีช่องโหว่ร้ายแรง
ตัวอย่างการถอดรหัส JWT มีลักษณะอย่างไร?
วางโทเค็นตัวอย่างมาตรฐานของ RFC 7519 ลงในช่องป้อนข้อมูลด้านบน:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
ส่วน header ถอดรหัสเป็น {"alg":"HS256","typ":"JWT"} และ payload เป็น {"sub":"1234567890","name":"John Doe","iat":1516239022} ป้อน your-256-bit-secret ในแผงตรวจสอบและการตรวจสอบลายเซ็นจะคืนค่าว่าถูกต้อง เปลี่ยนอักขระเดียวของความลับและจะคืนค่าว่าไม่ถูกต้อง ไม่มีอะไรในนี้ออกจากเบราว์เซอร์ของคุณ
นี่คือตัวถอดรหัส JWT ที่เราอยากให้มีอยู่ตอนที่เราต้องการดีบักโทเค็นในโปรดักชัน: เคารพความเป็นส่วนตัว รวดเร็ว และสร้างขึ้นบนพรีมิทีฟเดียวกับที่รันไทม์ใช้