JWT (JSON Web Token) เป็นมาตรฐานเปิด (RFC 7519) ที่กำหนดวิธีการที่กระชับและสมบูรณ์ในตัวเองสำหรับการส่งข้อมูลอย่างปลอดภัยระหว่างคู่กรณี ข้อมูลนี้สามารถตรวจสอบและเชื่อถือได้เพราะมีการเซ็นแบบดิจิทัล
JWT ประกอบด้วยสามส่วนที่คั่นด้วยจุด (.): เฮดเดอร์ (Header), เพย์โหลด (Payload) และลายเซ็น (Signature) เฮดเดอร์ระบุอัลกอริทึมลายเซ็น เพย์โหลดประกอบด้วยคำประกาศ และลายเซ็นใช้เพื่อยืนยันว่าข้อความไม่ถูกแก้ไข
สถานการณ์ทั่วไปที่ใช้ JWT
การตรวจสอบสิทธิ์ (สถานการณ์ที่พบบ่อยที่สุด), การแลกเปลี่ยนข้อมูล (JWT สามารถส่งข้อมูลได้อย่างปลอดภัยเพราะสามารถเซ็นได้), การอนุญาต (รวมข้อมูลสิทธิ์ของผู้ใช้) และการใช้งาน Single Sign-On
ประเภทของอัลกอริทึมลายเซ็น
JWT รองรับอัลกอริทึมลายเซ็นหลายประเภท แบ่งเป็นสองประเภทหลัก: อัลกอริทึมสมมาตรแบบ HMAC (เช่น HS256) และอัลกอริทึมอสมมาตรแบบ RSA/ECDSA (เช่น RS256, ES256) อัลกอริทึมสมมาตรใช้คีย์เดียวกันสำหรับเซ็นและตรวจสอบ อัลกอริทึมอสมมาตรใช้คีย์ส่วนตัวสำหรับเซ็นและคีย์สาธารณะสำหรับตรวจสอบ
อย่าเก็บข้อมูลสำคัญ (เช่น รหัสผ่าน) ใน JWT เพราะเพย์โหลดของ JWT เป็นเพียงการเข้ารหัส Base64 ไม่ได้เข้ารหัส สำหรับแอปพลิเคชันที่ต้องการความปลอดภัยสูง แนะนำให้ใช้เวลาหมดอายุที่สั้นและใช้กลยุทธ์การหมุนเวียนโทเค็น
จะทำอย่างไรเมื่อ JWT หมดอายุ?
เมื่อ JWT หมดอายุ เซิร์ฟเวอร์จะปฏิเสธโทเค็นนี้ วิธีแนะนำคือการใช้กลไก Refresh Token โดยที่ไคลเอ็นต์ใช้ Refresh Token เพื่อรับ Access Token ใหม่โดยไม่ต้องให้ผู้ใช้เข้าสู่ระบบใหม่ Refresh Token มักจะมีอายุการใช้งานที่ยาวนานกว่า แต่ควรเก็บอย่างระมัดระวัง
โดยการออกแบบ JWT เป็นโทเค็นที่ไม่มีสถานะและไม่สามารถยกเลิกได้จริงๆ แต่มีวิธีแก้ไขทั่วไปบางวิธี: รักษาบัญชีดำของโทเค็นที่ถูกยกเลิก (อาจลดข้อดีของการไม่มีสถานะของ JWT), ใช้เวลาหมดอายุที่สั้นร่วมกับ Refresh Token, หรือฝังตัวระบุเวอร์ชันในโทเค็นและเซิร์ฟเวอร์สามารถปฏิเสธเวอร์ชันเก่า
ความแตกต่างระหว่าง JWT และ session?
JWT เป็นโทเค็นที่สมบูรณ์ในตัวเอง ประกอบด้วยข้อมูลทั้งหมดที่จำเป็น เหมาะสำหรับระบบกระจายศูนย์ ไม่ต้องการให้เซิร์ฟเวอร์เก็บสถานะเซสชัน Session ขึ้นอยู่กับการเก็บข้อมูลฝั่งเซิร์ฟเวอร์ ต้องรักษาสถานะเซสชัน เหมาะสำหรับสถาปัตยกรรมเซิร์ฟเวอร์เดียว JWT เป็นมิตรกับการขยาย แต่การยกเลิกซับซ้อน; Session ยกเลิกง่าย แต่ขยายได้ยาก