ไทย

เซิร์ฟเวอร์ MCP
token exchange
OAuth

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

อธิบายกลยุทธ์ของโทเค็นขาออกสำหรับเซิร์ฟเวอร์ MCP: ทำไม token passthrough และ M2M ถึงล้มเหลว และโทเค็น exchange รักษาสิทธิ์การเข้าถึงให้ตรงกับสิทธิ์ของผู้ใช้ได้อย่างไร

Yijun

Developer

8/21/2026

หยุดเสียเวลาเป็นสัปดาห์กับการยืนยันตัวตนผู้ใช้

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

เริ่มต้นใช้งาน

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

ใน บทความก่อนหน้า เราได้แชร์ประสบการณ์โดยรวมในการสร้าง Logto remote MCP server บทความนี้จะครอบคลุมการออกแบบสถาปัตยกรรมและ flow ของ OAuth อย่างละเอียด

เมื่อ MCP server เป็นเส้นแบ่ง การพิสูจน์ตัวตนสำหรับ remote MCP server จะมีสองขา: ขาเข้า (inbound) และ ขาออก (outbound)

ขาเข้า: MCP client (VS Code, Cursor, ฯลฯ) ลงชื่อเข้าใช้ผ่าน OAuth รับ access token และใช้เพื่อเข้าถึง MCP server ของคุณ
ขาออก: เมื่อจัดการกับการเรียกใช้งานเครื่องมือ MCP server จะเรียก API ธุรกิจของคุณแทนผู้ใช้

ขาเข้าถูกนิยามไว้อย่างชัดเจนในสเปค MCP มีการพูดคุยและ implementation อยู่มากมายใน community เราก็เขียน คู่มือ implement เอาไว้เช่นกัน ขาออกกลับไม่ค่อยมีใครพูดถึง: MCP server จะมีแต่โทเค็นที่เข้าถึงตัวมันเอง แล้วมันจะเรียก business API ของคุณแทนผู้ใช้ได้อย่างไร?

นี่คือคำถามที่เราคิดไม่ตกตอนสร้าง Logto MCP server Logto Cloud เป็นโปรดักต์ B2B multi-tenant ทั่วไป: ผู้ใช้คนเดียวอยู่ได้หลาย tenant และสิทธิ์การเข้าถึงจะมาจากบทบาทของผู้ใช้ในแต่ละ tenant AI ต้องไม่เพียงแค่แสดงตัวแทนผู้ใช้ ยังต้องเลือก tenant ให้ถูกอีกด้วย

บทความนี้จะดำเนินไปตามลำดับการคิดของเราจริง ๆ:

ทำไม MCP server ควร deploy แยกเป็น resource ที่ป้องกันอีกส่วน
สองวิธีขาออกที่เราปฏิเสธ (token passthrough และ M2M token) พร้อมปัญหาของมัน
แบบที่ใช้จริง: token exchange + subject token รวมถึงวิธีที่ org token รองรับ multi-tenancy
หลักการสำคัญบางข้อสำหรับคนที่อยากสร้างแบบเดียวกัน

ปัญหาหลัก: บทบาทสองฝั่งของ MCP server

มองจากมุม OAuth, remote MCP server จะมีสองบทบาทพร้อมกัน:

สำหรับ MCP client มันคือ resource server: client ต้องถือโทเค็นเพื่อเข้าถึง
สำหรับ business API มันคือ client: มันต้องถือโทเค็นเพื่อเข้าถึง resource อื่น

พูดอีกอย่าง: MCP server เล่นคนละบทบาทในแต่ละฝั่ง และแต่ละฝั่งใช้ โทเค็นคนละตัวกัน โทเค็นที่ MCP client ได้จาก OAuth จะมี MCP server เป็น audience ซึ่ง API ธุรกิจจะปฏิเสธตอนเช็ค audience

ดังนั้น ขาออกก็คือปัญหา delegation: MCP server จะเรียก downstream API แทนผู้ใช้ ในขอบเขตสิทธิ์ผู้ใช้ โดยไม่ต้องเก็บ credentials ผู้ใช้ได้อย่างไร?

การตัดสินใจ: แยก MCP server เป็นบริการเดี่ยว

