การควบคุมการเข้าถึงตามบทบาท (RBAC) (Role-based access control (RBAC))

การควบคุมการเข้าถึงตามบทบาท (RBAC) เป็นโมเดลการอนุญาต (Authorization) ที่ได้รับการพิสูจน์แล้ว โดยจับคู่การกระทำทางธุรกิจในโลกจริงกับบทบาท (Roles) และสิทธิ์ (Permissions) คู่มือนี้จะอธิบายการทำงานของ RBAC ใน Logto รูปแบบการออกแบบที่ใช้ได้จริง และแนวปฏิบัติที่ดีที่สุดสำหรับการสร้างแอป SaaS ที่ปลอดภัยและขยายได้

RBAC คืออะไร?

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

แนวคิดหลัก

• บทบาท (Role): ชุดของสิทธิ์ที่มีชื่อ (เช่น admin, viewer, billing-manager)
• สิทธิ์ (Permission): การกระทำหรือสิทธิ์ (เช่น manage:members, view:analytics)
• ขอบเขต (Scope): คำพ้องความหมายของสิทธิ์ มักใช้ในบริบท OAuth 2.0
• ทรัพยากร API (API resource): API, endpoint หรือบริการที่สิทธิ์ถูกนำไปใช้
• ผู้ใช้ / ไคลเอนต์ (User/Client): เอนทิตีที่ได้รับมอบหมายบทบาท (ผู้ใช้ปลายทางหรือแอป M2M)

บันทึก:

ใน Logto (และ OAuth 2.1) “สิทธิ์ (permissions)” และ “ขอบเขต (scopes)” หมายถึงแนวคิดเดียวกัน และใช้แทนกันได้ตลอดเอกสารนี้

ทรัพยากร API (API resources)

ทรัพยากร API (API resource) คือ endpoint หรือบริการที่ได้รับการปกป้องในแอปของคุณ เช่น REST API, GraphQL endpoint หรือบริการ backend อื่น ๆ ที่ต้องการการอนุญาต

Logto สร้างโมเดลทรัพยากร API ตาม RFC 8707: Resource Indicators for OAuth 2.0
แต่ละทรัพยากร API จะถูกระบุอย่างไม่ซ้ำด้วย ตัวบ่งชี้ทรัพยากร (resource indicator) (URI) ซึ่งใช้สำหรับกำหนดขอบเขตของโทเค็นการเข้าถึง (Access token) และบังคับข้อจำกัดของผู้รับ (Audience)

ชื่อพร็อพเพอร์ตี้	คำอธิบาย	จำเป็น
ชื่อ API	ชื่อที่เข้าใจง่ายสำหรับระบุทรัพยากร API ใน Console และ log	ใช่
ตัวระบุ API	URI ตัวบ่งชี้ทรัพยากร (resource indicator) ที่ไม่ซ้ำกันซึ่งแทนทรัพยากร API	ใช่
เวลาหมดอายุของโทเค็น	อายุการใช้งานของโทเค็นการเข้าถึงที่ออกให้กับ API นี้ (วินาที) ค่าเริ่มต้นคือ 3600 (1 ชั่วโมง)	ไม่จำเป็น
API เริ่มต้น	ทรัพยากร API หนึ่งเดียวเท่านั้นที่สามารถตั้งเป็นค่าเริ่มต้นต่อ Logto tenant เมื่อกำหนดแล้วสามารถละเว้นพารามิเตอร์ resource ในคำขอ auth ได้	ไม่จำเป็น

บันทึก:

เมื่อมีการกำหนดทรัพยากร API เริ่มต้น Logto จะใช้เป็นผู้รับ (Audience) สำหรับโทเค็นเมื่อไม่มีการระบุพารามิเตอร์ resource ในคำขอการยืนยันตัวตน (Authentication request)

พฤติกรรมของทรัพยากร API เริ่มต้น

ใน Logto ทุกสิทธิ์ (ขอบเขต) ระดับโกลบอลที่ผู้ใช้กำหนดเองต้องเชื่อมโยงกับทรัพยากร API มิฉะนั้นสิทธิ์นั้นจะถูกจัดการเป็นขอบเขต OIDC

