MCP แบบ Local กับ Remote และการ Login ด้วย OAuth

เลือกระหว่าง MCP Server บนเครื่องกับบนอินเทอร์เน็ต เข้าใจกลไก OAuth ที่สเปก MCP กำหนด และจุดที่ต้องตั้งค่าให้ปลอดภัย

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

MCP แบบ Local และ Remote คืออะไร

เอกสาร Architecture ของ MCP อธิบายว่า Server ทำงานได้ทั้งบนเครื่องและบนอินเทอร์เน็ต

• Local Server รันบนเครื่องเดียวกับแอป AI ใช้ transport แบบ stdio และมักให้บริการ Client เพียงตัวเดียว เช่น Server ระบบไฟล์ที่ Claude Desktop เปิดขึ้นมาเอง
• Remote Server อยู่บนอินเทอร์เน็ต ใช้ Streamable HTTP และให้บริการ Client ได้หลายตัว เช่น Server ทางการของ Sentry ที่รันบนแพลตฟอร์มของ Sentry

เลือกแบบไหนดี

Local เหมาะเมื่อ

• ข้อมูลอยู่บนเครื่องผู้ใช้ เช่น ไฟล์ในโฟลเดอร์งาน
• ใช้คนเดียว หรือกำลังทดลองพัฒนา
• ยอมรับได้ว่าต้องติดตั้งบนทุกเครื่อง ซึ่งคู่มือทางการระบุว่า Server หลายตัวต้องมี Node.js ด้วย

Remote เหมาะเมื่อ

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

การ Login ของ Local Server

สเปก Authorization ของ MCP ระบุว่า Server แบบ stdio ไม่ควรใช้ flow OAuth แต่ให้รับ credential จาก environment เช่น API key ที่ตั้งไว้ในไฟล์ตั้งค่า ข้อสำคัญคือ Local Server รันด้วยสิทธิ์ของบัญชีผู้ใช้ จึงทำทุกอย่างที่ผู้ใช้ทำได้

OAuth ใน Remote Server ทำงานยังไง

สำหรับ transport แบบ HTTP สเปกกำหนดให้ใช้ OAuth 2.1 โดย MCP Server ทำหน้าที่เป็น resource server และ MCP Client เป็นตัวแทนผู้ใช้ ลำดับคร่าวๆ เป็นแบบนี้

1. Client ส่งคำขอโดยยังไม่มี token แล้วได้คำตอบ 401 พร้อมบอกที่อยู่ของเอกสาร Protected Resource Metadata
2. Client อ่านเอกสารนั้นเพื่อหาว่า authorization server คือใคร แล้วดึงข้อมูลตั้งค่าของ server นั้น
3. Client ลงทะเบียนตัวเอง โดยสเปกล่าสุดแนะนำ Client ID Metadata Documents ส่วน Dynamic Client Registration ยังรองรับแต่ถูกประกาศเลิกใช้
4. เบราว์เซอร์เปิดหน้า login ผู้ใช้ยืนยันตัวตนและอนุญาตสิทธิ์ โดย Client ใช้ PKCE และระบุ resource ว่า token นี้มีไว้ใช้กับ Server ตัวไหน
5. Client ได้ access token แล้วแนบไปในทุกคำขอ Server ต้องตรวจว่า token ออกมาเพื่อตัวเองจริง

ข้อดีของ flow นี้คือแอป AI ไม่เคยเห็นรหัสผ่านของผู้ใช้ และเพิกถอนสิทธิ์ได้ภายหลัง

ตัวอย่าง: สำนักงานบัญชีขนาดกลาง

สำนักงานบัญชีแห่งหนึ่งใช้ 2 แบบพร้อมกัน นักบัญชีแต่ละคนติดตั้ง Local Server ที่อ่านได้เฉพาะโฟลเดอร์ลูกค้าที่ตัวเองดูแล ส่วนระบบติดตามงานของทั้งสำนักงานเปิดเป็น Remote Server ให้ทุกคน login ด้วยบัญชีบริษัทผ่าน OAuth ใครออกจากงาน ฝ่ายไอทีปิดบัญชีเดียว สิทธิ์ใน AI ก็หายไปด้วย

ข้อควรระวัง

• Remote Server ต้องเข้าถึงได้จากอินเทอร์เน็ต ศูนย์ช่วยเหลือของ Claude ระบุว่า Claude เชื่อม remote connector จากคลาวด์ของ Anthropic ไม่ใช่จากเครื่องคุณ Server หลัง VPN หรือ firewall จะต่อไม่ได้ ถ้าไม่ allowlist IP ไว้
• ขอ scope ให้น้อยที่สุด เอกสาร Security Best Practices แนะนำให้เริ่มจากสิทธิ์พื้นฐาน แล้วขอเพิ่มเมื่อจำเป็น แทนการขอสิทธิ์ทั้งหมดตั้งแต่แรก
• ห้ามส่ง token ต่อแบบตรงๆ Server ต้องไม่รับ token ที่ไม่ได้ออกให้ตัวเอง
• Local Server ที่ติดตั้งคลิกเดียว ควรเห็นคำสั่งที่จะรันทั้งหมดก่อนกดยืนยัน

Local คือความสะดวกของคนเดียว Remote คือการจัดการสิทธิ์ของทั้งทีม เลือกตามว่าข้อมูลอยู่ที่ไหน และใครต้องใช้

เริ่มต้นยังไง

1. ระบุว่าข้อมูลที่อยากให้ AI ใช้อยู่บนเครื่องผู้ใช้ หรือบนระบบกลาง
2. ถ้าเป็นระบบกลาง เช็กว่าผู้ให้บริการมี Remote MCP Server ทางการแล้วหรือยัง ก่อนสร้างเอง
3. ถ้าสร้างเอง ใช้ authorization server ที่องค์กรมีอยู่แล้ว แทนการเขียนระบบ login ใหม่
4. ทดสอบ flow login กับบัญชีที่มีสิทธิ์ต่ำก่อน แล้วค่อยขยาย

อ่านพื้นฐานเพิ่มที่ MCP คืออะไร และ สร้าง MCP Server ตัวแรก เพื่อเห็นภาพทั้งระบบก่อนตัดสินใจ