แอปไดนามิก (CIMD)

แอปไดนามิกช่วยให้ OAuth client เชื่อมต่อกับ tenant ของคุณได้โดยไม่ต้องลงทะเบียนล่วงหน้า แทนที่จะใช้ client ID ที่ออกโดย Logto, client จะใช้ URL สาธารณะแบบ HTTPS เป็น client_id URL นี้จะให้บริการเอกสาร JSON ที่อธิบาย client ซึ่งเรียกว่า client ID metadata document (CIMD) Logto จะดึงเอกสารนี้และปฏิบัติต่อ client เหมือนเป็น แอปพลิเคชันบุคคลที่สาม

แอปไดนามิกนี้อิงตาม IETF draft OAuth Client ID Metadata Document

เมื่อใดควรใช้แอปไดนามิก

การลงทะเบียนล่วงหน้าจะใช้ได้เมื่อคุณรู้จักพาร์ทเนอร์ของคุณ แต่จะใช้ไม่ได้เมื่อ client ใด ๆ อาจเชื่อมต่อเข้ามา ซึ่งเป็นเรื่องปกติในระบบนิเวศ Model Context Protocol (MCP): ผู้ใช้ขอให้ AI agent ของตนเชื่อมต่อกับบริการของคุณ และ agent นั้นไม่เคยติดต่อกับ tenant ของคุณมาก่อน

ด้วยแอปไดนามิก client จะเผยแพร่ metadata ของตนเองที่ URL ที่ตนเป็นเจ้าของ และ URL นั้นคืออัตลักษณ์ของมัน โดยไม่ต้องสร้างอะไรใน tenant ของคุณล่วงหน้า

	แอปบุคคลที่สามที่ลงทะเบียนไว้	แอปไดนามิก
Client ID	ออกโดย Logto	URL แบบ HTTPS ที่ client เป็นเจ้าของ
การลงทะเบียน	จำเป็นต้องลงทะเบียน	ไม่จำเป็นต้องลงทะเบียน
Client secret	รองรับ	ไม่รองรับ
สิทธิ์	ต่อแอปพลิเคชัน	ใช้ร่วมกันโดย client ไดนามิกทั้งหมด
Grant types	ขึ้นกับประเภทแอป	`authorization_code` และ `refresh_token`

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

เปิดใช้งานแอปไดนามิก

ไปที่ Console > Applications และเปิดแท็บ Third-party apps
คลิก Create application และเลือกการ์ด Dynamic app ซึ่งจะเปิดใช้ฟีเจอร์ระดับ tenant แทนที่จะสร้างแอปพลิเคชัน
ยืนยันใน dialog เมื่อเปิดใช้งานแล้ว OAuth client ใด ๆ ที่มี client ID URL แบบ HTTPS สาธารณะที่ถูกต้องสามารถเริ่มคำขอการอนุญาตสำหรับ tenant ของคุณได้
เปิดแอปไดนามิกจากรายการแอปพลิเคชันและไปที่แท็บ Permissions เพื่อกำหนดสิทธิ์

แอปไดนามิกไม่มีชื่อ, redirect URI หรือข้อมูลรับรองที่แก้ไขได้ แต่ละ client จะระบุข้อมูลเหล่านี้ใน metadata document ของตนเอง

บันทึก:

แอปไดนามิกต้องการ การป้องกัน SSRF ของ OIDC provider เนื่องจาก Logto จะดึง metadata document จากอินเทอร์เน็ต อินสแตนซ์ที่โฮสต์เองและปิดฟีเจอร์นี้จะไม่สามารถเปิดใช้แอปไดนามิกได้

กำหนดสิทธิ์

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

หากร้องขอ user permission ที่ไม่ได้รับอนุญาตจะเกิดข้อผิดพลาด ขณะที่สิทธิ์ของทรัพยากร API และองค์กรที่ไม่ได้รับอนุญาตจะถูกละเลย ผู้ใช้จะยินยอมเฉพาะสิทธิ์ที่ตนมีผ่าน บทบาท (Roles) ของตน

เนื่องจาก client ไดนามิกทุกตัวใช้ชุดนี้ร่วมกัน ควรตั้งค่าให้น้อยที่สุด

เผยแพร่ client ID metadata document

หากคุณกำลังสร้าง client ที่เชื่อมต่อกับ Logto ให้โฮสต์ metadata document และใช้ URL ของมันเป็น client_id URL ต้องใช้ scheme https และต้องไม่มี fragment, user info หรือ dot path segment Logto จะส่งคำขอ GET ไปยัง URL นี้และคาดหวังว่าจะได้ JSON object