โดยทั่วไปสิ่งนี้จะไม่กระทบกับการเชื่อมต่อส่วนใหญ่ แต่เมื่อทำงานกับแอป third-party ที่ ไม่ รองรับ RFC 8707 คำขอการอนุญาตเริ่มต้นอาจไม่มีพารามิเตอร์ resource ในกรณีนี้ Logto จะออก โทเค็นการเข้าถึงแบบทึบ (opaque access tokens) แทน JWT ซึ่งอาจทำให้การควบคุมการเข้าถึงซับซ้อนขึ้น

เพื่อแก้ปัญหานี้ คุณสามารถตั้งค่า ทรัพยากร API เริ่มต้น ให้กับ tenant ของคุณได้:

• เมื่อไม่มีพารามิเตอร์ resource ใน คำขอการยืนยันตัวตน (Authentication request):
  • Logto จะใช้ทรัพยากร API เริ่มต้นเป็นผู้รับ (Audience) สำหรับโทเค็นการเข้าถึง
• หากมีขอบเขต openid:
  • Logto จะออกโทเค็นการเข้าถึงแบบทึบสำหรับ Userinfo endpoint เมื่อไม่มี resource ในคำขอโทเค็น
• หากไม่มีขอบเขต openid:
  • Logto จะออก JWT access token สำหรับทรัพยากร API เริ่มต้นเป็นผู้รับ (Audience)

การตั้งค่าทรัพยากร API เริ่มต้นช่วยให้การเชื่อมต่อกับแอปที่ไม่รองรับ RFC 8707 เป็นไปอย่างราบรื่น พร้อมทั้งยังคงรักษาความปลอดภัยและมาตรฐานการควบคุมการเข้าถึง

RBAC ใน Logto

Logto ให้ RBAC ที่ยืดหยุ่นทั้งในระดับ โกลบอล และ องค์กร เพื่อรองรับ SaaS แบบหลายผู้เช่า (multi-tenant):

• บทบาทโกลบอล (Global roles) กำหนดข้าม Logto tenant เหมาะสำหรับสิทธิ์ระดับผลิตภัณฑ์ ผู้ดูแลระบบ หรือ superuser
• บทบาทองค์กร (Organization roles) กำหนดภายในองค์กร เหมาะสำหรับการเข้าถึงเฉพาะองค์กร เช่น ผู้ดูแล workspace สมาชิกโปรเจกต์ หรือกลุ่มที่กำหนดเอง
• ทรัพยากร API (API resources) API และฟีเจอร์ที่ต้องการการอนุญาต
• สิทธิ์ (ขอบเขต) (Permissions / scopes) กำหนดต่อทรัพยากร API หรือในเทมเพลตองค์กร
  • สิทธิ์ของทรัพยากร API สามารถกำหนดให้กับบทบาทโกลบอลหรือองค์กรก็ได้
  • สิทธิ์ขององค์กรสามารถกำหนดให้กับบทบาทองค์กรเท่านั้น

ขึ้นอยู่กับความต้องการของผลิตภัณฑ์ คุณสามารถใช้โมเดล RBAC เหล่านี้แยกกันหรือผสมกันก็ได้

ตัวอย่างต่อไปนี้แสดงตัวอย่าง 3 รูปแบบพร้อมแผนภาพ:

รูปแบบที่ 1: ทรัพยากร API ระดับโกลบอล

สถานการณ์

ผลิตภัณฑ์ SaaS ที่มี API ใช้ร่วมกันกับผู้ใช้ทุกคนโดยไม่คำนึงถึงองค์กร
ใช้บทบาทโกลบอลเพื่อควบคุมการเข้าถึงทรัพยากร API ระดับผลิตภัณฑ์

แผนภาพ

จุดสำคัญ

