เครื่องสร้าง JWT

ยินดีต้อนรับสู่ เครื่องสร้าง JWT เครื่องมือออนไลน์ที่รวดเร็วและฟรีสำหรับสร้าง JSON Web Token ที่มีการลงนาม ไม่ว่าคุณจะกำลังทดสอบขั้นตอนการพิสูจน์ตัวตน สร้าง API ดีบั๊กการผสานรวม หรือเรียนรู้วิธีการทำงานของ JWT ในเบื้องลึก เครื่องสร้างนี้จะช่วยให้คุณควบคุมส่วนหัวของโทเค็น การเคลมส่วนข้อมูล และอัลกอริทึมการลงนาม HMAC ได้อย่างเต็มที่ สร้างโทเค็น HS256, HS384 หรือ HS512 ที่ถูกต้องได้ในคลิกเดียว และตรวจสอบแต่ละส่วนเคียงข้างกันได้ทันที

JSON Web Token คืออะไร?

JSON Web Token (JWT) คือรูปแบบข้อมูลประจำตัวขนาดกะทัดรัดและปลอดภัยสำหรับ URL ซึ่งกำหนดโดย RFC 7519 โดย JWT จะบรรจุการเคลมเกี่ยวกับหัวข้อ (subject) ระหว่างสองฝ่าย และพิสูจน์ความถูกต้องสมบูรณ์ผ่านลายเซ็นทางคริปโตกราฟี เนื่องจากโทเค็นบรรจุข้อมูลในตัวเอง ผู้รับจึงสามารถตรวจสอบความถูกต้องได้โดยไม่ต้องเรียกกลับไปยังผู้ออกโทเค็น ซึ่งเป็นคุณสมบัติที่ทำให้ JWT เป็นหัวใจหลักของการพิสูจน์ตัวตนแบบไร้สถานะสำหรับเว็บและโมบายแอปพลิเคชันสมัยใหม่

ทุกๆ JWT สร้างขึ้นจากสามส่วนที่เข้ารหัสแบบ base64url เชื่อมต่อกันด้วยจุด:

• ส่วนหัว (Header) — ออบเจกต์ JSON ที่ระบุประเภทโทเค็น (typ) และอัลกอริทึมการลงนาม (alg)
• ส่วนข้อมูล (Payload) — ออบเจกต์ JSON ที่เก็บการเคลม เช่น รหัสผู้ใช้, เวลาหมดอายุ และข้อมูลที่กำหนดเองอื่นๆ
• ลายเซ็น (Signature) — ลายเซ็น HMAC หรือ RSA ที่ครอบคลุมส่วนหัวและส่วนข้อมูลที่เข้ารหัส เพื่อป้องกันการดัดแปลงข้อมูล

วิธีการทำงานของเครื่องสร้าง JWT

เครื่องมือนี้ปฏิบัติตามวิธีการลงนาม JWT ที่แม่นยำตาม RFC 7519 §7.1:

1. แปลง JSON ของส่วนหัวให้อยู่ในรูปแบบกะทัดรัด (ไม่มีช่องว่าง) และเข้ารหัสแบบ base64url
2. ดำเนินการเช่นเดียวกันกับ JSON ของส่วนข้อมูล
3. เชื่อมต่อทั้งสองส่วนเข้าด้วยกันด้วยจุด นี่คือข้อมูลนำเข้าสำหรับการลงนาม
4. คำนวณ HMAC ของข้อมูลนำเข้าโดยใช้ความลับ (secret) ของคุณและอัลกอริทึม SHA-2 ที่เลือก
5. เข้ารหัสไบต์ลายเซ็นที่ได้ด้วย base64url
6. เชื่อมต่อทุกอย่างเข้าด้วยกันเป็น header.payload.signature

สิ่งที่ทำให้เครื่องสร้างนี้แตกต่าง

