ฉันควรจัดเก็บการอ้างสิทธิ์ผู้ใช้ของฉันในโทเค็น JWT หรือไม่


18

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

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

ตัวอย่างของการอ้างสิทธิ์คือ: CanEditProductList, CanEditShopDescription, CanReadUserDetails

เหตุผลที่ฉันต้องการใช้โทเค็น JWT สำหรับพวกเขาคือ:

  • การป้องกันที่ดีขึ้นต่อการแก้ไขการเคลมสินค้าด้านลูกค้า
  • ไม่จำเป็นต้องค้นหาการอ้างสิทธิ์ในทุกคำขอ

เหตุผลที่ฉันไม่ต้องการใช้โทเค็น JWT:

  • เซิร์ฟเวอร์รับรองความถูกต้องจะต้องทราบรายการการเรียกร้องเป็นศูนย์กลางของแอพ
  • โทเค็นกลายเป็นจุดเดียวของการแฮ็ค
  • ฉันได้อ่านบางสิ่งที่บอกว่าโทเค็น JWT ไม่ได้มีไว้สำหรับข้อมูลระดับแอป

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

หมายเหตุ: ฉันจะใช้ HTTPS สำหรับคำขอ API ทั้งหมดดังนั้นดูเหมือนว่าโทเค็นจะปลอดภัยพอ ฉันใช้ AngularJS, C #, Web API 2 และ MVC5


อ่านตอนนี้ .... และต้องการอัปเดตถ้าคุณสามารถ ฉันจะสนใจในสิ่งที่คุณทำเพราะฉันกำลังเผชิญกับความคิด .. และฉันก็คิดถึงว่าชิ้นส่วนบางชิ้นมีจุดประสงค์เพื่อทำงานอย่างไร ผู้ใช้ได้รับโทเค็นการอนุญาต แต่แล้วจะมีการดำเนินการเรียกร้องอย่างไร ... คุณสามารถอธิบายในสิ่งที่คุณค้นพบ ... เพราะมันอาจช่วยฉันได้
Seabizkit

คำตอบ:


7

ฉันจัดเก็บการอ้างสิทธิ์ตัวระบุเท่านั้น (หมายเลขผู้ใช้ ฯลฯ ) (เข้ารหัส) ใน jwt ของฉัน

จากนั้นเมื่อฉันได้รับโทเค็นบนเซิร์ฟเวอร์ (API) ฉันสามารถทำฝั่งเซิร์ฟเวอร์ค้นหา (db หรือการเรียก api เครือข่ายท้องถิ่น) และดึงการเชื่อมโยงทั้งหมดไปยังหมายเลขผู้ใช้ (แอปบทบาท ฯลฯ )

อย่างไรก็ตามหากคุณต้องการข้อมูลเพิ่มเติมใน jwt ให้ระวังขนาดเนื่องจากมันจะถูกส่งในแต่ละคำขอ แต่ให้แน่ใจว่าได้เข้ารหัสข้อมูลการอ้างสิทธิ์ที่ละเอียดอ่อน


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

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

ฉันคิดว่ามันเป็นความคิดที่ดีที่จะได้รับข้อมูลที่จำเป็นทั้งหมดบนเซิร์ฟเวอร์ทรัพยากรและไม่เก็บไว้ในโทเค็น
Mateusz Migała

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

3

ดูเหมือนว่าการรับรองความถูกต้อง (ผู้ใช้คือใคร) และการอนุญาต (สิ่งที่ผู้ใช้อนุญาตให้ทำ) จะไม่ถูกแบ่งอย่างชัดเจนตามที่คุณต้องการ

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

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

หมายเหตุ: JWT ทั้งสองควรลงนามโดยคีย์ที่แตกต่างกัน

ข้อดี:

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

Con:

  • ไคลเอนต์ต้องจัดการโทเค็นที่สองแทนหนึ่ง
  • การเพิ่มเซิร์ฟเวอร์การอนุญาตจะเพิ่มส่วนที่เคลื่อนไหวเพื่อจัดการ

1
อย่าลืมว่าแม้เมื่อคุณตรวจสอบการอนุญาตใน UI คุณยังต้องตรวจสอบการอนุญาตด้านเซิร์ฟเวอร์เมื่อมีคำขอมาถึง
ชาดคลาร์ก
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.