ตัวอย่างเช่น Claude Code ใช้ https://claude.ai/oauth/claude-code-client-metadata ซึ่งให้บริการ:

{
  "client_id": "https://claude.ai/oauth/claude-code-client-metadata",
  "client_name": "Claude Code",
  "client_uri": "https://claude.ai",
  "redirect_uris": ["http://localhost/callback", "http://127.0.0.1/callback"],
  "token_endpoint_auth_method": "none"
}

ชื่อฟิลด์เหมือนกับใน OAuth 2.0 Dynamic Client Registration หมายเหตุว่า:

client_id ต้องเหมือนกับ URL ที่ให้บริการเอกสารนี้
client ไดนามิกถือเป็น public client เอกสารต้องไม่มี client_secret และ token_endpoint_auth_method ต้องไม่เป็น shared-secret method ให้ใช้ PKCE แทน
URI metadata เช่น client_uri, logo_uri, tos_uri และ policy_uri ต้องเป็น URL แบบสัมบูรณ์ที่ใช้ https เสมอ ข้อนี้ไม่ใช้กับ redirect_uris ดังนั้น native client ยังสามารถใช้ loopback address ได้เหมือนตัวอย่างข้างต้น
redirect_uris จะถูกจับคู่แบบ exact string ยกเว้น loopback address ที่สามารถจับคู่กับพอร์ตใดก็ได้ Wildcard patterns ก็รองรับเช่นกัน
scope, grant_types และ response_types จะถูกกำหนดโดย Logto หากเอกสารระบุไว้ ค่าจะถูกละเลย client ไดนามิกสามารถใช้ได้เฉพาะ authorization code flow และ refresh token เท่านั้น

Logto จะ cache เอกสารนี้ได้นานสูงสุด 24 ชั่วโมง โดยอิงตาม header Cache-Control และ Expires ของ response ของคุณ กำหนดค่าเหล่านี้ตามความถี่ที่คุณคาดว่าจะอัปเดตเอกสาร

client ไดนามิกถือเป็นแอปพลิเคชันบุคคลที่สาม ดังนั้น หน้าขอความยินยอม จะแสดงเสมอ

หน้าขอความยินยอมจะแสดงข้อความแจ้งว่า client นี้ยังไม่ได้ลงทะเบียน ชื่อและโลโก้ของ client มาจาก metadata document ดังนั้นจึงสามารถเลียนแบบแบรนด์ใดก็ได้ โฮสต์ของ client ID URL จะแสดงด้วย เพราะเป็นส่วนเดียวที่ client ไม่สามารถปลอมแปลงได้

จัดการการอนุญาต (Manage authorizations)

การอนุญาตที่ให้กับ client ไดนามิกถือเป็น grant ของแอปบุคคลที่สามตามปกติ ผู้ใช้สามารถตรวจสอบและเพิกถอนสิทธิ์เหล่านี้ในหน้าตั้งค่าบัญชี และผู้ดูแลระบบสามารถจัดการผ่าน Management API โดยใช้ client ID URL เป็นตัวระบุ client

การปิดใช้งานแอปไดนามิกจะหยุดคำขอการอนุญาตใหม่ แต่ grant ที่มีอยู่จะยังคงอยู่ การเพิกถอน grant จะทำให้ client ต้องขออนุญาตจากผู้ใช้อีกครั้ง แต่ access token ที่ออกไปแล้วอาจยังใช้ได้จนกว่าจะหมดอายุ

ข้อจำกัด

รองรับเฉพาะ authorization code flow ที่ใช้ PKCE และ refresh token เท่านั้น ไม่รองรับ client credentials, device flow และ token exchange
ไม่สามารถกำหนดสิทธิ์และแบรนด์แยกตาม client ได้
การควบคุมการเข้าถึงระดับแอป ไม่ใช้กับ client ไดนามิก เพราะไม่มี record ของแอปพลิเคชัน

แอปบุคคลที่สาม (OAuth / OIDC)

เปิดให้ AI agent บุคคลที่สามเข้าถึง MCP server ของคุณ

เมื่อใดควรใช้แอปไดนามิก​

เปิดใช้งานแอปไดนามิก​

กำหนดสิทธิ์​

เผยแพร่ client ID metadata document​

หน้าขอความยินยอม (Consent screen)​

จัดการการอนุญาต (Manage authorizations)​

ข้อจำกัด​

แหล่งข้อมูลที่เกี่ยวข้อง​