เพิ่มคุณสมบัติของผู้ใช้ตามที่ต้องการสำหรับโทเค็นการเข้าถึง JWT ด้วย Logto เพื่อเพิ่มประสิทธิภาพการอนุญาตให้สูงสุด

ในบทความก่อนหน้านี้เราได้กล่าวถึงว่า หลายระบบเริ่มใช้โทเค็นการเข้าถึงแบบ JWT สำหรับการพิสูจน์ตัวตนของผู้ใช้และการควบคุมการเข้าถึง หนึ่งในเหตุผลสำคัญคือ JWT สามารถเก็บข้อมูลที่มีประโยชน์ เช่น บทบาทและสิทธิ์ของผู้ใช้ ข้อมูลเหล่านี้สามารถช่วยให้เราส่งผ่านข้อมูลการระบุผู้ใช้ระหว่างเซิร์ฟเวอร์และไคลเอนต์ จึงสามารถบรรลุการพิสูจน์ตัวตนของผู้ใช้และการควบคุมการเข้าถึงได้ ปกติแล้วข้อมูลที่รวมอยู่ใน JWT จะถูกกำหนดโดยเซิร์ฟเวอร์การพิสูจน์ตัวตน ตามโปรโตคอล OAuth 2.0, JWT มักจะมีฟิลด์เช่น sub (เรื่อง), aud (ผู้ฟัง), และ exp (เวลาหมดอายุ) ซึ่งมักถูกเรียกว่า claims ซึ่ง claims เหล่านี้สามารถช่วยยืนยันความถูกต้องของโทเค็นการเข้าถึงได้ อย่างไรก็ตามมีแสดการณ์การใช้งานมากมายที่ JWT ถูกใช้สำหรับการยืนยัน claim ของ JWT ทั่วไปมักจะไม่เพียงพอต่อความต้องการของผู้ใช้ ผู้คนมักจะคิดว่าถ้า JWT สามารถมีข้อมูลบ้าง เราสามารถเพิ่มข้อมูลบางอย่างให้ทำให้อำนวยความสะดวกในการอนุญาตได้หรือไม่ คำตอบคือ ได้, เราสามารถเพิ่ม claims ของผู้ใช้เองใน JWT เช่น ขอบเขตและระดับการสมัครของผู้ใช้ปัจจุบัน ด้วยวิธีนี้เราสามารถส่งผ่านข้อมูลการระบุผู้ใช้ระหว่างไคลเอนต์และเซิร์ฟเวอร์ (นี่หมายถึงเซิร์ฟเวอร์ที่ให้บริการต่างๆ เรียกว่าผู้ให้บริการ) เพื่อบรรลุการพิสูจน์ตัวตนและการควบคุมการเข้าถึง สำหรับ claims ของ JWT มาตรฐาน กรุณาอ้างอิงที่ RFC7519 Logto ในฐานะที่เป็นโซลูชั่นการระบุที่สนับสนุนทั้งการพิสูจน์ตัวตนและการอนุญาต ได้ทำการขยาย claims ของทรัพยากรและขอบเขตเพื่อลองใช้กับ RBAC ในมาตรฐาน ถึงแม้ว่า Logto จะมีการติดตั้ง RBAC ที่ใช้มาตรฐาน แต่ยังไม่ง่ายและยืดหยุ่นพอสำหรับทุกกรณีการใช้งานอันมีมากมาย ขึ้นอยู่กับสิ่งนี้, Logto สร้างฟีเจอร์ใหม่ของ claims ของ JWT ที่สามารถกำหนดเองได้ ให้ผู้ใช้กำหนด claims ของ JWT เพิ่มเติมได้เพื่อให้การพิสูจน์ตัวตนและการควบคุมการเข้าถึงมีความยืดหยุ่นมากขึ้น

Logto claims ของ JWT ของผู้ใช้เองทำงานอย่างไร?#

คุณสามารถไปยังหน้ารายการ Custom JWT ได้ด้วยการคลิกที่ปุ่ม "JWT claims" ในแถบด้านข้าง

ไปเริ่มจากการเพิ่ม claims ของผู้ใช้เองสำหรับผู้ใช้ปลายทางกันเถอะ

ใน editor ข้างซ้าย คุณสามารถกำหนดค่าฟังก์ชัน getCustomJwtClaims ของคุณเองได้ วิธีนี้มีพารามิเตอร์การป้อนข้อมูลสามตัว: token, data, และ envVariables

• token คือ payload ของโทเค็นการเข้าถึงดิบที่ได้จากข้อมูลประจำตัวของผู้ใช้ปลายทางปัจจุบันและการตั้งค่าระบบของคุณ รวมถึงข้อมูลที่เกี่ยวข้องกับการเข้าถึงผู้ใช้ใน Logto
• data คือข้อมูลทั้งหมดเกี่ยวกับผู้ใช้ใน Logto รวมถึงบทบาทของผู้ใช้ทั้งหมด, ตัวตนการเข้าสู่ระบบสังคม, ตัวตน SSO, การเป็นสมาชิกองค์กร ฯลฯ
• envVariables คือค่าตัวแปรแวดล้อมที่คุณตั้งค่าใน Logto สำหรับการใช้งานโทเค็นการเข้าถึงของผู้ใช้ปลายทางปัจจุบัน เช่น API key(s) ของ APIs ภายนอกที่ต้องการ ฯลฯ

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

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

