JWT คืออะไร? คู่มือฉบับสมบูรณ์เกี่ยวกับ JSON Web Tokens

JWT คืออะไร?

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

การรับรองความถูกต้องด้วย JWT ทำงานอย่างไร

การรับรองความถูกต้องด้วย JWT ใช้รูปแบบไร้สถานะที่ลดความจำเป็นในการจัดเก็บเซสชันฝั่งเซิร์ฟเวอร์ การเข้าใจโฟลว์นี้เป็นกุญแจสำคัญในการเข้าใจว่าทำไม JWT จึงกลายเป็นตัวเลือกเริ่มต้นสำหรับความปลอดภัยของ API สมัยใหม่

โฟลว์การรับรองความถูกต้อง

1. ผู้ใช้เข้าสู่ระบบ — ไคลเอนต์ส่งข้อมูลประจำตัว (ชื่อผู้ใช้และรหัสผ่าน) ไปยังเซิร์ฟเวอร์รับรองความถูกต้อง
2. เซิร์ฟเวอร์สร้าง JWT — เซิร์ฟเวอร์ตรวจสอบข้อมูลประจำตัว สร้าง JWT ที่มีข้อมูลประจำตัวและสิทธิ์ของผู้ใช้ ลงนามด้วย secret หรือ private key และส่งกลับไปยังไคลเอนต์
3. ไคลเอนต์เก็บโทเค็น — ไคลเอนต์เก็บ JWT โดยทั่วไปใน localStorage, sessionStorage หรือ HTTP-only cookie
4. ไคลเอนต์ส่งโทเค็นไปกับทุกคำขอ — สำหรับทุกคำขอ API ที่ตามมา ไคลเอนต์รวม JWT ใน header Authorization โดยใช้รูปแบบ Bearer: Authorization: Bearer <token>
5. เซิร์ฟเวอร์ตรวจสอบโทเค็น — เซิร์ฟเวอร์ตรวจสอบลายเซ็น JWT ตรวจสอบเวลาหมดอายุ และแยก claims ผู้ใช้เพื่ออนุญาตคำขอ
6. ไม่ต้องค้นหาเซสชัน — เนื่องจาก JWT มีข้อมูลที่จำเป็นทั้งหมด เซิร์ฟเวอร์จึงไม่ต้องสอบถามฐานข้อมูลหรือแคชเพื่อระบุตัวผู้ใช้

ทำไมสิ่งนี้จึงสำคัญ

การรับรองความถูกต้องแบบใช้เซสชันดั้งเดิมเก็บ session ID ในหน่วยความจำหรือฐานข้อมูลของเซิร์ฟเวอร์ ทุกคำขอที่รับรองความถูกต้องต้องมีการค้นหา JWT ขจัดการค้นหานี้ — โทเค็นเองพิสูจน์ตัวตนของผู้ใช้ สิ่งนี้ทำให้ระบบที่ใช้ JWT สามารถขยายขนาดได้โดยธรรมชาติเพราะเซิร์ฟเวอร์ใดๆ ในคลัสเตอร์สามารถตรวจสอบโทเค็นได้โดยไม่ต้องมีสถานะเซสชันร่วมกัน

JWT เทียบกับการรับรองความถูกต้องแบบใช้เซสชัน

| ด้าน | การรับรองความถูกต้องด้วย JWT | การรับรองความถูกต้องแบบใช้เซสชัน | |--------|--------------------|------------------------------| | การจัดเก็บ | ฝั่งไคลเอนต์ (ในโทเค็น) | ฝั่งเซิร์ฟเวอร์ (ในหน่วยความจำหรือ DB) | | ความสามารถในการขยายขนาด | ไม่ต้องการที่เก็บเซสชันร่วมกัน | ต้องการที่เก็บเซสชันร่วมกันระหว่างอินสแตนซ์ | | ข้ามโดเมน | ทำงานข้ามโดเมนได้ตามธรรมชาติ | ยากที่จะแชร์เซสชัน | | เป็นมิตรกับมือถือ | ใช่ (ไม่ต้องการ cookies) | ต้องการการสนับสนุน cookie | | การเพิกถอน | ยาก (จนกว่าโทเค็นจะหมดอายุ) | ง่าย (ลบเซสชันจากที่เก็บ) | | ขนาด payload | ใหญ่กว่าต่อคำขอ (โทเค็นใน header) | น้อยที่สุด (แค่ session ID) |

ทำไม JWT จึงใช้สำหรับความปลอดภัยของ API

คุณลักษณะที่ทำให้ JWT เหมาะสำหรับการรับรองความถูกต้องยังทำให้เหมาะสำหรับการรักษาความปลอดภัย API อีกด้วย

ไร้สถานะและปรับขนาดได้

ทุก JWT นำพาข้อมูลทั้งหมดที่เซิร์ฟเวอร์ต้องการเพื่ออนุญาตคำขอ ไม่มีฐานข้อมูลเซสชันให้สอบถาม ไม่มีแคชให้ตรวจสอบ ไม่มีสถานะให้ซิงโครไนซ์ข้ามเซิร์ฟเวอร์ load balancer สามารถส่งคำขอไปยังอินสแตนซ์เซิร์ฟเวอร์ใดๆ ได้โดยไม่ต้องประสานงาน

ข้ามโดเมนและข้ามต้นทาง