ฝัง MCP endpoint ลงใน business API เพื่อ share process และ auth stack ดูเหมือนง่ายสุด แต่หลังชั่งใจแล้ว เราเลือก deploy แยก:

แยกความเสี่ยง: ตอนตัดสินใจ Official MCP SDK ยังไม่เหมาะใช้ production และโปรโตคอลก็เปลี่ยนไว (เช่น เปลี่ยนจาก SSE เป็น Streamable HTTP) Logto เป็น IAM ถนนเข้า sign-in ต้องพร้อมเสมอ ถ้า deploy แยก ขืน MCP server พัง จะกระทบแค่ AI entry point ไม่เกี่ยวกับ service หลัก
แยกการพัฒนา: ระบบ MCP เปลี่ยนเร็วมาก แก้ bug client ต้องรีบ deploy ในขณะที่ core service มีขั้นตอนปล่อยแบบระวัง หากแยกจะไม่ดึงกันไปมา
เลือก runtime อิสระ: service แยกเลือก runtime ที่เหมาะได้ Logto MCP server ใช้ Cloudflare Workers: stateless, scale per request, แทบไม่ต้องดูแล ถ้าฝังจะเลือกไม่ได้

MCP server deploy แยกใน domain ของตัวเอง mcp.logto.io ไม่เกี่ยวกับ service หลักเลย จะ open source ทีหลังก็ไม่มีอุปสรรค

แบบฝังไปกับ business API ก็หนีไม่พ้นปัญหา token เช่นกัน: MCP endpoint กับ business API จะ share resource identifier เดียวกัน โทเค็นที่ MCP client ได้จะมีสิทธิ์ API เต็ม ทุกอย่างขึ้นอยู่กับ "การ call นี้วิ่งด้วยสิทธิ์ของใคร" ซึ่งแค่เปลี่ยนจาก exchange ข้าม service เป็น permission ใน process เท่านั้น สุดท้ายปัญหาก็ยังอยู่ Deploy แยกทำให้เรากำหนดขอบ permission ชัดเจน ซึ่งที่เหลือในบทความนี้จะพูดถึงเรื่องนี้

MCP server ต้องมี resource identifier ของตัวเอง

จะเริ่มอภิปรายขาออกจริง ๆ ก็คือ: audience ของโทเค็นที่ MCP client ได้ควรเป็นอะไร?

ใช้ resource identifier เดียวกับ business API ดูง่ายสุด: Management API ของ Logto เป็น OAuth protected resource อยู่แล้ว MCP client จะขอโทเค็นมันไปใช้ตรง ๆ MCP server forward ไปตรง ๆ หลายระบบ MCP รุ่นแรกก็ทำอย่างนี้

แต่ราคาที่จ่ายคือ: ถ้าโทเค็นของ MCP มี audience เป็น business API, ขอบ permission ก็หายไปแล้ว

MCP tools ที่คุณดีไซน์ไว้หมดความหมาย: โทเค็นใช้เรียก API เต็มได้โดยไม่ผ่าน tools
ถ้าโทเค็นหลุด ขอบวงผลกระทบเปลี่ยนจาก "เครื่องมือ MCP ไม่กี่ตัว" กลายเป็น "ทั้ง Management API"
Audit, rate limit, และ permission scope ที่แยกสำหรับ MCP ก็สร้างไม่ได้