เพิ่มประสิทธิภาพการอนุญาตด้วย claims ของ JWT ผู้ใช้เอง: ตัวอย่างที่เป็นประโยชน์#

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

การตั้งค่าตัวอย่าง#

ทีมของ John พัฒนาแอปผู้ช่วย AI ที่ช่วยให้ผู้ใช้พูดคุยกับหุ่นยนต์ AI เพื่อรับบริการต่างๆ บริการของหุ่นยนต์ AI แบ่งเป็นบริการฟรีและจ่ายเงิน บริการฟรีรวมถึงข้อเสนอพิเศษเที่ยวบิน ในขณะที่บริการที่จ่ายเงินรวมถึงการพยากรณ์หุ้น แอปผู้ช่วย AI ใช้ Logto เพื่อจัดการผู้ใช้ทั้งหมด ซึ่งแบ่งออกเป็นสามประเภท: ผู้ใช้ฟรี, ผู้ใช้จ่ายล่วงหน้า, และผู้ใช้พรีเมียม ผู้ใช้ฟรีสามารถใช้บริการฟรีเท่านั้น ผู้ใช้จ่ายล่วงหน้าสามารถใช้บริการทั้งหมด (คิดค่าบริการตามการใช้งาน) และผู้ใช้พรีเมียมสามารถใช้บริการทั้งหมด (แต่มีขีดจำกัดอัตราเพื่อป้องกันการใช้ที่ไม่ถูกต้อง) นอกจากนี้ แอปผู้ช่วย AI ยังใช้ Stripe เพื่อจัดการการชำระเงินของผู้ใช้และมีบริการสถิติเพื่อบันทึกการดำเนินการของผู้ใช้

การตั้งค่า Logto#

เราสร้างทรัพยากร API สำหรับบริการแอปผู้ช่วย AI และสร้างขอบเขตสองตัว recommend:flight และ predict:stock หลังจากนั้นเราสร้างบทบาทสองตัว free-user และ paid-user และกำหนดขอบเขตที่สอดคล้องกัน:

• กำหนดขอบเขต recommend:flight ให้กับบทบาท free-user
• กำหนดทั้งขอบเขต recommend:flight และ predict:stock ให้กับบทบาท paid-user

สุดท้ายเราสร้างผู้ใช้สามคน free-user, prepaid-user, และ premium-user แล้วกำหนดบทบาทที่สอดคล้องกัน:

• กำหนดบทบาท free-user ให้กับผู้ใช้ free-user
• กำหนดบทบาท paid-user ให้กับผู้ใช้ prepaid-user และ premium-user

ตามที่แสดงในภาพต่อไปนี้เพื่อให้ได้ข้อมูลการอนุญาตที่ต้องการสำหรับสถานการณ์ที่อธิบายไว้ข้างต้น เราหวังที่จะรวม roles, balance และ numOfCallsToday ของผู้ใช้ที่เข้าสู่ระบบปัจจุบันใน JWT เมื่อยืนยันการเข้าถึงโทเค็นในแอปผู้ช่วย AI ข้อมูลเหล่านี้สามารถใช้ในการตรวจสอบสิทธิ์อย่างรวดเร็ว หลังจากกำหนดค่า envVariables เราดำเนินการฟังก์ชัน getCustomJwtClaims และคลิก "Run test" เพื่อดูผลลัพธ์ของ claims ของ JWT เพิ่มเติมตามข้อมูลการทดสอบปัจจุบัน เนื่องจากยังไม่ได้กำหนดข้อมูลการทดสอบสำหรับ data.user.roles การทดสอบแสดงว่าผลลัพธ์เป็นอาร์เรย์ว่าง สำหรับผู้ใช้พรีเมียมเราสามารถเห็น roles เป็น ["paid-user"] และทั้ง isPaidUser และ isPremiumUser เป็น true

ตรวจสอบว่าฟีเจอร์ custom JWT ใช้งานหรือไม่#

ตามการกำหนดค่า Logto ข้างบนเราจะได้รับผลลัพธ์ที่เกี่ยวข้องในการทดสอบ ต่อไปเราจะใช้แอปตัวอย่างที่ Logto ให้เพื่อยืนยันว่าฟีเจอร์ custom JWT ของเรามีผล หา SDK ที่คุณถนัดจาก Logto SDKs และปรับใช้แอปตัวอย่างตามเอกสารและ GitHub repo ที่เกี่ยวข้อง ตามการกำหนดค่าที่เรากล่าวถึงข้างบน โดยใช้ React SDK เป็นตัวอย่าง เราจะต้องอัพเดตการตั้งค่าที่เกี่ยวข้องใน LogtoConfig:

หลังจากลงชื่อเข้าใช้ผู้ใช้ 'free_user' ในแอปตัวอย่างที่จำลองแอปผู้ช่วย AI เราสามารถดู roles, balance, numOfCallsToday, isPaidUser, isPremiumUser ที่เราระบุเองได้โดยดูที่ส่วน payload ของโทเค็นการเข้าถึง JWT

อัปเดตตรรกะการอนุญาตของผู้ให้บริการ#

จากขั้นตอนก่อนหน้าเราได้เพิ่ม claims ของผู้ใช้เองตามความต้องการทางธุรกิจในโทเค็นการเข้าถึงผู้ใช้ ต่อไปเราใช้ claims เหล่านี้ในการตรวจสอบการอนุญาตอย่างรวดเร็ว

เราจะใช้ตรรกะการยืนยัน JWT ที่ Logto ใช้กับโทเค็นการเข้าถึงด้าน API รหัสตัวอย่างทั้งหมดสามารถหาดูได้ใน GitHub repo:

คุณสามารถอ้างอิงตรรกะของ Logto API ในการตรวจสอบโทเค็นการเข้าถึงและปรับแต่งตามตรรกะธุรกิจของคุณเอง ตัวอย่างเช่น สำหรับสถานการณ์แอปผู้ช่วย AI ที่อธิบายไว้ที่นี่คุณสามารถเพิ่มตรรกะการยืนยันสำหรับ claims ของผู้ใช้เองอย่าง roles, balance, numOfCallsToday, isPaidUser และ isPremiumUser ในฟังก์ชัน verifyBearerTokenFromRequest

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

ทำไมจึงต้องใช้ custom JWT claims?#

เราได้ให้ตัวอย่างสถานการณ์แอปผู้ช่วย AI ของ John และวิธีการใช้ฟีเจอร์ Custom JWT ของ Logto เพื่อบรรลุการตรวจสอบสิทธิ์อย่างยืดหยุ่นมากขึ้น ในกระบวนการนี้เราได้เห็นข้อดีของฟีเจอร์ Custom JWT:

1. เงื่อนไขไม่มีฟีเจอร์ Custom JWT ผู้ใช้จะต้องร้องขอ API ภายนอก (เช่นที่คุณทำใน getCustomJwtClaims) ทุกครั้งที่ตรวจสอบสิทธิ์ สำหรับผู้ให้บริการที่ให้ API นี้อาจเพิ่มภาระพิเศษได้ ด้วยฟีเจอร์ Custom JWT ข้อมูลเหล่านี้สามารถวางลงใน JWT โดยตรงเพื่อลดการเรียก API ภายนอกบ่อยๆ
2. สำหรับผู้ให้บริการ ฟีเจอร์ Custom JWT ช่วยให้พวกเขาตรวจสอบสิทธิ์ผู้ใช้ได้เร็วขึ้น โดยเฉพาะเมื่อไคลเอ็นต์เรียกผู้ให้บริการบ่อยๆ การปรับปรุงการทำงานของบริการ
3. ฟีเจอร์ Custom JWT ช่วยให้สามารถใช้งานข้อมูลการอนุญาตเพิ่มเติมที่ธุรกิจต้องการได้อย่างรวดเร็ว ข้อมูลที่สามารถส่งอยู่ระหว่างไคลเอนต์และผู้ให้บริการได้อย่างปลอดภัยเนื่องจาก JWT เป็นตัวเองและสามารถเข้ารหัสได้ให้ยากต่อการปลอมแปลง

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

สรุป#

ในบทความนี้ Logto ได้ขยายโทเค็นการเข้าถึง JWT พื้นฐานและขยายฟังก์ชันของ claims JWT เพิ่มเติมให้ผู้ใช้ใส่ข้อมูลของผู้ใช้ปลายทางเพิ่มเติมลงในโทเค็นการเข้าถึง JWT ตามความต้องการทางธุรกิจของพวกเขาเพื่อที่ว่าหลังจากที่ผู้ใช้ล็อกอิน สิทธิ์ของผู้ใช้สามารถตรวจสอบได้อย่างรวดเร็ว เราได้ให้ตัวอย่างสถานการณ์แอปผู้ช่วย AI ของ John และแสดงวิธีการใช้ฟีเจอร์ Custom JWT ของ Logto เพื่อบรรลุการตรวจสอบสิทธิ์อย่างยืดหยุ่นมากขึ้น นอกจากนี้ เรายังชี้ให้เห็นหัวข้อสำคัญบางประการในการใช้ custom JWT ควบคู่ไปกับสถานการณ์ธุรกิจจริง ผู้ใช้สามารถนำข้อมูลที่เกี่ยวข้องกับผู้ใช้ต่างๆ ลงในโทเค็นการเข้าถึง JWT ตามความต้องการทางธุรกิจ เพื่อให้ผู้ให้บริการสามารถตรวจสอบสิทธิ์ของผู้ใช้ได้อย่างรวดเร็ว