สถาปัตยกรรม JWT สำหรับผู้ใช้หลายคน?

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

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

ปรากฎว่า 1 แอป : 1 คีย์ พร้อมข้อสังเกตบางประการ

1. คีย์นี้ไม่ควรเปลี่ยนแปลงในทางทฤษฎี: หาก ณ เวลา T1 KEY=x ผู้ใช้สามารถเข้าสู่ระบบและรับ JWT ที่ลงนามด้วย KEY=x ที่ T2 KEY=y ผู้ใช้จะเรียกใช้ API บางส่วนโดยใช้ JWT ก่อนหน้า และเซิร์ฟเวอร์จะพยายามตรวจสอบ(signature(payload , x) , y) ดังนั้นผู้ใช้ทุกคนจะถูกออกจากระบบโดยอัตโนมัติ

2. แม้ว่า 1. การหมุนกุญแจจะเป็นการดี ในกรณีนี้ ระบบการตรวจสอบความถูกต้องควรบันทึกบัฟเฟอร์ของคีย์เก่า และใช้เพื่อตรวจสอบ JWT ที่เก่าที่สุด เนื่องจาก JWT ควรมีอายุการใช้งานสั้น จึงอาจมีประโยชน์ในการตั้งค่าเวลาการหมุนให้มากกว่าเวลาหมดอายุของ JWT และเพียงเก็บคีย์ที่ใช้ล่าสุดไว้พร้อมกับค่าปัจจุบัน

3. คีย์นี้เป็นความลับและควรได้รับการจัดการเหมือนกับข้อมูลลับอื่นๆ ทุกประการ นอกเหนือจากวิธีการที่แย่ เช่น ปล่อยให้มันเป็นข้อความธรรมดาในโค้ด/การกำหนดค่า ยังมีผู้จัดการความลับจากผู้ให้บริการคลาวด์ หรือความลับของ kubernetes หากคุณใช้อย่างหลัง เช่นเดียวกับผู้จัดการความลับจากเครื่องมือการจัดการการกำหนดค่า (เกลือ, ansible) หรือ ห้องนิรภัยของ Hashicorp ซึ่งเป็นเครื่องมือจัดเก็บข้อมูลเฉพาะสำหรับข้อมูลที่ละเอียดอ่อน อย่างไรก็ตาม หากคุณอยู่ในองค์กรที่มีโครงสร้างจะเป็นเรื่องที่น่ากังวลมากกว่าเกี่ยวกับอินฟาเรด/ทีมรักษาความปลอดภัย