ข้อสรุปแรก: MCP server ต้องเป็น resource ที่ป้องกันแยก มี identifier (https://mcp.logto.io) และ scope ของตัวเอง

ข้อดีตรงนี้คือ permission ขอบชัดมาก และทำให้ปัญหาขาออกชัดด้วย: โทเค็นเข้าถึงได้แค่ MCP server แล้วตอน MCP server จะเรียก API ต้องใช้อะไร?

ดูทางเลือกกันต่อ

วิธีที่ 1: token passthrough

วิธีแรกเกิดจากความ analog ธรรมชาติ

Logto Console เป็น SPA วิธีเรียก Management API ง่ายสุด: ลงชื่อเข้าใช้ OAuth ใน browser รับ token ที่มี Management API เป็น audience, frontend เรียก API ตรง ๆ

แล้ว MCP server จะทำตัวเหมือน Console ได้ไหม? ให้ MCP client ขอ โทเค็นของ business API ตอน sign in, MCP server forward ไปแบบไม่ต้องเปลี่ยนอะไรเลย:

ข้อดีคือโคตรง่าย: MCP server แค่ forward โทเค็น แต่ปัญหาก็มีชัดเจน:

1. ขัดกับขอบ permission ที่ตัดสินใจไว้ชัด ๆ token passthrough ต้องให้ MCP client ถือโทเค็นของ business API ซึ่งตรงข้ามกับที่เราเพิ่งปฏิเสธ

2. MCP server ไม่ใช่ protected resource จริงอีกต่อไป โทเค็นที่รับมา audience ไม่ใช่ตัวมันเอง, การตรวจ audience เลยหมดความหมาย เหลือแต่ "ตรวจลายเซ็นกับผู้ออก" ขัดกับ definition ของ MCP spec (ควร act เป็น resource server และประกาศด้วย RFC 9728 Protected Resource Metadata) เรียกว่าเอา backend มาหลอกว่าเป็น SPA ใน browser

3. MCP client ไม่ยอมตาม MCP client ที่ถูกสเปค จะขอโทเค็นตาม metadata, audience จะเป็น MCP server ทำให้ไม่มีทางขอโทเค็นของ business API แบบนี้ไม่ได้ในฝั่ง client

วิธีที่ 2: M2M token

ถ้าโทเค็นฝั่งผู้ใช้ใช้ไม่ได้ เอาโทเค็นของ MCP server เองได้ไหม?

ให้ MCP server ลงทะเบียน M2M (machine-to-machine) application ขอ token ด้วย client credentials แล้วใช้เรียก business API – แบบนี้ใช้บ่อยใน service ภายใน

ตอนนี้ขาเข้าก็ไม่มีปัญหา: โทเค็น client มี audience เป็น MCP server, server ตรวจปกติ แล้วใช้โทเค็น M2M ตัวเอง

จุดตกม้าตายคือ สิทธิ์ของ M2M ไม่เกี่ยวกับสิทธิ์ผู้ใช้เลย

สิทธิ์เกินขอบ: สิทธิ์ใน M2M หมายถึง "MCP server ทำอะไรได้" ไม่ใช่ "ผู้ใช้นี้ทำอะไรได้" เช่น ผู้ใช้ที่มีแค่สิทธิ์อ่าน สามารถลบ application ใน MCP เพราะโทเค็น M2M มีสิทธิ์นั้น
หาตัวผู้ใช้ไม่เจอ: downstream API เห็นแต่ M2M ตลอด, audit log ผูกกับผู้ใช้ไม่ได้
Confused deputy: MCP server กลายเป็น proxy สิทธิ์สูง ใครหลอกมันทำอะไรได้หมด

M2M เหมาะกับ job ที่ไม่มี context ผู้ใช้ เช่น งานประจำ, sync system กับ system MCP server ไม่เหมือนกัน: ทุก call มีผู้ใช้เป็นคนเริ่ม ต้อง act ด้วยสิทธิ์และ identity ผู้นั้น

แบบสุดท้าย: token exchange + subject token

เอาปัญหาสองวิธีแรกมารวมกัน จะได้ requirement ของแบบที่ถูกต้อง:

โทเค็นที่ MCP client ถือใช้ได้แค่ MCP server (จากข้อแรก)
ตอนเรียก downstream MCP server ต้อง act เป็น user นั้น ๆ (จากข้อสอง)

ดังนั้นต้องใช้กลไกมาตรฐาน: token exchange (RFC 8693) MCP server เอาหลักฐานแทนผู้ใช้ แลกเป็นโทเค็นฝั่ง downstream ที่คงสิทธิ์และ identity ของผู้ใช้นั้น ๆ

ใน Logto, "หลักฐานแทนผู้ใช้" คือ user impersonation หรือ subject token เป็น credential อายุสั้นที่ server ขอแทนผู้ใช้ "การแลก token ถัดไปนี้วิ่งเป็น user นี้" ผู้ใช้ไม่ต้องทำหรือ config อะไร flow ทั้งหมดอัตโนมัติ subject token อายุสั้น ใช้ได้ครั้งเดียว หมดอายุทันทีที่ใช้

มี 4 บทบาทในสถาปัตยกรรม MCP server deploy แยกที่ mcp.logto.io:

Flow ของการแลกโทเค็นหลัง call เครื่องมือหนึ่งครั้ง:

ทีละขั้น:

① Inbound validation MCP client เรียก tool พร้อม user token token นี้ audience เป็น resource ID ของ MCP server, scope คือ mcp:all MCP server ตรวจสอบ signature, issuer, audience, scope แล้วได้ identity ผู้ใช้ หยุดที่ inbound token ตัวนี้ไม่เอาไป downstream

② Service identity MCP server ใช้ M2M credentials ขอโทเค็น access ที่ scope เฉพาะ access:mcp:api scope นี้ใช้งานเดียว: เรียก endpoint ต่อไป

③ ขอ subject token คือ key ของ chain ทั้งหมด MCP server เรียก POST /api/mcp/subject-tokens endpoint ที่ Cloud เปิดเฉพาะ MCP โดยให้ credentials สองตัว พร้อมกัน:

Authorization header: M2M token พิสูจน์ตัว "ฉันคือเซิร์ฟเวอร์ MCP"
x-mcp-user-token header: user's token พิสูจน์ "ผู้ใช้นี้ authorize จริง และ authorization ยัง valid"

Cloud ตรวจสอบ user token: signature, issuer, expiry, audience ต้องเป็น resource ID ของ MCP server, scope ต้อง include mcp:all หลังผ่าน userId เอาจาก sub claim ของ token endpoint นี้ไม่มี parameter เลือก user ได้เอง

ดีไซน์นี้กัน misuse ของ M2M credential ถ้า endpoint รับ userId อะไรก็ได้ ใครถือ credential ก็ปลอมเป็น user ไหนก็ได้ แบบนี้ MCP server จะแลก credential ได้แค่กับ user ที่มีโทเค็น valid เท่านั้น

Subject token ที่ได้อายุสั้น ใช้ครั้งเดียว implementation ไม่ cache เลย ขอใหม่ทุกครั้ง

④ แลก working tokens มี subject token แล้ว เอาไปแลกตามมาตรฐาน ได้ token สองแบบตามที่ต้องการ:

Cloud API token: user-level สำหรับคำสั่งที่ใช้ identity ผู้ใช้ เช่น list tenants, create tenants
Org token: scope ไปที่ tenant ที่เลือก (แต่ละ tenant ใน Logto Cloud = 1 org) token นี้ issue แทน user, สิทธิ์เทียบ user role ใน tenant นั้น

⑤ Outbound call เรียก business API ด้วย exchanged token แล้วส่งผลลัพธ์กลับ MCP client

Multi-tenant context จบในขั้นแลก: tenant อยู่ในขั้น exchange ไม่ใช่ขั้น connection list_tenants list ตัวเลือกด้วย Cloud API token ผู้ใช้เลือกผ่าน chat MCP server แลก org token ให้ tenant ที่เลือก endpoint เดียวรับได้ทุก tenant ไม่ต้องแยก deploy ถ้าสร้าง tenant ใหม่กลางทางก็ใช้ได้เลย

ทำไม chain นี้เวิร์ก

เทียบกับ failure ของสองแบบก่อน จะเห็นว่าแก้ทุกจุด:

user token มีขอบเขตแคบลง (จากแบบ 1): audience แค่ MCP server ถ้าหลุดออกไป invoke ได้แค่เครื่องมือ MCP ที่ควบคุมเท่านั้น
M2M โทเค็นใช้ไม่ได้ในทางที่ผิด (จากแบบ 2): ไม่ใช้เรียก business API โดยตรง แค่พิสูจน์ตัว service การออก subject token ต้องใช้ user token valid พร้อมกัน ทำให้ MCP server แลกได้แค่ user ที่ authorize จริง เท่านี้ confused deputy ไม่มีทางเกิด
ไม่ต้องเก็บ credentials ผู้ใช้: subject token ขอและใช้แล้วทิ้ง MCP server เก็บแค่ credentials ตัวเอง
revocation เชื่อมโยง: เมื่อผู้ใช้ un-authorize token user กลายเป็น invalid, check x-mcp-user-token ล้มเหลว chain หยุดที่นี่แหละ
สิทธิ์ downstream ตรงกับผู้ใช้: exchanged token ออกแทน user จริง เช่นเดียวกับสิทธิ์ user นั้น ๆ อ่านได้ก็อ่าน, เขียนไม่ได้ก็ไม่ได้ Audit log เห็นตัวจริง

M2M credential ทำหน้าที่เหมาะเลยใน design นี้: ไว้ยืนยัน "ฉันคือใคร" ส่วนความสามารถ "act เป็น user" ต้องแลกทันทีเมื่อมีอำนาจจาก user จริง

สรุปส่งท้าย

ภาพรวม strategy โทเค็นสำหรับ remote MCP server มีไม่กี่จุดที่สำคัญ:

inbound/outbound authentication แยกกัน, token ฝั่ง MCP client ต้อง audience เป็น MCP server เท่านั้น
outbound แก้ด้วย token exchange: ถ้า auth server รองรับ exchange inbound token ตรง ใช้ exchange ได้ทันที ถ้าไม่ (เช่น Logto รับ subject token) ใช้กลไก impersonation ในฝั่ง server เพื่อเริ่ม exchange
multi-tenancy ไม่มีผลกับกลไก นำ context org เป็น parameter ตอน exchange เดียวกัน โปรดักต์ single-tenant ก็แค่ข้ามไป
AI act แทน user ตลอด สิทธิ์ token downstream ต้อง Match สิทธิ์ผู้ใช้

เทสง่าย ๆ: สมมุติ token ฝั่ง MCP client หลุดออกไป สิ่งที่ attacker ทำได้คือ call MCP tools ที่กำหนดไว้เท่านั้น แถมขอบเขตเทียบผู้ใช้ ถ้าใช้เรียก full API ได้ แปลว่า permission boundary พังแล้ว

MCP ecosystem ยัง evolve เร็วมาก Auth inbound ปกป้องไว้ดีแล้ว ส่วน "จะเรียก downstream อย่างไร" ยังขึ้นอยู่กับแต่ละทีม หวังว่ากรณีของเราจะเป็นตัวอย่างที่ช่วยคุณได้

ถ้าคุณจะสร้าง MCP server สำหรับโปรดักต์ตัวเอง ลองดู solutions ของ Logto สำหรับ AI: Auth สำหรับ AI app, agent, MCP server หรือจะลองเล่น token chain นี้จริง ๆ ก็เชื่อมไปที่ Logto MCP server ได้เลย

แหล่งอ้างอิงในบทความนี้:

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

ปัญหาหลัก: บทบาทสองฝั่งของ MCP server#

การตัดสินใจ: แยก MCP server เป็นบริการเดี่ยว#

MCP server ต้องมี resource identifier ของตัวเอง#

วิธีที่ 1: token passthrough#

วิธีที่ 2: M2M token#

แบบสุดท้าย: token exchange + subject token#

ทำไม chain นี้เวิร์ก#

สรุปส่งท้าย#

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

ปัญหาหลัก: บทบาทสองฝั่งของ MCP server#

การตัดสินใจ: แยก MCP server เป็นบริการเดี่ยว#

MCP server ต้องมี resource identifier ของตัวเอง#

วิธีที่ 1: token passthrough#

วิธีที่ 2: M2M token#

แบบสุดท้าย: token exchange + subject token#

ทำไม chain นี้เวิร์ก#

สรุปส่งท้าย#

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

ปัญหาหลัก: บทบาทสองฝั่งของ MCP server

การตัดสินใจ: แยก MCP server เป็นบริการเดี่ยว

MCP server ต้องมี resource identifier ของตัวเอง

วิธีที่ 1: token passthrough

วิธีที่ 2: M2M token

แบบสุดท้าย: token exchange + subject token

ทำไม chain นี้เวิร์ก

สรุปส่งท้าย

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

ปัญหาหลัก: บทบาทสองฝั่งของ MCP server

การตัดสินใจ: แยก MCP server เป็นบริการเดี่ยว

MCP server ต้องมี resource identifier ของตัวเอง

วิธีที่ 1: token passthrough

วิธีที่ 2: M2M token

แบบสุดท้าย: token exchange + subject token

ทำไม chain นี้เวิร์ก

สรุปส่งท้าย