วิธีใช้งาน
- เลือก HS256, HS384 หรือ HS512
- แก้ไข claims ของ payload แล้วคลิก “Set iat and exp” เพื่อเพิ่มเวลาปัจจุบันและเวลาหมดอายุ
- ป้อน secret สำหรับทดสอบ หรือสุ่ม secret ขนาด 256 บิต
- คัดลอกโทเคนที่ลงนามแล้ว หากต้องการตรวจสอบโทเคน ให้สลับไปที่ “Verify signature” วางโทเคนแล้วป้อน secret
วิธีการทำงาน
JSON Web Token (RFC 7519) มี 3 ส่วนที่เข้ารหัส Base64URL ได้แก่ header, payload ของ claims และ signature ด้วยอัลกอริทึม HMAC HS256, HS384 และ HS512 ลายเซ็นคือ HMAC ที่ใช้ SHA-256, SHA-384 หรือ SHA-512 บน “header.payload” โดยมี secret ที่ใช้ร่วมกันเป็นคีย์ ใครก็ตามที่มี secret จะสร้างและตรวจสอบ token ได้
เครื่องมือนี้จะ serialize header และ payload เป็น JSON แบบ compact เข้ารหัส และเซ็นชื่อด้วย crypto.subtle ซึ่งเป็น Web Crypto API ที่ฝังอยู่ในเบราว์เซอร์ของคุณ ฟิลด์ alg ใน header จะตรงกับอัลกอริทึมที่เลือกเสมอ typ มีค่าเริ่มต้นเป็น JWT และฟิลด์ header อื่น ๆ เช่น kid จะถูกเก็บไว้ “ตั้งค่า iat และ exp” เขียนเวลาปัจจุบันเป็น iat (เวลาที่ออก) และเพิ่มอายุที่เลือกเป็น exp โดยทั้งคู่เป็นวินาทีนับจาก 1 มกราคม 1970 UTC ผลลัพธ์ตรงกับไลบรารี JWT อื่น ๆ เช่น token ตัวอย่างคลาสสิกจาก jwt.io จะได้ตรงกันทุกประการ
secret เป็นข้อความธรรมดา (ไบต์ UTF-8 คือคีย์) หรือไบต์ที่เข้ารหัส Base64/Base64URL ซึ่งหลายเฟรมเวิร์กใช้ ปุ่มสร้าง secret แบบสุ่มจะสร้างไบต์สุ่ม 32 ไบต์ด้วย crypto.getRandomValues สำหรับ HS256 ควรใช้ไบต์สุ่มอย่างน้อย 32 ไบต์ secret สั้นที่คนตั้งเองอาจถูกเดาแบบออฟไลน์จาก token ใดก็ได้
การตรวจสอบจะถอดรหัส token ตรวจสอบว่าใช้ HMAC algorithm และคำนวณลายเซ็นใหม่ด้วย crypto.subtle.verify นอกจากนี้ยังแสดงเมื่อ exp หรือ nbf บ่งชี้ว่า token หมดอายุแล้วหรือยังไม่เริ่มมีผล ระบบไม่รองรับ RS256, ES256 และอัลกอริทึม public-key อื่น ๆ และการตรวจสอบที่นี่ไม่ตรวจสอบ issuer, audience หรือ claims อื่น ๆ ที่แอปพลิเคชันของคุณอาจต้องใช้
ตัวอย่าง
ทดสอบ API บนเครื่อง
เซิร์ฟเวอร์ development ของคุณต้องการ HS256 token ที่เซ็นด้วย “dev-secret-change-me” ตั้งค่า sub เป็น user ID สำหรับทดสอบ คลิก “ตั้งค่า iat และ exp” โดยตั้ง 1 ชั่วโมง ป้อน secret แล้วส่ง token ใน header Authorization: Bearer
ตรวจสอบว่า secret ใดใช้เซ็น token
token บน staging ถูกปฏิเสธ วาง token ลงใน “ตรวจสอบลายเซ็น” แล้วลองใช้ secret ของ staging: “ลายเซ็นไม่ถูกต้อง” จะบอกว่า token ถูกเซ็นด้วย secret อื่น หรือ secret อยู่ในรูปแบบอื่น (ข้อความ vs Base64)
จำลองตัวอย่าง jwt.io
เมื่อใช้ header {"alg":"HS256","typ":"JWT"} payload {"sub":"1234567890","name":"John Doe","iat":1516239022} และ secret “your-256-bit-secret” โทเคนจะลงท้ายด้วย SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ตรงกับ jwt.io
คำถามที่พบบ่อย
secret ของฉันถูกส่งไปยังเซิร์ฟเวอร์ของคุณหรือไม่
ไม่ การลงนามและการตรวจสอบทำงานด้วย Web Crypto API ภายในเบราว์เซอร์ของคุณ และ secret จะไม่ถูกจัดเก็บหรือส่งไปที่ใด เรายังแนะนำให้ใช้ secret สำหรับทดสอบเท่านั้น เพราะ secret สำหรับลงนามจริงไม่ควรพิมพ์ลงในเว็บไซต์ใด ๆ
ทำไมลายเซ็นไม่ถูกต้องทั้งที่ secret ถูกต้อง
ตรวจสอบรูปแบบของ secret บางระบบใช้ข้อความของ secret โดยตรง แต่บางระบบถอดรหัส Base64 ก่อน ซึ่งให้ไบต์คีย์ต่างกัน และตรวจสอบด้วยว่าโทเคนไม่ถูกแก้ไขและใช้อัลกอริทึมเดียวกัน
ฉันสร้างโทเคน RS256 หรือ ES256 ได้ไหม
ไม่สามารถทำได้ด้วยเครื่องมือนี้ รองรับเฉพาะอัลกอริทึม HMAC แบบใช้ secret ร่วมกัน ได้แก่ HS256, HS384 และ HS512
payload ถูกเข้ารหัสหรือไม่
ไม่ JWT ที่ลงนามแล้วเป็นเพียงข้อมูลที่ถูก encode เท่านั้น ใคร ๆ ก็ decode และอ่าน payload ได้ ลายเซ็นยืนยันเพียงว่าโทเคนไม่ถูกแก้ไข อย่าใส่รหัสผ่านหรือข้อมูลลับอื่นใน payload
ความเป็นส่วนตัว
โทเคนถูกสร้างและตรวจสอบในเบราว์เซอร์ของคุณเท่านั้นด้วย Web Crypto API header, payload, token และ secret จะไม่ถูกอัปโหลด จัดเก็บ หรือรวมอยู่ใน analytics