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

เคล็ดลับ:

สำรวจ โซลูชัน AI ของ Logto: การยืนยันตัวตน (Authentication) และการอนุญาต (Authorization) สำหรับเซิร์ฟเวอร์ MCP, เอเจนต์ AI และแอป

คู่มือนี้จะแนะนำวิธีการผสาน Logto เข้ากับเซิร์ฟเวอร์ MCP ของคุณโดยใช้ mcp-auth และ MCP official SDK v2 เพื่อให้ AI agent บุคคลที่สามสามารถยืนยันตัวตนผู้ใช้ด้วยความยินยอมของผู้ใช้ และเข้าถึงเซิร์ฟเวอร์ MCP ของคุณได้อย่างปลอดภัย

คุณจะได้เรียนรู้วิธี:

• กำหนดค่า Logto เป็นเซิร์ฟเวอร์การอนุญาต (authorization server) สำหรับเซิร์ฟเวอร์ MCP ของคุณ
• ออนบอร์ด AI agent บุคคลที่สาม โดยการลงทะเบียนแอปบุคคลที่สาม หรือเปิดใช้ dynamic app เพื่อให้ agent ใด ๆ สามารถเชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า
• ตั้งค่าเครื่องมือ “whoami” ในเซิร์ฟเวอร์ MCP ของคุณเพื่อคืนค่าการอ้างสิทธิ์ตัวตน (identity claims) ของผู้ใช้ปัจจุบัน
• ทดสอบ flow กับ AI agent บุคคลที่สาม (MCP client)

หลังจากจบบทเรียนนี้ เซิร์ฟเวอร์ MCP ของคุณจะสามารถ:

• ยืนยันตัวตนผู้ใช้ใน Logto tenant ของคุณ พร้อมขอความยินยอมจากผู้ใช้สำหรับ AI agent บุคคลที่สาม
• ตรวจสอบ JWT โทเค็นการเข้าถึง (access token) ที่ออกโดย Logto (ลายเซ็น, ผู้ออก, ผู้รับ, และวันหมดอายุ)
• คืนค่าการอ้างสิทธิ์ตัวตนที่ตรวจสอบแล้ว (sub, iss, aud ฯลฯ) สำหรับการเรียกใช้เครื่องมือ "whoami"

ตัวอย่างโค้ด:

โค้ดตัวอย่างที่สมบูรณ์และสามารถรันได้สำหรับคู่มือนี้ สามารถดูได้ที่ repository mcp-auth/js:

• whoami-express: เซิร์ฟเวอร์ "whoami" ในคู่มือนี้ บน Node.js ด้วย Express
• whoami: เซิร์ฟเวอร์เดียวกันที่สร้างด้วย fetch-native (มาตรฐานเว็บ Request / Response กับ Hono) สามารถนำไปใช้งานบน Cloudflare Workers ได้

ความแตกต่างระหว่าง AI agent บุคคลที่สาม (MCP client) กับ MCP client ของคุณเอง

ลองดูตัวอย่างนี้ สมมติว่าคุณเป็นนักพัฒนาที่รันเซิร์ฟเวอร์ MCP เพื่อจัดการการเข้าถึงอีเมลและระบบอัตโนมัติ

แอปอีเมลทางการ (MCP client ของคุณเอง)

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

AI agent บุคคลที่สาม (MCP client บุคคลที่สาม)

• คุณกำลังสร้าง ecosystem รอบเซิร์ฟเวอร์ MCP ของคุณ นักพัฒนาคนอื่นจึงสร้าง “SmartMail AI” (ผู้ช่วย AI ที่สามารถสรุปอีเมลและนัดหมายอัตโนมัติ) โดยผสานเป็น client บุคคลที่สาม
• วิธีการทำงาน: SmartMail AI (MCP client บุคคลที่สาม) ต้องการเข้าถึงอีเมลผู้ใช้ผ่านเซิร์ฟเวอร์ MCP ของคุณ เมื่อ Alice ลงชื่อเข้าใช้ SmartMail AI ด้วยบัญชีของเธอ:
  • เธอจะเห็นหน้าขอความยินยอม (consent screen) ขออนุญาตให้ SmartMail AI อ่านอีเมลและปฏิทินของเธอ
  • Alice สามารถอนุญาตหรือปฏิเสธการเข้าถึงนี้ได้
  • เฉพาะข้อมูลที่ Alice ยินยอมเท่านั้นที่จะถูกแชร์กับ SmartMail AI และ SmartMail AI จะไม่สามารถเข้าถึงข้อมูลเพิ่มเติมได้หากไม่ได้รับความยินยอมใหม่อย่างชัดเจน

