JWT (JSON Web Token) เป็นมาตรฐานเปิดที่กำหนดโดย IETF ใน RFC 7519 (RFC 7515 อธิบายรูปแบบการเซ็น JWS, RFC 7516 อธิบายการเข้ารหัส JWE, RFC 7517 กำหนดคีย์ JWK) สำหรับการถ่ายโอน 'ข้อมูลที่อ้างถึง' ของผู้ใช้อย่างปลอดภัยระหว่างคำขอ HTTP, กระบวนการ OIDC และการเรียกไมโครเซอร์วิส สตริง JWT มาตรฐานประกอบด้วยสามส่วนที่เข้ารหัส Base64URL: Header (อัลกอริทึมและประเภท), Payload (Claims, ข้อมูลผู้ใช้) และ Signature (ลายเซ็นจากคีย์บนสองส่วนแรก) สามส่วนเชื่อมด้วยจุด `.` เช่น `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`
**JWT ไม่ใช่การเข้ารหัส** นี่เป็นความเข้าใจผิดที่พบบ่อยที่สุด Payload เป็นข้อความธรรมดาโดยค่าเริ่มต้น — ใครๆ ก็สามารถถอดรหัส Base64URL และอ่านเนื้อหาได้ JWT ให้ **การตรวจจับการแก้ไข** ไม่ใช่ความลับ: เซิร์ฟเวอร์เซ็น Header.Payload ใหม่ด้วยคีย์ร่วมและเปรียบเทียบกับ Signature ของ Token หากตรงกัน แสดงว่า Token ไม่ถูกแก้ไขระหว่างทาง เปรียบเสมือน 'ตั๋วรถไฟพร้อมตราป้องกันการปลอม': ผู้ตรวจสอบสนใจว่าตั๋วเป็นของแท้หรือไม่ ไม่ใช่ QR Code อ่านไม่ออก
JWT แบ่งหน้าที่อย่างชัดเจนระหว่าง 13 อัลกอริทึม **ตระกูล HMAC** (HS256/HS384/HS512) ใช้คีย์สมมาตรสำหรับทั้งเซ็นและตรวจสอบ รวดเร็วและง่าย เหมาะสำหรับเซอร์วิสเดียวหรือคลัสเตอร์ที่เชื่อถือได้; Secret ต้องยาวอย่างน้อยเท่าความยาว digest (เช่น ≥ 32 ไบต์สำหรับ HS256) **ตระกูล RSA** (RS256/RS384/RS512) ใช้ RSASSA-PKCS1-v1_5 ซึ่งเป็นรูปแบบอสมมาตรที่พบบ่อยที่สุด — ผู้เซ็นถือคีย์ส่วนตัว ผู้ตรวจสอบถือคีย์สาธารณะ **ตระกูล RSA-PSS** (PS256/PS384/PS512) ใช้ padding RSA-PSS ที่ใหม่กว่าพร้อมการรับประกันความปลอดภัยที่เข้มแข็งกว่า AWS SigV4 และผู้ให้บริการ OIDC สมัยใหม่เลือกใช้ **ตระกูล ECDSA** (ES256/ES384/ES512) ใช้เส้นโค้งวงรี (P-256/P-384/P-521 ตามลำดับ) พร้อมลายเซ็นที่สั้นกว่าและประสิทธิภาพดีกว่า **EdDSA** (หลักๆ คือ Ed25519) รวดเร็วมากและเป็น deterministic (ข้อความเดิม + คีย์เดิม = ลายเซ็นเดิมทุกครั้ง) และเป็นอัลกอริทึมที่แนะนำใน OAuth 2.1 และโปรโตคอลใหม่
ความปลอดภัยคือจุดที่ JWT มักมีปัญหาในสภาพแวดล้อมการผลิต OWASP JWT Cheat Sheet ระบุกฎสำคัญอย่างน้อยสี่ข้อ: (1) ห้ามใส่รหัสผ่าน, เลขประจำตัวประชาชน, เลขบัตร หรือ API Key เป็นข้อความธรรมดาใน Payload เด็ดขาด; (2) เซิร์ฟเวอร์ต้อง **ไม่เชื่อถือฟิลด์ alg** ที่ประกาศใน Header ของ Token — ต้องตรวจสอบด้วยอัลกอริทึมที่กำหนดไว้ ไม่งั้นผู้โจมตีที่แก้ header เป็น `alg: none` จะผ่านได้ทั้งหมด (นี่คือรากของ CVE ในอดีตเช่น CVE-2015-9235); (3) HMAC Secret ต้องเป็นแบบสุ่มและยาวอย่างน้อย 32 ไบต์ ห้ามเป็นสตริงสั้น; (4) การตรวจสอบไม่ใช่แค่ลายเซ็น — ต้องตรวจสอบ `exp` (วันหมดอายุ), `nbf` (ยังไม่ก่อน), `iss` (ผู้ออก) และ `aud` (ผู้รับ) ด้วย เครื่องมือนี้เน้น Claims เหล่านี้ทั้งหมดใน UI เพื่อให้คุณเห็นได้ในทันทีว่าปัญหาคือลายเซ็น, เวลา หรือ Claims
JWT ไม่ใช่ตัวแทนของ session Session เก็บสถานะผู้ใช้บนเซิร์ฟเวอร์ (Redis หรือฐานข้อมูล); JWT บรรจุสถานะใน Token สถาปัตยกรรมไมโครเซอร์วิส, API แบบ stateless, ไคลเอนต์มือถือ และการตั้งค่าที่ใช้ CORS มากได้รับประโยชน์จาก JWT; ระบบองค์กรแบบดั้งเดิมและกระบวนการที่ต้องยกเลิกทันที (เช่น 'เตะผู้ใช้ออกตอนนี้') ยังเหมาะกับ session มากกว่า เครื่องมือนี้ครอบคลุมทั้งการดีบัก JWT ล้วนๆ และขั้นตอนการแยกวิเคราะห์ Token / ตรวจสอบลายเซ็น / แก้ไข Payload ในการย้ายจาก session เป็น JWT