• การแสดงภาพแยกสามส่วนด้วยสี — ส่วนหัว (สีชมพู), ส่วนข้อมูล (สีม่วง), ลายเซ็น (สีฟ้า) เพื่อให้คุณเห็นแต่ละส่วนได้ทันที
• จานเครื่องมือ Quick Claims — ใส่ฟิลด์ iss, sub, aud, iat, nbf และ jti ได้ในคลิกเดียว
• ตัวช่วยตั้งค่าวันหมดอายุ — ปุ่มที่ตั้งค่าไว้ล่วงหน้าสำหรับ 1 ชั่วโมง, 1 วัน, 7 วัน หรือ 30 วัน ซึ่งจะคำนวณ Unix timestamp ที่ถูกต้องให้โดยอัตโนมัติ
• พรีวิวโทเค็นแบบสด — ส่วนหัวและส่วนข้อมูลที่เข้ารหัสจะอัปเดตตามที่คุณพิมพ์ เพื่อให้คุณเห็นว่าการแก้ไขแต่ละครั้งเปลี่ยนโทเค็นอย่างไร
• การซิงค์ส่วนหัวอัจฉริยะ — การสลับอัลกอริทึมจะอัปเดตฟิลด์ alg ในส่วนหัวโดยอัตโนมัติ
• ตัวเลือก Secret แบบ Base64 — หากความลับของคุณถูกเก็บเป็น base64 (ตามมาตรฐาน JWS สำหรับคีย์ไบนารี) ให้เปิดใช้งานตัวเลือกนี้แล้วเครื่องมือจะถอดรหัสก่อนนำไปลงนาม
• ปุ่มคัดลอกแยกตามส่วน — คัดลอกส่วนหัว, ส่วนข้อมูล, ลายเซ็น หรือโทเค็นเต็มแยกจากกันได้
• สรุปการเคลม — การเคลมมาตรฐานที่ระบบรู้จักจะถูกแสดงรายการพร้อมคำอธิบายและเวลาที่อ่านเข้าใจง่ายสำหรับมนุษย์

การเลือกอัลกอริทึมที่เหมาะสม

ตัวเลือก HMAC ทั้งสามรูปแบบที่เครื่องมือนี้รองรับนั้นทำงานเหมือนกัน ยกเว้นแฮช SHA-2 ที่อยู่เบื้องหลังและความยาวของลายเซ็น:

• HS256 — HMAC ร่วมกับ SHA-256 ลายเซ็นขนาด 256 บิต เป็นค่าเริ่มต้นสำหรับไลบรารีที่ออก JWT เกือบทุกแห่งและเป็นตัวเลือกที่ทำงานร่วมกันได้กว้างขวางที่สุด
• HS384 — HMAC ร่วมกับ SHA-384 ลายเซ็นขนาด 384 บิต มีระดับความปลอดภัยที่สูงกว่าเล็กน้อยต่อการวิเคราะห์รหัสลับในอนาคต
• HS512 — HMAC ร่วมกับ SHA-512 ลายเซ็นขนาด 512 บิต มีประโยชน์เมื่อนโยบายต้องการแฮชมาตรฐานที่ยาวที่สุด

ทั้งสามรูปแบบขึ้นอยู่กับความลับที่แชร์ร่วมกัน (shared secret) ซึ่งทั้งผู้ลงนามและผู้ตรวจสอบต้องถือครองไว้ RFC 7518 §3.2 กำหนดให้คีย์ต้องมีความยาวอย่างน้อยเท่ากับผลลัพธ์ของแฮช: 256 บิตสำหรับ HS256, 384 บิตสำหรับ HS384, 512 บิตสำหรับ HS512

การเคลมมาตรฐานที่ลงทะเบียนไว้ (Standard Registered Claims)

RFC 7519 §4.1 กำหนดชุดการเคลมมาตรฐานขนาดเล็กที่ผู้ออกและผู้ตรวจสอบ JWT ควรจดจำได้ ทั้งหมดเป็นตัวเลือกเสริมแต่ได้รับการรองรับอย่างกว้างขวาง:

• iss (issuer) — ระบุผู้สร้างโทเค็น มักเป็น URL หรือชื่อบริการ
• sub (subject) — ระบุว่าโทเค็นนี้เกี่ยวกับใคร โดยทั่วไปคือรหัสผู้ใช้
• aud (audience) — ระบุผู้รับที่โทเค็นนี้ตั้งใจให้ใช้ อาจเป็นสตริงเดียวหรืออาร์เรย์ก็ได้
• exp (expiration time) — Unix timestamp หลังจากเวลานี้โทเค็นต้องถูกปฏิเสธ
• nbf (not before) — Unix timestamp ก่อนเวลานี้โทเค็นต้องไม่ถูกยอมรับ
• iat (issued at) — Unix timestamp บันทึกเวลาที่โทเค็นถูกสร้างขึ้น
• jti (JWT ID) — ตัวระบุที่ไม่ซ้ำกันซึ่งช่วยให้สามารถยกเลิกหรือติดตามโทเค็นแต่ละรายการได้

วิธีใช้งานเครื่องมือนี้

1. เลือกอัลกอริทึมการลงนาม — คลิก HS256, HS384 หรือ HS512 ส่วนหัวจะถูกอัปเดตโดยอัตโนมัติเพื่อให้ตรงกัน
2. แก้ไขส่วนหัว (ไม่บังคับ) — ส่วนหัวเริ่มต้นประกอบด้วย alg และ typ เพิ่ม kid (key id) ที่กำหนดเองหากผู้ตรวจสอบของคุณต้องการ
3. สร้างส่วนข้อมูล — พิมพ์การเคลมของคุณเป็น JSON หรือคลิกปุ่ม Quick Claims เพื่อใส่ฟิลด์มาตรฐาน ตัวช่วยวันหมดอายุจะเขียน Unix timestamp ที่ถูกต้องสำหรับระยะเวลาสัมพัทธ์ที่คุณเลือก
4. ตั้งค่าความลับ (secret) — ป้อนความลับที่แชร์ของ HMAC คลิกไอคอนรูปตาเพื่อแสดงข้อมูล หากความลับของคุณเข้ารหัสแบบ base64 ให้เปิดใช้งานช่องทำเครื่องหมายเพื่อให้เครื่องมือถอดรหัสก่อนลงนาม
5. สร้าง JWT — คลิก สร้าง JWT โทเค็นตัวเต็ม, การ์ดแสดงผลสามส่วน, แผนภาพโครงสร้าง และสรุปการเคลมที่ระบบรู้จักจะแสดงขึ้นมาพร้อมกัน
6. คัดลอกสิ่งที่คุณต้องการ — ใช้ปุ่มคัดลอกแยกตามส่วน หรือปุ่มคัดลอกโทเค็น เพื่อนำค่าที่เข้ารหัสไปใช้ใน Postman, curl หรือแอปพลิเคชันไคลเอนต์ของคุณ

กรณีการใช้งานทั่วไป

การพิสูจน์ตัวตนและการอนุญาตสิทธิ์

• ออกโทเค็นการเข้าถึง (access tokens) หลังจากล็อกอินสำเร็จ
• เข้ารหัสตัวตนผู้ใช้ (sub) พร้อมกับการเคลมบทบาทหรือสิทธิ์การใช้งาน
• ลงนามโทเค็นที่มีอายุสั้น (15–60 นาที) และรีเฟรชตามความจำเป็น

การทดสอบการรวมระบบ API

• สร้างโทเค็นจำลองเพื่อทดสอบว่า API ของคุณตอบสนองต่อการเคลมที่หมดอายุ, ลงวันที่ในอนาคต หรือรูปแบบที่ไม่ถูกต้องอย่างไร
• สร้าง JWT คงที่สำหรับการทดสอบหน่วย (unit tests) และ CI pipelines
• จำลองโทเค็นที่เหมือนโปรดักชันในสภาพแวดล้อมโลคัลโดยไม่ต้องเรียกใช้เซิร์ฟเวอร์การพิสูจน์ตัวตนจริง

การดีบั๊ก Single Sign-On (SSO)