• ผู้ใช้ และ แอป M2M ได้รับมอบหมายบทบาทโกลบอล (เช่น ผู้จัดการร้าน, เจ้าหน้าที่บริการ)
• บทบาทให้สิทธิ์ (ขอบเขต) เช่น read:store, order:book
• สิทธิ์เชื่อมโยงโดยตรงกับทรัพยากร API (เช่น https://read.shop/stores)

ควรใช้เมื่อใด

เมื่อการเข้าถึงไม่ขึ้นกับองค์กร หรือผู้ใช้ / ไคลเอนต์ทำงานข้ามทุกองค์กร

บันทึก:

Logto ไม่รองรับสิทธิ์ที่ไม่ใช่ API ในระดับโกลบอล เนื่องจากสงวนไว้สำหรับขอบเขต OIDC

เคล็ดลับ:

สำหรับคู่มือการใช้งานแบบทีละขั้นตอน ดู ปกป้องทรัพยากร API ระดับโกลบอล

รูปแบบที่ 2: สิทธิ์องค์กร (ที่ไม่ใช่ API)

สถานการณ์

ควบคุมฟีเจอร์หรือเวิร์กโฟลว์ในแอปที่ไม่ได้บังคับใช้ที่ชั้น API (เช่น การจำกัดฟีเจอร์ UI, dashboard หรือเครื่องมือภายใน) โดยใช้บทบาทและสิทธิ์ขององค์กร

แผนภาพ

จุดสำคัญ

• แต่ละองค์กร (A และ B) มีการกำหนดของตัวเอง แต่ทุกองค์กรใช้ชุดบทบาทร่วมกันที่กำหนดใน เทมเพลตองค์กร
• ผู้ใช้ และ แอป M2M สามารถมีบทบาทต่างกันในแต่ละองค์กร
• บทบาทองค์กร (เช่น Admin, Member) ให้สิทธิ์องค์กร เช่น invite:member, manage:billing
• สิทธิ์ถูกบังคับใช้ใน UI หรือ business logic ของแอป ไม่ใช่ที่ API gateway

ควรใช้เมื่อใด

เมื่อคุณต้องการควบคุมว่าใครเห็นหรือใช้ฟีเจอร์ในองค์กร โดยไม่ต้องบังคับใช้ที่ระดับ API

เคล็ดลับ:

สำหรับคู่มือการใช้งานแบบทีละขั้นตอน ดู ปกป้องสิทธิ์องค์กร (ที่ไม่ใช่ API)

รูปแบบที่ 3: ทรัพยากร API ระดับองค์กร

สถานการณ์

แพลตฟอร์ม SaaS แบบหลายผู้เช่าที่แต่ละองค์กรมีสมาชิก ข้อมูล และบทบาทของตัวเอง
ใช้ บทบาทองค์กร เพื่อให้สิทธิ์เข้าถึง API ภายในแต่ละองค์กร

แผนภาพ

จุดสำคัญ

• แต่ละองค์กร (A และ B) มีการกำหนดของตัวเอง แต่ทุกองค์กรใช้ชุดบทบาทร่วมกันที่กำหนดใน เทมเพลตองค์กร
• ผู้ใช้ และ แอป M2M สามารถมีบทบาทต่างกันในแต่ละองค์กร
• สิทธิ์ (ขอบเขต) เช่น invite:member, manage:billing เชื่อมโยงกับทรัพยากร API
• สิทธิ์ถูกบังคับใช้ที่ระดับ API เมื่อโทเค็นการเข้าถึงมีบริบทองค์กร

ควรใช้เมื่อใด

เมื่อคุณต้องการควบคุมการเข้าถึง API ตามบริบทขององค์กร เช่น อนุญาตให้ผู้ใช้จัดการข้อมูลขององค์กรตนเอง

เคล็ดลับ:

สำหรับคู่มือการใช้งานแบบทีละขั้นตอน ดู ปกป้องทรัพยากร API ระดับองค์กร

ออกแบบและใช้งานโมเดลสิทธิ์

ตามสถาปัตยกรรมและความต้องการของผู้ใช้ในผลิตภัณฑ์ของคุณ คุณสามารถเลือกโมเดล RBAC ที่เหมาะสมจากตัวอย่างข้างต้น นี่คือ cheat sheet สำหรับช่วยออกแบบและใช้งานโมเดลสิทธิ์ของคุณอย่างมีประสิทธิภาพ:

โมเดลสิทธิ์	กำหนดทรัพยากร API พร้อมสิทธิ์หรือไม่	กำหนดสิทธิ์องค์กรหรือไม่	ใช้บทบาทโกลบอลหรือไม่	ใช้บทบาทองค์กรหรือไม่
ทรัพยากร API ระดับโกลบอล	✅	n/a	✅	n/a
สิทธิ์องค์กร (ที่ไม่ใช่ API)	n/a	✅	n/a	✅
ทรัพยากร API ระดับองค์กร	✅	n/a	n/a	✅

กำหนดทรัพยากร API พร้อมสิทธิ์

ลงทะเบียน API ของคุณใน Logto Console หรือ ผ่าน Management API เพื่อกำหนดทรัพยากร API และสิทธิ์ (ขอบเขต) ของแต่ละ API

บันทึก:

ใน OAuth 2.0 และ OIDC “ทรัพยากร API” เรียกทางเทคนิคว่า resource indicator คือ URI ที่ไม่ซ้ำกันสำหรับระบุ API หรือบริการที่ได้รับการปกป้องของคุณ

ลงทะเบียนทรัพยากร API พร้อมสิทธิ์ใน Logto Console

1. ไปที่ Console → API resources
2. คลิก Create API resource
3. กรอกข้อมูล:
   • ชื่อ API: ชื่อที่อ่านเข้าใจง่ายสำหรับ API ของคุณ
   • ตัวระบุ API: ตัวบ่งชี้ทรัพยากร API (เช่น https://api.yourapp.com/org)
4. ในแท็บ Permissions คลิก Create permission เพื่อสร้างสิทธิ์ (ขอบเขต) สำหรับทรัพยากร API นี้
5. ในแท็บ General คุณสามารถตั้งค่าต่อไปนี้เพิ่มเติมได้:
   • เวลาหมดอายุของโทเค็น: กำหนดอายุโทเค็นการเข้าถึงสำหรับ API นี้ แนะนำให้ตั้งค่าสั้น (เช่น 1 ชั่วโมง) เพื่อความปลอดภัย
   • API เริ่มต้น: กำหนดให้ทรัพยากร API นี้เป็นค่าเริ่มต้นสำหรับ audience-restriction และการออกโทเค็นหากไม่มีการระบุ resource ใน OAuth request ตัวเลือกนี้เหมาะสำหรับไคลเอนต์ที่ไม่รองรับพารามิเตอร์ resource (เช่น third-party tools หรือปลั๊กอินบางตัว)

เคล็ดลับ

• แมปตัวบ่งชี้ทรัพยากร API กับ endpoint จริงเพื่อให้ชื่อเข้าใจง่าย
  • เช่น https://api.example.com/v1/users
• ใช้ชื่อที่ชัดเจนและอิงการกระทำ (เช่น invite:member, manage:billing, view:analytics)
  • หรือบางแนวอาจใช้ prefix หรือจัดกลุ่มตามฟีเจอร์เพื่อความชัดเจน (เช่น billing:read, billing:manage)
• กำหนดสิทธิ์ตามธุรกิจ ไม่ใช่แค่ endpoint ทางเทคนิค

ตัวอย่าง

ตัวบ่งชี้ทรัพยากร API	สิทธิ์	คำอธิบาย
https://api.example.com/users	invite:user	เชิญผู้ใช้ใหม่
https://api.example.com/users	manage:user	อัปเดตหรือลบผู้ใช้
https://api.example.com/billing	view:billing	ดูรายละเอียดการเรียกเก็บเงิน
https://api.example.com/billing	manage:billing	แก้ไขการตั้งค่าการเรียกเก็บเงิน

กำหนดสิทธิ์องค์กร

ลงทะเบียนสิทธิ์องค์กรใน Logto Console หรือ ผ่าน Management API เพื่อกำหนดสิทธิ์ที่ใช้ภายในแต่ละองค์กร สิทธิ์องค์กรจะถูกกำหนดใน เทมเพลตองค์กร

ลงทะเบียนสิทธิ์องค์กรใน Logto Console

1. ไปที่ Console → Organization template → Organization permissions
2. คลิก Create organization permission
3. กรอกข้อมูล:
   • ชื่อสิทธิ์: ชื่อที่ชัดเจนและอิงการกระทำ (เช่น invite:member, manage:billing)
   • คำอธิบาย: คำอธิบายสั้น ๆ ว่าสิทธิ์นี้อนุญาตอะไร (เช่น "เชิญสมาชิกใหม่เข้าสู่องค์กร")
4. คลิก Create permission เพื่อบันทึก

เคล็ดลับ

• ใช้ชื่อที่ชัดเจนและอิงการกระทำ (เช่น invite:member, manage:billing)
• แยกสิทธิ์องค์กรออกจากสิทธิ์ API เพื่อป้องกันความสับสน

ตัวอย่าง

สิทธิ์องค์กร	คำอธิบาย
invite:member	เชิญสมาชิกใหม่เข้าสู่องค์กร
manage:billing	แก้ไขการตั้งค่าการเรียกเก็บเงินขององค์กร

กำหนดบทบาทโกลบอล

สร้างและกำหนดค่าบทบาทโกลบอลใน Logto Console หรือ ผ่าน Management API เพื่อจัดกลุ่มสิทธิ์ที่ใช้ข้าม Logto tenant ทั้งหมด

บทบาทโกลบอลสามารถเป็นอย่างใดอย่างหนึ่งต่อไปนี้:

• บทบาทผู้ใช้: กำหนดให้ผู้ใช้ปลายทาง ให้สิทธิ์เข้าถึง API และฟีเจอร์
• บทบาทเครื่องต่อเครื่อง (M2M): กำหนดให้แอป M2M ให้สิทธิ์เข้าถึง API และฟีเจอร์ รวมถึง Logto Management API

บันทึก:

โปรดทราบว่าบทบาทสองประเภทนี้ไม่สามารถผสมหรืออัปเดตหลังจากสร้างแล้ว ให้กำหนดผู้ใช้หรือแอป M2M ให้กับบทบาทตามประเภท

สร้างบทบาทโกลบอลใน Logto Console

1. ไปที่ Console → Roles
2. คลิก Create role
3. กรอกข้อมูล:
   • ชื่อบทบาท: ชื่อที่ชัดเจนและอธิบายได้ (เช่น admin, viewer, billing-manager)
   • ประเภทบทบาท: เลือก User หรือ Machine-to-machine (M2M) เฉพาะบทบาท M2M เท่านั้นที่เชื่อมกับ Logto Management API ได้
   • คำอธิบาย: คำอธิบายสั้น ๆ เกี่ยวกับวัตถุประสงค์ของบทบาท (เช่น "บทบาทผู้ดูแลระบบเข้าถึงได้เต็มที่", "บทบาทผู้ชมสำหรับอ่านอย่างเดียว")
   • กำหนดสิทธิ์: เลือกสิทธิ์ (ขอบเขต) ที่บทบาทนี้ควรมีจากทรัพยากร API ที่มีอยู่ คุณสามารถอัปเดตสิทธิ์ได้ภายหลัง
4. คลิก Create role เพื่อบันทึก

กำหนดผู้ใช้หรือแอป M2M ให้กับบทบาทโกลบอล

1. ไปที่ Console → Roles
2. คลิกบทบาทที่ต้องการกำหนดผู้ใช้หรือแอป M2M
3. สำหรับ User roles คลิกแท็บ Users สำหรับ M2M roles คลิกแท็บ machine-to-machine apps
4. คลิก Assign users หรือ Assign M2M apps
5. ค้นหาผู้ใช้หรือแอป M2M ที่ต้องการกำหนดให้บทบาทนี้
6. เลือกผู้ใช้หรือแอป M2M แล้วคลิก Assign

บทบาทโกลบอลเริ่มต้น

คุณสามารถตั้งค่าบทบาทโกลบอลหนึ่งหรือหลายบทบาทเป็น บทบาทเริ่มต้น สำหรับผู้ใช้ใหม่ บทบาทเริ่มต้นจะถูกกำหนดให้อัตโนมัติเมื่อผู้ใช้ถูกสร้าง ไม่ว่าจะเป็นการสมัครด้วยตนเองหรือผ่าน Management API คุณสามารถเปิด toggle นี้ได้ที่แท็บ “General” ในหน้ารายละเอียด Console > Roles

กำหนดบทบาทองค์กร

สร้างบทบาทองค์กรใน Logto Console หรือ ผ่าน Management API เพื่อจัดกลุ่มสิทธิ์ที่ใช้ภายในแต่ละองค์กร บทบาทองค์กรจะถูกกำหนดใน เทมเพลตองค์กร

บทบาทองค์กรสามารถเป็นอย่างใดอย่างหนึ่งต่อไปนี้:

• บทบาทผู้ใช้: กำหนดให้ผู้ใช้ปลายทางในองค์กร ให้สิทธิ์เข้าถึง API และฟีเจอร์
• บทบาทเครื่องต่อเครื่อง (M2M): กำหนดให้แอป M2M ในองค์กร ให้สิทธิ์เข้าถึง API และฟีเจอร์ บทบาทนี้ ไม่สามารถ เชื่อมกับ Logto Management API ได้เนื่องจากเป็นแบบองค์กร

บันทึก:

โปรดทราบว่าบทบาทสองประเภทนี้ไม่สามารถผสมหรืออัปเดตหลังจากสร้างแล้ว ให้กำหนดผู้ใช้หรือแอป M2M ให้กับบทบาทตามประเภท

สร้างบทบาทองค์กรใน Logto Console

1. ไปที่ Console → Organization template → Organization roles
2. คลิก Create organization role
3. กรอกข้อมูล:
   • ชื่อบทบาท: ชื่อที่ชัดเจนและอธิบายได้ (เช่น admin, member, billing-manager)
   • ประเภทบทบาท: เลือก User หรือ Machine-to-machine (M2M) เฉพาะบทบาท M2M เท่านั้นที่เชื่อมกับ Logto Management API ได้
   • คำอธิบาย: คำอธิบายสั้น ๆ เกี่ยวกับวัตถุประสงค์ของบทบาท (เช่น "บทบาทผู้ดูแลระบบเข้าถึงได้เต็มที่", "บทบาทสมาชิกสำหรับเข้าถึงพื้นฐาน")
4. คลิก Create role เพื่อบันทึก
5. ใน modal Assign permissions เลือกสิทธิ์องค์กรและ / หรือสิทธิ์ทรัพยากร API ที่บทบาทนี้ควรมี คุณสามารถอัปเดตสิทธิ์ได้ภายหลัง

กำหนดผู้ใช้หรือแอป M2M ให้กับบทบาทองค์กร

เนื่องจากบทบาทองค์กรเป็นแบบองค์กร คุณต้องกำหนดผู้ใช้หรือแอป M2M ให้กับบทบาทองค์กรในบริบทขององค์กร

1. ไปที่ Console → Organizations
2. เลือกองค์กรที่ต้องการจัดการ
3. สำหรับ User roles คลิกแท็บ Users สำหรับ M2M roles คลิกแท็บ machine-to-machine apps
4. หากผู้ใช้หรือแอป M2M ยังไม่เป็นสมาชิกขององค์กร คลิก Add member หรือ Add M2M app เพื่อเพิ่มเข้าองค์กร ในขั้นตอนนี้คุณสามารถกำหนดบทบาทองค์กรให้พวกเขาได้
5. หากผู้ใช้หรือแอป M2M เป็นสมาชิกอยู่แล้ว คลิกเมนูสามจุดข้างชื่อแล้วเลือก Edit organization roles
6. ใน modal ที่เปิดขึ้น เลือกและบันทึกบทบาทองค์กรที่ต้องการกำหนดให้ผู้ใช้หรือแอป M2M

การจัดเตรียมแบบ Just-in-time (JIT)

คุณยังสามารถกำหนดบทบาทองค์กรให้กับผู้ใช้หรือแอป M2M ขณะที่พวกเขาเข้าร่วมองค์กรได้ ดูรายละเอียดที่ การจัดเตรียมแบบ Just-in-time (JIT)

บังคับใช้การอนุญาตใน backend หรือ API ของคุณ

Logto ออก JSON Web Tokens (JWTs) ที่มีการอ้างสิทธิ์ (Claims) ที่จำเป็นสำหรับบังคับใช้การอนุญาตในแอปหรือ API ของคุณ

เพื่อบังคับใช้การอนุญาต backend หรือ API ของคุณควร:

1. กำหนดให้ไคลเอนต์ส่งโทเค็นการเข้าถึงที่ถูกต้องใน header ของ request ด้วยรูปแบบ Authorization: Bearer <token>
2. ตรวจสอบโทเค็นการเข้าถึงเพื่อให้แน่ใจว่าออกโดย Logto, ไม่หมดอายุ และมีสิทธิ์ (ขอบเขต) ที่จำเป็นสำหรับการกระทำที่ร้องขอ
3. ตอบกลับด้วย error (เช่น HTTP 401 Unauthorized หรือ HTTP 403 Forbidden) หากไม่มีโทเค็น โทเค็นไม่ถูกต้อง หรือไม่มีสิทธิ์ที่จำเป็น

สำหรับคู่มือแบบทีละขั้นตอนและเฉพาะภาษา ดู วิธีตรวจสอบโทเค็นการเข้าถึง

ผสาน Logto RBAC กับแอปของคุณ

คุณสามารถผสาน Logto RBAC เข้ากับแอปของคุณได้สองวิธี:

• Logto SDKs: ใช้ Logto SDK เพื่อจัดการ flow การยืนยันตัวตนและการอนุญาตในตัว
• ไลบรารี OAuth 2.0 / OIDC มาตรฐาน: ใช้ไลบรารี OAuth 2.0 หรือ OpenID Connect ที่คุณชื่นชอบเพื่อ implement flow ที่จำเป็น

เมื่อผสานแล้ว ให้ร้องขอโทเค็นการเข้าถึงด้วยพารามิเตอร์ที่เหมาะสมกับโมเดล RBAC ที่เลือก และเพิ่มโทเค็นการเข้าถึงใน header Authorization ของ request API เพื่อบังคับใช้สิทธิ์

ดูตัวอย่างแบบทีละขั้นตอนในแต่ละโมเดลด้านบน

กรณีการใช้งานขั้นสูง

สำรวจกรณีการใช้งาน RBAC ที่ซับซ้อนยิ่งขึ้นใน Logto:

• ผสมบทบาทโกลบอลและองค์กร: กำหนดทั้งสองให้กับผู้ใช้ / ไคลเอนต์เมื่อจำเป็น Logto จะ resolve ตาม context ของโทเค็นที่ร้องขอ
• หลายแอป: ใช้ทรัพยากรและขอบเขตร่วมกันสำหรับ RBAC ข้ามแอป
• สิทธิ์แบบไดนามิก: หากจำเป็น ผสม RBAC กับการตรวจสอบขณะ runtime (เช่น ความเป็นเจ้าของ, attribute) สำหรับกรณีขั้นสูง
• การอ้างสิทธิ์โทเค็นแบบกำหนดเอง: ใช้ custom claims เพื่อ enrich โทเค็นตามต้องการ

แนวปฏิบัติที่ดีที่สุด & ข้อควรระวัง

• หลักการสิทธิ์น้อยที่สุด: ให้เฉพาะสิทธิ์ที่แต่ละบทบาทต้องการเท่านั้น
• หลีกเลี่ยงการกระจายสิทธิ์: ทำให้โมเดลสิทธิ์ของคุณเรียบง่ายและดูแลรักษาง่าย
• ทบทวนและอัปเดตบทบาท / สิทธิ์: ตรวจสอบ RBAC model ของคุณเป็นประจำเมื่อผลิตภัณฑ์พัฒนา
• แยกหน้าที่: สร้างบทบาทแยกสำหรับการกระทำที่สำคัญ / ผู้ดูแลระบบ
• ทดสอบ RBAC ใน staging: ตรวจสอบขอบเขตและการยกระดับสิทธิ์

คำถามที่พบบ่อย

ฉันจะอัปเดตบทบาทหรือสิทธิ์ข้ามทุกองค์กรได้อย่างไร?

อัปเดต เทมเพลตองค์กร สำหรับการเปลี่ยนแปลงระดับโกลบอล องค์กรที่มีอยู่จะรับการอัปเดต

สามารถเปลี่ยนบทบาท / สิทธิ์แบบไดนามิกได้หรือไม่?

ได้ บทบาทและสิทธิ์สามารถอัปเดตได้ตลอดเวลา

จะเกิดอะไรขึ้นถ้าฉันลบสิทธิ์ออกจากบทบาท?

ผู้ใช้ / ไคลเอนต์ที่มีบทบาทนั้นจะสูญเสียสิทธิ์ทันทีสำหรับโทเค็นใหม่

ฉันจะตรวจสอบว่าใครมีบทบาทอะไรได้อย่างไร?

ใช้ Logto Console หรือ API เพื่อดูรายการการกำหนดบทบาท

สามารถกำหนดบทบาทและสิทธิ์ผ่าน API ได้หรือไม่?

ได้ ทั้ง Console และ Management API รองรับการจัดการบทบาทและการกำหนดแบบโปรแกรม

อ่านเพิ่มเติม

เทมเพลตองค์กร ปรับแต่งการอ้างสิทธิ์ในโทเค็น วิธีตรวจสอบโทเค็นการเข้าถึง ปกป้องทรัพยากร API ระดับโกลบอล ปกป้องสิทธิ์องค์กร (ที่ไม่ใช่ API) ปกป้องทรัพยากร API ระดับองค์กร