ข้ามไปยังเนื้อหาหลัก

ปกป้องสิทธิ์ขององค์กร (ที่ไม่ใช่ API)

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

สิทธิ์ขององค์กร (ที่ไม่ใช่ API) คืออะไร?​

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

ตัวอย่างการใช้งาน เช่น

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

Logto ช่วยให้คุณรักษาความปลอดภัยสิทธิ์ขององค์กรเหล่านี้โดยใช้ OAuth 2.1 และ RBAC พร้อมรองรับสถาปัตยกรรม SaaS แบบหลายผู้เช่า

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

วิธีการทำงานใน Logto​

  • RBAC ระดับองค์กร: บทบาทและสิทธิ์ถูกกำหนดในเทมเพลตองค์กร เมื่อผู้ใช้เข้าร่วมองค์กร จะได้รับบทบาทหนึ่งหรือมากกว่าเพื่อรับสิทธิ์ที่กำหนด
  • การบังคับใช้ที่ไม่ใช่ API: การตรวจสอบสิทธิ์จะเกิดขึ้นใน UI ของแอป เวิร์กโฟลว์ หรือ logic ฝั่ง backend ของคุณ ไม่จำเป็นต้องผ่าน API gateway
  • แยกจากการปกป้อง API: สิทธิ์ขององค์กร (ที่ไม่ใช่ API) จะแตกต่างจากสิทธิ์ของทรัพยากร API คุณสามารถผสมผสานทั้งสองแบบสำหรับกรณีการใช้งานขั้นสูง
Organization permissions RBAC

ภาพรวมการนำไปใช้​

  1. กำหนดสิทธิ์ขององค์กร ใน Logto ภายใต้เทมเพลตองค์กร
  2. สร้างบทบาทขององค์กร ที่รวมสิทธิ์ที่จำเป็นสำหรับการดำเนินการเฉพาะขององค์กร
  3. กำหนดบทบาท ให้กับผู้ใช้หรือ client ในแต่ละองค์กร
  4. ขอโทเค็นองค์กร (JWT) สำหรับองค์กรปัจจุบันโดยใช้ refresh token หรือ client credentials flow
  5. ตรวจสอบ access token ใน UI หรือ backend ของแอปเพื่อบังคับใช้สิทธิ์ขององค์กร

กระบวนการอนุญาต: การยืนยันตัวตนและปกป้องสิทธิ์ขององค์กร​

แผนภาพต่อไปนี้แสดงวิธีที่ client (เว็บ, มือถือ, หรือ backend) ขอและใช้โทเค็นองค์กรเพื่อบังคับใช้สิทธิ์ที่ไม่ใช่ API

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

การยืนยันตัวตนของผู้ใช้ = เบราว์เซอร์/แอป M2M = บริการ backend หรือ script ที่ใช้ client credentials + บริบทองค์กร

ขั้นตอนการนำไปใช้​

ลงทะเบียนสิทธิ์ขององค์กร​

  1. ไปที่ Console → เทมเพลตองค์กร → สิทธิ์ขององค์กร
  2. กำหนดสิทธิ์ขององค์กรที่คุณต้องการ (เช่น invite:member, manage:billing, view:analytics)

สำหรับขั้นตอนการตั้งค่าแบบเต็ม ดู กำหนดสิทธิ์ขององค์กร

ตั้งค่าบทบาทขององค์กร​

  1. ไปที่ Console → เทมเพลตองค์กร → บทบาทขององค์กร
  2. สร้างบทบาทที่รวมสิทธิ์ขององค์กรที่คุณกำหนดไว้ก่อนหน้า (เช่น admin, member, billing)
  3. กำหนดบทบาทเหล่านี้ให้กับผู้ใช้หรือ client ในแต่ละองค์กร

สำหรับขั้นตอนการตั้งค่าแบบเต็ม ดู ใช้บทบาทขององค์กร

ขอรับโทเค็นองค์กร (ที่ไม่ใช่ API)​

client/แอปของคุณควรขอโทเค็นองค์กร (ที่ไม่ใช่ API) เพื่อเข้าถึงสิทธิ์ขององค์กร Logto จะออกโทเค็นองค์กรเป็น JSON Web Tokens (JWTs) คุณสามารถขอโทเค็นเหล่านี้ได้โดยใช้ refresh token flow หรือ client credentials flow

Refresh token flow​

เกือบทุก SDK อย่างเป็นทางการของ Logto รองรับการขอโทเค็นองค์กรโดยใช้ refresh token flow ได้ทันที ไลบรารี client มาตรฐาน OAuth 2.0 / OIDC ก็สามารถนำไปใช้ได้เช่นกัน

เมื่อเริ่มต้น Logto SDK ให้เพิ่ม urn:logto:scope:organizations และสิทธิ์ขององค์กรที่ต้องการ (scopes) ลงในพารามิเตอร์ scopes

บาง SDK ของ Logto มี scope สำหรับองค์กรที่กำหนดไว้ล่วงหน้า เช่น UserScope.Organizations ใน JavaScript SDK

บันทึก:

ตรวจสอบ organizations การอ้างสิทธิ์ (claim) ในโทเค็น ID (ID token) เพื่อรับรายการรหัสองค์กรที่ผู้ใช้สังกัด การอ้างสิทธิ์นี้จะแสดงรายการองค์กรทั้งหมดที่ผู้ใช้เป็นสมาชิก ทำให้ง่ายต่อการแสดงหรือสลับองค์กรในแอปของคุณ

ใช้ getOrganizationToken หรือเมธอดที่คล้ายกัน (เช่น getAccessToken พร้อม organization ID) เพื่อขอโทเค็นองค์กรสำหรับองค์กรที่ต้องการ