• เปรียบเทียบ JWT ที่รู้ว่าถูกต้องกับ JWT ที่ผู้ให้บริการส่งมาเพื่อหาความคลาดเคลื่อนจากข้อกำหนด
• ตรวจสอบอัลกอริทึมการลงนามและรหัสคีย์ (kid) ที่ใช้โดยผู้ออกโทเค็นต้นทาง

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

JWT ที่สร้างที่นี่เป็นโทเค็นจริงที่ใช้งานได้ใช่หรือไม่?

ใช่ โทเค็นถูกลงนามด้วย HMAC เหนือส่วนหัวและส่วนข้อมูลที่เข้ารหัสตามรูปแบบมาตรฐาน ไลบรารี JWT ใดๆ ที่ใช้ความลับเดียวกันกับคุณจะสามารถตรวจสอบความถูกต้องได้สำเร็จ

ทำไมโทเค็นของฉันถึงดูเหมือนกับที่ฉันสร้างจากที่อื่นทุกประการ?

เพราะ JWT เป็นแบบกำหนดแน่นอน (deterministic): เมื่อมีส่วนหัว ส่วนข้อมูล และความลับที่เหมือนกัน ทุกไลบรารีที่เป็นไปตามมาตรฐานจะสร้างสตริงที่เหมือนกันทุกประการ หากคุณเห็นความแตกต่าง ให้ตรวจสอบลำดับการจัดรูปแบบ JSON, ตัวสะกดของคีย์ และการเข้ารหัสของความลับว่าตรงกันทั้งหมดหรือไม่

ฉันสามารถถอดรหัส JWT เพื่อยืนยันสิ่งที่ฉันสร้างได้หรือไม่?

ได้ คุณสามารถใช้เครื่องมือนี้ร่วมกับตัวถอดรหัส JWT เพื่อตรวจสอบส่วนต่างๆ การถอดรหัสเป็นเพียงการย้อนขั้นตอน base64url เท่านั้น การตรวจสอบลายเซ็นยังคงต้องใช้ความลับ

ทำไมความลับของฉันถึงถูกปฏิเสธว่าสั้นเกินไป?

RFC 7518 แนะนำให้ใช้คีย์ที่มีความยาวอย่างน้อยเท่ากับความยาวของผลลัพธ์แฮช: 256 บิตสำหรับ HS256 ตัวเครื่องมือเองไม่ได้บังคับขั้นต่ำ แต่ผู้ตรวจสอบที่ทำงานอย่างถูกต้องอาจปฏิเสธคีย์ที่สั้นเกินไป ควรใช้ความลับขนาด 32+ ไบต์ที่สร้างแบบสุ่มในการใช้งานจริง

เครื่องมือนี้รองรับ RS256, ES256 หรือ EdDSA หรือไม่?

ยังไม่รองรับในขณะนี้ — เครื่องมือนี้มุ่งเน้นที่อัลกอริทึมที่ใช้ HMAC เนื่องจากต้องการเพียงสตริงที่แชร์ร่วมกัน อัลกอริทึมแบบอสมมาตร (RS*, PS*, ES*, EdDSA) จำเป็นต้องใช้คู่คีย์และการจัดการ PEM ซึ่งเหมาะกับเครื่องมือเฉพาะทางมากกว่า

ความลับและส่วนข้อมูลของฉันถูกส่งไปยังเซิร์ฟเวอร์หรือไม่?

แบบฟอร์มจะถูกส่งผ่าน HTTPS เพื่อคำนวณลายเซ็น ไม่มีการบันทึกหรือจัดเก็บข้อมูลใดๆ เกินกว่าช่วงเวลาของคำขอ อย่างไรก็ตาม อย่าป้อนความลับที่ใช้จริงในโปรดักชันที่นี่ ให้ถือว่านี่เป็นสภาพแวดล้อมการทดสอบสาธารณะ

แหล่งข้อมูลเพิ่มเติม

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7518 - JSON Web Algorithms (JWA)
• JSON Web Token - Wikipedia