การควบคุมการเข้าถึง (permission) นี้ช่วยให้ข้อมูลผู้ใช้ปลอดภัย แม้เซิร์ฟเวอร์ MCP ของคุณจะจัดการข้อมูลทั้งหมด แต่แอปบุคคลที่สามอย่าง SmartMail AI จะเข้าถึงได้เฉพาะสิ่งที่ผู้ใช้อนุญาตอย่างชัดเจนเท่านั้น ไม่สามารถข้ามขั้นตอนนี้ได้ เพราะถูกบังคับใช้โดยการควบคุมการเข้าถึงของคุณในเซิร์ฟเวอร์ MCP

สรุป

ประเภท client	ตัวอย่าง	ต้องขอความยินยอม?	ใครควบคุม?
แอปอีเมลทางการ	แอปอีเมลของคุณเอง	ไม่	คุณ (นักพัฒนา)
AI agent บุคคลที่สาม	SmartMail AI assistant	ใช่	นักพัฒนาคนอื่น

บันทึก:

หากคุณต้องการผสานเซิร์ฟเวอร์ MCP ของคุณกับ AI agent หรือแอปของคุณเอง โปรดดูคู่มือ เปิดใช้งาน auth สำหรับแอปที่ใช้ MCP ของคุณด้วย Logto

ข้อกำหนดเบื้องต้น

• Logto Cloud (หรือแบบ self-hosted) tenant
• สภาพแวดล้อม Node.js >= 20

ทำความเข้าใจสถาปัตยกรรม

• เซิร์ฟเวอร์ MCP: เซิร์ฟเวอร์ที่เปิดเผยเครื่องมือและทรัพยากรให้กับไคลเอนต์ MCP โดยอิงตาม MCP specification ล่าสุด จะทำหน้าที่เป็น resource server ของ OAuth 2.0 ที่ตรวจสอบโทเค็นการเข้าถึง (access token) ที่ออกโดย Logto
• ไคลเอนต์ MCP: ไคลเอนต์ที่ใช้เริ่มต้น flow การยืนยันตัวตนและทดสอบการเชื่อมต่อ AI agent ของบุคคลที่สามจะถูกใช้เป็นไคลเอนต์ในคู่มือนี้
• Logto: ทำหน้าที่เป็นผู้ให้บริการ OpenID Connect (authorization server) จัดการข้อมูลระบุตัวตนของผู้ใช้ และออกโทเค็นการเข้าถึง JWT ที่ผูกกับผู้รับ (audience-bound) สำหรับเซิร์ฟเวอร์ MCP ของคุณ

ไดอะแกรมลำดับ (sequence diagram) ที่ไม่เป็นทางการนี้แสดงภาพรวมของกระบวนการทั้งหมด:

บันทึก:

เนื่องจาก MCP มีการพัฒนาอย่างรวดเร็ว ไดอะแกรมข้างต้นอาจไม่อัปเดตล่าสุดเสมอ โปรดดูเอกสาร mcp-auth สำหรับข้อมูลล่าสุด

ตั้งค่าตัวแทน AI ของบุคคลที่สามใน Logto

เพื่อให้ตัวแทน AI ของบุคคลที่สามสามารถเข้าถึง MCP server ได้ คุณต้องตั้งค่า แอปของบุคคลที่สาม ใน Logto แอปนี้จะใช้แทนตัวแทน AI และรับข้อมูลประจำตัวที่จำเป็นสำหรับการยืนยันตัวตน (การยืนยันตัวตน (Authentication)) และการอนุญาต (การอนุญาต (Authorization))

แอปของบุคคลที่สามคืออะไร?:

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