สำหรับรายละเอียดของแต่ละ SDK ดู Quick starts

Client credentials flow​

สำหรับกรณีเครื่องต่อเครื่อง (M2M) คุณสามารถใช้ client credentials flow เพื่อขอ access token สำหรับสิทธิ์ขององค์กร โดยส่ง POST request ไปที่ endpoint /oidc/token ของ Logto พร้อมพารามิเตอร์องค์กร คุณสามารถขอโทเค็นองค์กรโดยใช้ client ID และ secret ของคุณ

พารามิเตอร์สำคัญที่ต้องใส่ใน request:

  • organization_id: ID ขององค์กรที่ต้องการโทเค็น
  • scope: สิทธิ์ขององค์กรที่ต้องการ (เช่น invite:member, manage:billing)

ตัวอย่างที่ไม่เป็นทางการของ token request โดยใช้ client credentials grant type:

POST /oidc/token HTTP/1.1
Host: your.logto.endpoint
Content-Type: application/x-www-form-urlencoded
Authorization: Basic base64(client_id:client_secret)

grant_type=client_credentials
&organization_id=your-organization-id
&scope=invite:member manage:billing

ตรวจสอบโทเค็นองค์กร​

โทเค็นองค์กร (JWTs) ที่ออกโดย Logto จะมีการอ้างสิทธิ์ (claims) ที่แอป/UI/backend ของคุณสามารถใช้เพื่อบังคับใช้การควบคุมการเข้าถึงในระดับองค์กร

เมื่อแอปของคุณได้รับโทเค็นองค์กร คุณควร:

  • ตรวจสอบลายเซ็นของโทเค็น (โดยใช้ JWKs ของ Logto)
  • ยืนยันว่าโทเค็นไม่หมดอายุ (exp claim)
  • ตรวจสอบว่า iss (ผู้ออก) ตรงกับ endpoint Logto ของคุณ
  • ตรวจสอบว่า aud (ผู้รับ) ตรงกับตัวระบุองค์กรที่ฟอร์แมตไว้ (เช่น urn:logto:organization:{organization_id})
  • แยก claim scope (คั่นด้วยช่องว่าง) และตรวจสอบสิทธิ์ที่ต้องการ

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

Optional: Handle user permission change​

User permissions can change at any time. Because Logto issues JWTs for RBAC, permission updates only appear in newly issued tokens, and never modify existing JWTs.

Scope subset rule:

An access token can only include scopes that were requested in the original OAuth authorization flow. Even if a user gains new permissions, the token issued later can only contain a subset of the originally requested scopes. To access newly granted scopes that were not part of the initial request, the client must run a new authorization flow.

Downscoped permissions​

When a user loses permissions:

  • Newly issued tokens immediately reflect the reduced scopes.
  • Existing JWTs keep the old scopes until they expire.
  • Your API should always validate scopes and rely on short token lifetimes.

If you need faster reactions, implement your own signal that tells clients to refresh their tokens.

Enlarged permissions​

For organization tokens, when a user gains permissions, enlarged permissions will show up on the next issuance (refresh or token request). A new token is still required, but no full re-auth is needed unless the new scopes exceed the original request set.

Recommendations​

  • Validate scopes in your API on every call.
  • Keep token expiration short.
  • Add optional notifications if you need immediate permission-change propagation.

แนวปฏิบัติที่ดีและเคล็ดลับด้านความปลอดภัย​

  • อย่าอาศัยการบังคับใช้เฉพาะ UI: ควรตรวจสอบสิทธิ์ใน backend สำหรับการดำเนินการสำคัญเสมอ
  • ใช้ข้อจำกัดผู้รับ (audience restriction): ตรวจสอบ claim aud เสมอเพื่อให้แน่ใจว่าโทเค็นสำหรับองค์กรที่ต้องการ
  • ตั้งชื่อสิทธิ์ให้สอดคล้องกับธุรกิจ: ใช้ชื่อที่ชัดเจนและตรงกับการกระทำจริง กำหนดเฉพาะสิทธิ์ที่จำเป็นสำหรับแต่ละบทบาทองค์กร
  • แยกสิทธิ์ API และที่ไม่ใช่ API เมื่อเป็นไปได้ (แต่สามารถอยู่ในบทบาทเดียวกันได้)
  • ทบทวนเทมเพลตองค์กรเป็นประจำ เมื่อผลิตภัณฑ์ของคุณพัฒนา

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

สามารถผสมสิทธิ์ขององค์กรและที่ไม่ใช่องค์กรในบทบาทเดียวกันได้หรือไม่?​

ไม่ได้ สิทธิ์ขององค์กร (รวมถึงสิทธิ์ API ระดับองค์กร) ถูกกำหนดโดยเทมเพลตองค์กรและไม่สามารถผสมกับสิทธิ์ API ระดับโกลบอลได้ อย่างไรก็ตาม คุณสามารถสร้างบทบาทที่มีทั้งสิทธิ์ขององค์กรและสิทธิ์ API ระดับองค์กรได้

ควรบังคับใช้สิทธิ์ที่ไม่ใช่ API ที่ไหน?​

ตรวจสอบสิทธิ์ที่ไม่ใช่ API ทั้งใน UI (สำหรับการจำกัดฟีเจอร์) และใน logic ฝั่ง server สำหรับการดำเนินการที่สำคัญ

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

วิธีตรวจสอบ access token การปรับแต่ง token claims

กรณีศึกษา: สร้างแอป SaaS แบบหลายผู้เช่า