ถอดรหัส JWT (JWT Decoder)
วาง JSON Web Token แล้วอ่าน header และ payload ในรูปแบบ JSON ที่จัดรูปแบบแล้ว โดยแสดงเวลาหมดอายุและเวลาออกโทเค็นเป็นวันที่ พร้อมระบุว่าโทเค็นยังใช้งานได้อยู่หรือไม่ การถอดรหัสทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณ ซึ่งสำคัญมากเมื่อโทเค็นนั้นเป็นข้อมูลยืนยันตัวตนที่ยังใช้งานอยู่
0 ตัวอักษร · 0 คำ · 0 บรรทัด
0 ตัวอักษร · 0 คำ · 0 บรรทัด
ทำงานทั้งหมดภายในแท็บเบราว์เซอร์นี้ ข้อความของคุณจะไม่ถูกอัปโหลดหรือจัดเก็บไว้
Registered claims
ชื่อ claim ทั้งเจ็ดที่กำหนดไว้ใน RFC 7519 §4.1 ทุกตัวเป็นตัวเลือก ส่วนเวลาเป็นจำนวนวินาทีนับตั้งแต่ 1970-01-01 UTC
| Claim | ความหมาย |
|---|---|
iss | ผู้ออก: ผู้ที่สร้างและลงนามโทเคน |
sub | หัวเรื่อง: ผู้ใช้หรือเอนทิตีที่โทเคนอ้างถึง |
aud | ผู้รับ: ผู้ที่โทเคนตั้งใจส่งให้ |
exp | เวลาหมดอายุ: ปฏิเสธโทเคนหลังเวลานี้ |
nbf | ใช้ได้ไม่ก่อน: ปฏิเสธโทเคนก่อนเวลานี้ |
iat | ออกเมื่อ: เวลาที่สร้างโทเคน |
jti | JWT ID: ตัวระบุที่ไม่ซ้ำกัน ใช้ป้องกันการนำโทเคนกลับมาใช้ซ้ำ (replay) |
ค่า alg ที่ใช้บ่อย
| ค่า alg | ความหมาย |
|---|---|
HS256 | HMAC ร่วมกับ SHA-256 ใช้ความลับร่วมชุดเดียวทั้งลงนามและตรวจสอบ |
RS256 | ลายเซ็น RSA PKCS#1 v1.5 ร่วมกับ SHA-256 ใช้กุญแจส่วนตัวลงนาม และกุญแจสาธารณะตรวจสอบ |
PS256 | RSA-PSS ร่วมกับ SHA-256 |
ES256 | ECDSA บนเส้นโค้ง P-256 ร่วมกับ SHA-256 ลายเซ็นสั้น |
EdDSA | ลายเซ็น Ed25519 หรือ Ed448 |
none | โทเคนที่ไม่ได้ลงนาม เซิร์ฟเวอร์ควรปฏิเสธ |
ภายใน JSON Web Token มีอะไรบ้าง
JWT กำหนดไว้ใน RFC 7519 (พฤษภาคม 2015) ซึ่งแนะนำให้ออกเสียงเหมือนคำภาษาอังกฤษว่า "jot" รูปแบบที่ลงลายเซ็นซึ่งพบได้ทั่วไปคือสตริง Base64url สามส่วนที่เชื่อมกันด้วยจุด ได้แก่ header.payload.signature โดย header ระบุอัลกอริทึมที่ใช้ลงลายเซ็นไว้ใน alg เช่น HS256 หรือ RS256 และมักมี ID ของคีย์ใน kid ส่วน payload เก็บ claim ซึ่งเป็นฟิลด์ JSON เช่น sub (ผู้ใช้) iss (ผู้ออกโทเค็น) aud (กลุ่มเป้าหมายที่ตั้งใจไว้) รวมถึง exp, nbf และ iat ซึ่งเป็นเวลาเป็นวินาทีนับจาก 1 มกราคม 1970 UTC ตัวถอดรหัสจะแปลงเวลาทั้งสามนี้เป็นเวลาท้องถิ่นของคุณและรูปแบบ ISO 8601 พร้อมบอกว่าโทเค็นหมดอายุแล้ว ยังไม่ถึงเวลาที่ใช้งานได้ หรืออยู่ในช่วงที่ใช้งานได้
Base64url เป็นการเข้ารหัสแบบหนึ่ง ไม่ใช่การเข้ารหัสลับ ใครที่มีโทเค็นก็อ่าน payload ได้เหมือนที่หน้านี้แสดง จึงไม่ควรใส่รหัสผ่าน เลขบัตร หรือข้อมูลลับอื่น ๆ ไว้ใน claim โทเค็นที่มีห้าส่วนคั่นด้วยจุดคือ JWE หรือโทเค็นที่เข้ารหัสลับ ต้องมีคีย์จึงจะอ่านเนื้อหาได้ และตัวถอดรหัสจะแจ้งให้ทราบ หากคัดลอก "Bearer " นำหน้ามาจากเฮดเดอร์ Authorization ระบบจะลบออกให้อัตโนมัติ
ทำไมเครื่องมือนี้จึงไม่ตรวจสอบลายเซ็น
ลายเซ็นพิสูจน์ว่า header และ payload ถูกสร้างโดยผู้ที่ถือคีย์ และไม่ถูกแก้ไขตั้งแต่นั้น การตรวจสอบต้องใช้คีย์ดังกล่าว คือ secret ที่ใช้ร่วมกันสำหรับอัลกอริทึม HMAC เช่น HS256 หรือคีย์สาธารณะของผู้ออกโทเค็นสำหรับ RS256, ES256 หรือ EdDSA การวาง secret สำหรับลงลายเซ็นของระบบจริงลงในหน้าเว็บใด ๆ ไม่ใช่ความคิดที่ดี และตัวถอดรหัสที่อ้างว่ารับรองโทเค็นโดยไม่มีคีย์จะทำให้เข้าใจผิดว่าปลอดภัย เครื่องมือนี้จึงแสดงลายเซ็นแต่ไม่ตรวจสอบ ให้มองสิ่งที่เห็นเป็นเพียงสิ่งที่โทเค็นอ้าง ไม่ใช่ข้อเท็จจริง
การตรวจสอบควรทำบนเซิร์ฟเวอร์ของคุณ โดยใช้ไลบรารีที่ยังมีการดูแลและกำหนดอัลกอริทึมที่คาดหวังไว้ตายตัว ข้อผิดพลาดในอดีตสองอย่างอธิบายเหตุผลได้ คือการยอมรับ alg "none" ซึ่งทำให้ใครก็ปลอมโทเค็นที่ไม่มีลายเซ็นได้ และ algorithm confusion ซึ่งเซิร์ฟเวอร์ที่คาดหวัง RS256 ถูกหลอกให้ตรวจลายเซ็น HS256 โดยใช้คีย์สาธารณะเป็น secret ของ HMAC ตัวถอดรหัสเหมาะสำหรับการดีบัก เช่น ดูว่าผู้ให้บริการออก claim อะไรบ้าง สังเกตว่า audience ผิด หรือพบว่าเซสชันล้มเหลวเพราะ exp หมดไปเมื่อหนึ่งนาทีก่อน หากต้องการอ่านส่วน Base64url แบบดิบ ให้ใช้ตัวถอดรหัส Base64
คำถามที่พบบ่อย
- วาง access token จริงลงในเครื่องมือถอดรหัส JWT ปลอดภัยหรือไม่
- บนหน้านี้โทเค็นจะไม่ออกจากเบราว์เซอร์ของคุณ อย่างไรก็ตาม โทเค็นที่ยังใช้ได้ทำหน้าที่เหมือนรหัสผ่านจนกว่าจะหมดอายุ จึงควรใช้โทเค็นที่หมดอายุแล้วหรือโทเค็นทดสอบ และไม่ควรให้โทเค็นที่ใช้งานจริงปรากฏในภาพหน้าจอหรือแชต
- ทำไมโทเค็นจึงแสดงว่าหมดอายุแล้ว ทั้งที่เพิ่งออกให้
- ให้ตรวจนาฬิกาของอุปกรณ์ก่อน ผู้ออกโทเค็นบางรายกำหนดอายุของ access token เพียงไม่กี่นาที และโทเค็นที่คัดลอกจากล็อกอาจเก่ากว่าที่คิด ส่วน exp ที่เขียนเป็นมิลลิวินาทีแทนที่จะเป็นวินาทีจะให้ผลตรงข้าม คือไปตกอยู่ในอนาคตอีกหลายพันปี
- ผู้อื่นแก้ไข payload ของ JWT ได้หรือไม่
- แก้ไขและเข้ารหัสใหม่ได้ แต่ลายเซ็นจะไม่ตรงกันอีกต่อไป เซิร์ฟเวอร์ที่ตรวจลายเซ็นด้วยคีย์และอัลกอริทึมที่ถูกต้องจะปฏิเสธโทเค็นที่ถูกแก้ไข
- JWS กับ JWE ต่างกันอย่างไร
- JWS (RFC 7515) มีลายเซ็น มีสามส่วน และใครก็อ่านได้ ส่วน JWE (RFC 7516) เข้ารหัสลับ มีห้าส่วน และเฉพาะผู้ถือคีย์เท่านั้นที่อ่าน payload ได้
- การออกจากระบบทำให้ JWT ใช้งานไม่ได้หรือไม่
- ไม่ได้ด้วยตัวเอง JWT ที่ลงลายเซ็นแล้วจะยังใช้ได้จนถึง exp เว้นแต่เซิร์ฟเวอร์จะมีรายการปฏิเสธหรือตรวจบันทึกเซสชัน นี่คือเหตุผลที่ access token มักมีอายุสั้น