ดูเพิ่มเติมที่ แอปพลิเคชันของบุคคลที่สาม

มี 3 วิธีในการเชื่อมต่อ AI agent:

• สร้างแอปใน Console ด้วยตนเอง เหมาะสำหรับการทดสอบหรือกรณีที่มี agent ไม่กี่ตัวที่รู้จักล่วงหน้า
• สร้างบริการลงทะเบียนผ่าน Management API หากคุณต้องการควบคุมว่าใครจะได้รับข้อมูลประจำตัว
• เปิดใช้งาน dynamic app หากต้องการให้ agent ใด ๆ เชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า

อนุญาตให้นักพัฒนาสร้างแอปของบุคคลที่สามใน Logto

หากคุณกำลังสร้าง marketplace หรืออยากให้นักพัฒนาสามารถสร้างแอปของบุคคลที่สามใน Logto ได้ คุณสามารถใช้ Logto Management API เพื่อสร้างแอปของบุคคลที่สามแบบโปรแกรมมิ่ง วิธีนี้จะช่วยให้นักพัฒนาสามารถลงทะเบียนแอปพลิเคชันของตนเองและรับข้อมูลประจำตัวที่จำเป็นสำหรับการยืนยันตัวตน (การยืนยันตัวตน (Authentication))

คุณจะต้องโฮสต์บริการของคุณเองเพื่อจัดการกระบวนการลงทะเบียน client โดยบริการนี้จะติดต่อกับ Logto Management API เพื่อสร้างแอปของบุคคลที่สามแทนนักพัฒนา

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

อนุญาตให้ AI agent ใด ๆ เชื่อมต่อได้โดยไม่ต้องลงทะเบียนล่วงหน้า

ในระบบนิเวศ MCP แบบเปิด คุณมักจะไม่รู้จัก agent ล่วงหน้า Dynamic app จะตัดขั้นตอนการลงทะเบียนออก: agent จะใช้ URL HTTPS สาธารณะซึ่งให้บริการ client metadata document ของตนเองเป็น client_id และ Logto จะ resolve เมื่อมี authorization request เข้ามา

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

สร้างแอปของบุคคลที่สามใน Logto ด้วยตนเอง

คุณสามารถสร้างแอปของบุคคลที่สามใน Logto Console ด้วยตนเองเพื่อทดสอบหรือเชื่อมต่อแบบ ad-hoc วิธีนี้เหมาะสำหรับการทดสอบการเชื่อมต่ออย่างรวดเร็วโดยไม่ต้องพัฒนากระบวนการลงทะเบียน client แบบเต็มรูปแบบ

1. ลงชื่อเข้าใช้ Logto Console ของคุณ

2. ไปที่ Applications → Create application → Third-party app -> OIDC

3. กรอกชื่อแอปและข้อมูลที่จำเป็นอื่น ๆ จากนั้นคลิก Create application

4. คลิกแท็บ Permissions เพื่อกำหนด สิทธิ์ (permissions) ให้กับแอป:

   • ส่วน User: สิทธิ์ข้อมูลผู้ใช้ เช่น profile และ email สำหรับการอ้างสิทธิ์ (claims) ข้อมูลตัวตนพื้นฐาน
   • ส่วน API resource: สิทธิ์ (ขอบเขต; scopes) ของ ทรัพยากร API (API resources) ที่คุณกำหนดใน Logto เช่น ทรัพยากร API ที่แทน MCP server
   • ส่วน Organization: สิทธิ์ขององค์กร หากคุณใช้ฟีเจอร์องค์กรของ Logto

5. ในแอปของบุคคลที่สาม ให้กำหนด scopes เพื่อขอสิทธิ์ที่คุณอนุญาตไว้ เช่น openid profile email พร้อมกับ scopes ของ API resource

   หมายเหตุ: openid จำเป็นสำหรับ OIDC หากต้องการรับโทเค็นการเข้าถึง (access token) ที่ผูกกับ API resource แอปต้องใส่พารามิเตอร์ resource ใน authorization request ด้วย MCP client ที่ปฏิบัติตามสเปค MCP ล่าสุดจะทำสิ่งนี้โดยอัตโนมัติตาม metadata ของทรัพยากรที่ได้รับการปกป้อง