JWT ทำงานข้ามโดเมนและต้นทางที่แตกต่างกันได้ตามธรรมชาติ โทเค็นที่ออกโดย auth.example.com สามารถใช้เข้าถึง api.example.com และ admin.example.com สิ่งนี้ทำให้ JWT เป็นรากฐานของระบบ single sign-on (SSO)

การอนุญาตแบบละเอียด

payload ของ JWT สามารถรวม claims ที่กำหนดเองสำหรับบทบาท สิทธิ์ และการเป็นสมาชิกองค์กร:

{
  "sub": "user_abc123",
  "role": "admin",
  "permissions": ["read:users", "write:users", "delete:users"],
  "org_id": "org_xyz789",
  "iat": 1516239022,
  "exp": 1516325422
}

เซิร์ฟเวอร์ API อ่าน claims เหล่านี้โดยตรงจากโทเค็นโดยไม่ต้องค้นหาเพิ่มเติม

JWT สำหรับ Single Sign-On (SSO)

Single sign-on เป็นหนึ่งในกรณีการใช้งาน JWT ที่พบบ่อยที่สุด ในสถาปัตยกรรม SSO ทั่วไป:

1. ผู้ใช้เข้าสู่ระบบ identity provider (IdP) — เช่น Auth0, Okta หรือ Keycloak
2. IdP ออก JWT ที่ลงนามด้วย private key ของตน
3. ผู้ใช้แสดง JWT นี้ต่อแอปพลิเคชันหลายตัว
4. แต่ละแอปพลิเคชันตรวจสอบลายเซ็นโดยใช้ public key ของ IdP
5. แต่ละแอปพลิเคชันเชื่อถือโทเค็นโดยไม่ต้องสื่อสารกับ IdP ในทุกคำขอ

รูปแบบนี้ทำให้การเข้าสู่ระบบครั้งเดียวสามารถให้สิทธิ์การเข้าถึงบริการมากมาย — อีเมล, ที่เก็บไฟล์, การจัดการโครงการ, ระบบ HR — โดยไม่ต้องให้แต่ละบริการใช้โฟลว์การเข้าสู่ระบบของตัวเอง

แนวปฏิบัติที่ดีที่สุดด้านความปลอดภัยของ JWT

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

เก็บโทเค็นให้มีอายุสั้น

ตั้งค่า claim exp (การหมดอายุ) ให้มีระยะเวลาสั้น — 15 นาทีถึง 1 ชั่วโมงสำหรับ access token ใช้ refresh token ที่มีอายุยาวนานกว่า (วันหรือสัปดาห์) เพื่อขอ access token ใหม่โดยไม่ต้องให้ผู้ใช้รับรองความถูกต้องใหม่

ใช้ HTTPS เสมอ

JWT ไม่ได้เข้ารหัส payload ของมัน ใครก็ตามที่ดักจับโทเค็นสามารถถอดรหัสและอ่านเนื้อหาได้ ส่ง JWT ผ่าน HTTPS เสมอเพื่อป้องกันการดักจับ

ตรวจสอบทุกอย่าง

ตรวจสอบลายเซ็นเสมอ ตรวจสอบว่าโทเค็นยังไม่หมดอายุ ยืนยันว่า aud (ผู้รับ) ตรงกับแอปพลิเคชันของคุณ และปฏิเสธโทเค็นที่มีอัลกอริทึมที่ไม่คาดคิด

เก็บโทเค็นอย่างปลอดภัย

ฝั่งไคลเอนต์ เก็บ JWT ใน HTTP-only cookies เมื่อเป็นไปได้ หรือในหน่วยความจำสำหรับ single-page applications หลีกเลี่ยง localStorage สำหรับโทเค็นที่ให้การเข้าถึงข้อมูลที่ละเอียดอ่อน

ความเข้าใจผิดทั่วไปเกี่ยวกับ JWT

"JWT ถูกเข้ารหัส" — ไม่ใช่ JWT ถูกลงนาม ไม่ได้ถูกเข้ารหัส payload ถูกเข้ารหัสแบบ base64url ซึ่งสามารถย้อนกลับได้ JWE (JSON Web Encryption) ให้การเข้ารหัส แต่มันเป็นข้อกำหนดแยกต่างหากที่ไม่ได้ครอบคลุมโดย JWT มาตรฐาน

"JWT ป้องกัน CSRF" — ไม่ใช่โดยตัวมันเอง JWT ใน Authorization header ช่วยได้ แต่หากโทเค็นอยู่ใน cookie ก็ยังต้องการการป้องกัน CSRF

"JWT ใช้สำหรับการรับรองความถูกต้องเท่านั้น" — JWT ใช้สำหรับการรับรองความถูกต้อง แต่ยังใช้สำหรับการแลกเปลี่ยนข้อมูลการอนุญาต เซสชันไร้สถานะ และการแชร์ข้อมูลที่ปลอดภัยระหว่างบริการ

ถอดรหัสและสำรวจ JWT ออนไลน์

ใช้เครื่องมือถอดรหัส JWT เพื่อตรวจสอบ JSON Web Token ใดๆ วางโทเค็นของคุณและดู header, payload และอัลกอริทึมลายเซ็นที่ถอดรหัสแล้วทันที เครื่องมือช่วยให้คุณเข้าใจว่าข้อมูลใดที่โทเค็นของคุณนำพาและตรวจสอบว่ามีโครงสร้างที่ถูกต้อง