6. กำหนด redirect URI ของแอปของบุคคลที่สามให้ถูกต้อง และอย่าลืมอัปเดต redirect URI ใน Logto ด้วย

---

เบื้องหลังแล้ว แอปของบุคคลที่สามคือไคลเอนต์มาตรฐานของ OAuth 2.0 / OIDC ซึ่งหมายความว่าคุณ (หรือผู้พัฒนาแอปบุคคลที่สาม) สามารถใช้ไลบรารีหรือเฟรมเวิร์ก OAuth 2.0 / OIDC ใดก็ได้ในการเชื่อมต่อกับ Logto

ข้อควรคำนึงถึง:

1. เมื่อสร้างแอปบุคคลที่สาม ให้เลือกประเภทแอปพลิเคชันที่เหมาะสมตามสถาปัตยกรรมของแอป:
   • เว็บแบบดั้งเดิม: ใช้ client secret สำหรับการยืนยันตัวตน
   • Single page app / Native: ใช้ PKCE เพื่อความปลอดภัยในการอนุญาตโดยไม่ต้องใช้ client secret
2. คู่มือเริ่มต้นอย่างรวดเร็วส่วนใหญ่ของเราเขียนสำหรับแอป first-party แต่คุณยังสามารถใช้เป็นข้อมูลอ้างอิงสำหรับการเชื่อมต่อแอปบุคคลที่สามได้
3. ความแตกต่างหลักคือแอปบุคคลที่สามจะแสดงหน้าขอความยินยอม (consent screen) เพื่อขออนุญาตจากผู้ใช้ในการเข้าถึงข้อมูลของพวกเขาโดยชัดแจ้ง

ดู แอปพลิเคชันบุคคลที่สาม สำหรับคู่มือการเชื่อมต่อฉบับสมบูรณ์

ตั้งค่าเซิร์ฟเวอร์ MCP

เราจะใช้ MCP official SDK v2 และ mcp-auth เพื่อสร้างเซิร์ฟเวอร์ MCP พร้อมเครื่องมือ "whoami" ที่ส่งคืนการอ้างสิทธิ์ (claims) ของตัวตนผู้ใช้ปัจจุบัน

สร้างโปรเจกต์และติดตั้ง dependencies

mkdir mcp-server
cd mcp-server
npm init -y
npm pkg set type="module"
npm pkg set main="whoami.js"
npm pkg set scripts.start="node whoami.js"
npm install @modelcontextprotocol/server @modelcontextprotocol/express @modelcontextprotocol/node express mcp-auth

• @modelcontextprotocol/server คือ MCP SDK v2 หลัก ซึ่งใช้มาตรฐานเว็บ Request / Response
• @modelcontextprotocol/express และ @modelcontextprotocol/node ใช้สำหรับปรับให้เข้ากับ Express บน Node.js
• mcp-auth ให้ตัวตรวจสอบโทเค็นและข้อมูลเมตา OAuth discovery สำหรับ MCP SDK

บันทึก:

MCP SDK v2 และ mcp-auth รองรับเฉพาะ ESM และต้องใช้ Node.js >= 20

ลงทะเบียนเซิร์ฟเวอร์ MCP เป็นทรัพยากร API

MCP specification ล่าสุด กำหนดให้โทเค็นการเข้าถึง (Access tokens) ต้องผูกกับทรัพยากรที่ออกให้ (RFC 8707) และ mcp-auth จะบังคับใช้: การอ้างสิทธิ์ aud ของโทเค็นต้องตรงกับตัวระบุทรัพยากรของเซิร์ฟเวอร์ MCP ของคุณ ใน Logto จะทำได้โดยการสร้างทรัพยากร API ที่ตัวบ่งชี้ (indicator) ตรงกับ URL ของเซิร์ฟเวอร์ MCP ของคุณ:

1. ลงชื่อเข้าใช้ Logto Console ของคุณ
2. ไปที่ ทรัพยากร API (API resources) → สร้างทรัพยากร API (Create API resource)
3. กรอกรายละเอียด แล้วคลิก สร้างทรัพยากร API (Create API resource):
   • ชื่อ API (API name): กรอกชื่อ เช่น "Who am I"
   • ตัวระบุ API (API identifier): กรอก http://localhost:3001/ ต้องตรงกับตัวระบุทรัพยากรที่เราจะตั้งค่าในเซิร์ฟเวอร์ MCP

เครื่องหมาย / ต่อท้ายในตัวบ่งชี้ทรัพยากร:

ควรใส่เครื่องหมาย / ต่อท้าย (/) ในตัวบ่งชี้ทรัพยากรเสมอ เนื่องจากบั๊กปัจจุบันใน MCP SDK อย่างเป็นทางการ ไคลเอนต์ที่ใช้ SDK จะเติม / ต่อท้ายตัวระบุทรัพยากรโดยอัตโนมัติเมื่อเริ่มต้นคำขอ auth หากตัวบ่งชี้ทรัพยากรของคุณไม่มี / ต่อท้าย การตรวจสอบทรัพยากรจะล้มเหลวสำหรับไคลเอนต์เหล่านั้น

ตั้งค่า MCP Auth กับ Logto

ประกาศเซิร์ฟเวอร์ MCP ของคุณเป็นทรัพยากรที่ได้รับการป้องกัน: ตัวระบุทรัพยากรและเซิร์ฟเวอร์การอนุญาตที่เชื่อถือ จำไว้ว่าต้องแทนที่ <your-logto-issuer-endpoint> ด้วย endpoint ของผู้ออก (issuer) ที่คุณคัดลอกมาก่อนหน้านี้ (ดูได้ในหน้าแอปพลิเคชันที่ Endpoints & Credentials เช่น https://my-project.logto.app/oidc)

ใน whoami.js:

import { MCPAuth } from 'mcp-auth';

const authIssuer = '<your-logto-issuer-endpoint>';

const mcpAuth = new MCPAuth({
  protectedResourceMetadata: {
    // ตัวระบุทรัพยากร; ต้องตรงกับตัวบ่งชี้ทรัพยากร API ที่ลงทะเบียนใน Logto
    resource: 'http://localhost:3001/',
    // เซิร์ฟเวอร์การอนุญาตที่เซิร์ฟเวอร์ MCP นี้เชื่อถือ
    authorizationServer: { issuer: authIssuer, type: 'oidc' },
  },
});

ข้อมูลเมตาของเซิร์ฟเวอร์การอนุญาตจะถูกดึงมาแบบ lazy เมื่อถูกเรียกใช้ครั้งแรกและแคชไว้หลังจากนั้น อินสแตนซ์ MCPAuth จะตรวจสอบโทเค็นการเข้าถึง JWT กับ JWKS ของ Logto — ทั้งลายเซ็น, ผู้ออก, ผู้รับ, และวันหมดอายุถูกบังคับใช้ทั้งหมด ไม่ต้องเขียนโค้ดตรวจสอบโทเค็นเอง

สร้างเครื่องมือ "whoami"

ต่อไป มาสร้างเครื่องมือ "whoami" ที่ส่งคืนการอ้างสิทธิ์ (claims) ของตัวตนผู้ใช้ปัจจุบันจากโทเค็นการเข้าถึงที่ตรวจสอบแล้ว ใช้ getAuthInfo เพื่ออ่านข้อมูล auth ที่ mcp-auth ตรวจสอบแล้วจาก context ของ callback เครื่องมือ

import { McpServer } from '@modelcontextprotocol/server';
import { getAuthInfo } from 'mcp-auth';

// ฟังก์ชัน factory สำหรับสร้างอินสแตนซ์ MCP server
// แต่ละคำขอจะได้อินสแตนซ์ server ของตัวเอง เพื่อแยกคำขอออกจากกัน
const createMcpServer = () => {
  const mcpServer = new McpServer({
    name: 'WhoAmI',
    version: '0.0.0',
  });

  // เพิ่มเครื่องมือในเซิร์ฟเวอร์ที่ส่งคืนข้อมูลผู้ใช้ปัจจุบัน
  mcpServer.registerTool(
    'whoami',
    {
      description: 'รับข้อมูลผู้ใช้ปัจจุบัน',
    },
    (context) => {
      const { claims } = getAuthInfo(context);
      return {
        content: [{ type: 'text', text: JSON.stringify(claims) }],
      };
    }
  );

  return mcpServer;
};

เชื่อมต่อเซิร์ฟเวอร์

สุดท้าย ให้บริการ OAuth discovery documents (RFC 9728 / RFC 8414) เพื่อให้ไคลเอนต์ MCP ค้นหาเซิร์ฟเวอร์การอนุญาตของคุณ และปกป้อง endpoint MCP ด้วย Bearer auth middleware ของ SDK

import {
  createMcpExpressApp,
  mcpAuthMetadataRouter,
  requireBearerAuth,
} from '@modelcontextprotocol/express';
import { toNodeHandler } from '@modelcontextprotocol/node';
import { createMcpHandler } from '@modelcontextprotocol/server';

const PORT = 3001;

// MCP handler ใช้มาตรฐานเว็บ Request / Response; `toNodeHandler` ปรับให้เข้ากับ Express
const mcpNodeHandler = toNodeHandler(createMcpHandler(createMcpServer));

const app = createMcpExpressApp();

// ให้บริการ OAuth discovery documents (`/.well-known/...`) ซึ่งเป็นสาธารณะโดยออกแบบ
app.use(mcpAuthMetadataRouter(await mcpAuth.getAuthMetadataOptions()));

app.all(
  '/',
  // ต้องการ Bearer token ที่ถูกต้อง; ข้อมูล auth ที่ตรวจสอบแล้วจะถูกส่งต่อไปยัง handler ผ่าน `req.auth`
  requireBearerAuth(mcpAuth.getBearerAuthOptions()),
  // `createMcpExpressApp` ใช้ `express.json()` ซึ่งจะดึงข้อมูลจาก request stream ดังนั้น
  // body ที่แปลงแล้วจะถูกส่งต่ออย่างชัดเจน
  async (request, response) => mcpNodeHandler(request, response, request.body)
);

app.listen(PORT);

รันเซิร์ฟเวอร์ด้วย:

npm start

ทดสอบการผสานระบบ

1. เริ่มต้นเซิร์ฟเวอร์ MCP
2. เชื่อมต่อ AI agent บุคคลที่สามกับเซิร์ฟเวอร์ MCP ของคุณและเรียกใช้เครื่องมือ whoami
3. agent จะได้รับการตอบกลับ 401 Unauthorized, ค้นพบ Logto ผ่าน metadata ของทรัพยากรที่ได้รับการป้องกันของเซิร์ฟเวอร์ MCP และเปลี่ยนเส้นทางผู้ใช้ไปยัง Logto เพื่อยืนยันตัวตน
4. ผู้ใช้ลงชื่อเข้าใช้และตรวจสอบหน้าขอความยินยอม ซึ่งจะแสดงสิทธิ์ที่ agent ร้องขอ จากนั้นอนุมัติ (หรือปฏิเสธ) การเข้าถึง
5. agent จะได้รับ JWT โทเค็นการเข้าถึงที่ผูกกับผู้รับ (audience-bound) และใช้โทเค็นนี้เรียกใช้เครื่องมืออีกครั้ง
6. เซิร์ฟเวอร์ MCP ตรวจสอบโทเค็นการเข้าถึงกับ JWKS ของ Logto และคืนค่าการอ้างสิทธิ์ตัวตนที่ตรวจสอบแล้วให้ agent

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

ขณะนี้เซิร์ฟเวอร์ MCP ของคุณสามารถตรวจสอบโทเค็นการเข้าถึงขาเข้าจาก AI agent บุคคลที่สามได้แล้ว ขั้นตอนถัดไป เรียนรู้วิธีที่เซิร์ฟเวอร์ MCP ของคุณสามารถเรียก API ธุรกิจ downstream ของคุณอย่างปลอดภัยในนามของผู้ใช้ โดยไม่ต้องส่งต่อโทเค็นหรือสูญเสียบริบทผู้ใช้:

วิธีที่เซิร์ฟเวอร์ MCP เรียก API ของคุณในนามของผู้ใช้: กลยุทธ์โทเค็นสำหรับ production