เสริมพลังธุรกิจของคุณ: เชื่อมต่อเครื่องมือ AI เข้ากับบริการที่มีอยู่ของคุณด้วยการควบคุมการเข้าถึง
เรียนรู้วิธีเสริมพลังธุรกิจของคุณโดยเชื่อมต่อเครื่องมือ AI เข้ากับบริการที่มีอยู่ของคุณอย่างปลอดภัยด้วยการใช้ Personal Access Tokens และ Model Context Protocol (MCP) พร้อมซอร์สโค้ดสมบูรณ์และตัวอย่างที่ใช้งานได้จริง
ยินดีต้อนรับสู่คู่มือเชื่อมต่อเครื่องมือ AI เข้ากับบริการที่มีอยู่ของคุณพร้อมการควบคุมการเข้าถึง!
เราจะสำรวจวิธีเตรียมบริการที่มีอยู่ของคุณให้พร้อมสำหรับเครื่องมือ AI โดยเฉพาะการรวมเข้ากับ LLM (โดยใช้ Model Context Protocol)) และตัวแทน AI ต่างๆ ในขณะเดียวกันก็จัดการกับความท้าทายด้านการควบคุมการเข้าถึง
ผ่านคู่มือนี้ คุณจะได้เรียนรู้:
- การรวม AI อย่างไร้รอยต่อ: เรียนรู้วิธีเชื่อมต่อเครื่องมือ AI เข้ากับบริการของคุณ ทำให้ข้อมูลและฟังก์ชันของคุณพร้อมใช้งานในสภาพแวดล้อม AI
- ความปลอดภัย API ที่เพิ่มขึ้น: ปรับปรุงอินเทอร์เฟซ API ของคุณเพื่อปกป้องข้อมูลและความเป็นส่วนตัวของผู้ใช้ด้วยการควบคุมการเข้าถึงที่มีประสิทธิภาพ
- ประสบการณ์ AI ที่เป็นส่วนตัวสำหรับผู้ใช้ของคุณ: สร้างประสบการณ์ที่ใช้ AI ช่วยสำหรับผู้ใช้แต่ละคนผ่าน Personal Access Tokens
เรามีทรัพยากรการสอนที่สมบูรณ์, โครงการสาธิตที่สมบูรณ์ ซอร์สโค้ด (มีส่วน Frontend, Backend และ MCP SERVER) และแม้กระทั่งคำแนะนำปฏิบัติที่ช่วยให้คุณสร้างบริการพร้อม AI จากศูนย์ได้
นี่คือวิธีที่คู่มือนี้จะช่วยปรับปรุงธุรกิจของคุณ:
- ความได้เปรียบในการแข่งขัน: เสริมสร้างความสามารถทางเทคนิคและประสบการณ์ผู้ใช้ของบริการของคุณให้โดดเด่นในตลาดที่มีการแข่งขัน
- การเพิ่มค่าให้กับผู้ใช้: ช่วยให้ผู้ใช้ค้นพบคุณค่าที่ลึกซึ้งยิ่งขึ้นในผลิตภัณฑ์ของคุณผ่านเครื่องมือ AI, เพิ่มอัตราการเก็บรักษาและความพึงพอใจ
- บริการที่พร้อมรับอนาคต: รวมบริการของคุณเข้ากับระบบนิเวศ AI อย่างไร้รอยต่อ, เตรียมพร้อมสำหรับภูมิทัศน์ธุรกิจที่ขับเคลื่อนด้วย AI ที่กำลังจะมาถึง และเปิดเส้นทางการเติบโตที่สร้างสรรค์
มาเริ่มกันเลย!
MCP คืออะไรและมันเชื่อมต่อเครื่องมือ AI เข้ากับบริการของคุณอย่างไร
MCP (Model Context Protocol) เป็นโปรโตคอลเปิดที่เป็นสากลที่มาตรฐานการให้ข้อมูลบริบทกับโมเดลภาษาใหญ่ (LLMs)
MCP ประกอบด้วยองค์ประกอบสำคัญหลายอย่างที่ทำงานร่วมกันเพื่อให้เครื่องมือ AI สามารถเข้าถึงบริการของคุณได้:
ในคู่มือนี้ คุณเพียงแค่รู้ว่า MCP Server เป็นจุดเชื่อมต่อที่สำคัญระหว่างบริการของคุณและเครื่องมือ AI ซึ่งเป็นผู้ให้บริการเครื่องมือชุดต่างๆ สำหรับ LLM ที่จะใช้งาน และเครื่องมือเหล่านี้จะทำงานร่วมกับบริการของคุณเอง สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ MCP คุณสามารถดูได้ที่ MCP คืออะไรและมันทำงานอย่างไร ที่นี่ เราจะเน้นไปที่ MCP Server เท่านั้น
เราจะใช้ระบบบริหารเนื้อหา (CMS) ที่มีการรวมกฎการควบคุมการเข้าถึงตามบทบาท (RBAC) เป็นตัวอย่าง เราจะสร้าง MCP Server สำหรับมันและกำหนดเครื่องมือ get-available-article-count
ที่อนุญาตให้ LLM ดึงจำนวนบทความที่มีให้กับผู้ใช้ในปัจจุบันใน CMS:
นี่คือโค้ดสำคัญสำหรับการเชื่อมต่อ MCP Server เข้ากับบริการของคุณ ในการใช้งานเครื่องมือนี้ จะส่งคำขอไปยัง endpoint api/articles
ของบริการและส่งคืนผลลัพธ์แต่อย่างไรก็ตาม นี่ยังไม่เพียงพอ เนื่องจาก API ของบริการอาจจะไม่ใช่สาธารณะ แต่ละ endpoint ต้องการการควบคุมการเข้าถึง และผู้ใช้ต่างๆ อาจจะเข้าถึงข้อมูลและทรัพยากรที่ต่างกันได้
ต่อไปเราจะพูดถึงวิธีการเพิ่มการควบคุมการเข้าถึงให้กับบริการของคุณ
วิธีการใช้การควบคุมการเข้าถึงสำหรับ MCP Server
สิ่งสำคัญคือต้องเข้าใจว่าผู้ใช้ที่เข้าถึงระบบของคุณผ่านเครื่องมือ AI นั้นเป็นบุคคลเดียวกันกับที่อาจจะใช้ระบบของคุณโดยตรง - MCP Server ทำหน้าที่เป็นตัวแทนของพวกเขาเมื่อพวกเขาโต้ตอบผ่านเครื่องมือ AI
ดังนั้นเมื่อผู้ใช้เข้าถึงบริการของคุณผ่านเครื่องมือ AI สองปัญหาการเข้าถึงที่เกิดขึ้นจริงคือ:
- MCP Server จะเข้าสู่ระบบของคุณเหมือนผู้ใช้อย่างไร?
- ระบบของคุณควรออกแบบกลไกการควบคุมการเข้าถึงทั้งหมดใหม่เพื่อรองรับ MCP Server หรือไม่? ซึ่งจะเป็นค่าใช้จ่ายและความพยายามสำคัญ โดยเฉพาะเมื่อระบบดั้งเดิมของคุณมีการยืนยันตัวตนของมันเอง
กุญแจสำคัญในการแก้ปัญหาเหล่านี้คือ:
จะให้ผู้ใช้สามารถให้ MCP Server เข้าถึงบริการของคุณได้โดยไม่ต้องใช้ข้อมูลหลักของพวกเขาและการเข้าสู่ระบบแบบโต้ตอบได้อย่างไร?
ถ้าคุณแก้ปัญหานี้ได้ คุณก็สามารถโต้ตอบกับบริการของคุณได้โดยตรงผ่าน MCP Server และบริการของคุณสามารถใช้กลไกการควบคุมการเข้าถึงที่ออกแบบไว้ให้กับผู้ใช้ได้ต่อไปโดยไม่ต้องออกแบบระบบใหม่เพียงเพื่อ MCP Server!
แต่เป็นไปได้ไหม?
แน่นอนว่ามันเป็นไปได้ เราสามารถแก้ไขปัญหานี้อย่างลงตัวด้วยการ ใช้ Personal Access Tokens!
Personal Access Tokens (PATs) มอบวิธีที่ปลอดภัยให้ผู้ใช้มอบ access token โดยไม่ต้องใช้ข้อมูลหลักของพวกเขาและการเข้าสู่ระบบแบบโต้ตอบ ซึ่งมีประโยชน์สำหรับ CI/CD, สคริปต์, หรือโปรแกรมที่ต้องเข้าถึงทรัพยากรอย่างโปรแกรม
นี่คือวิธีการทำงาน:
ดังนั้น ตราบใดที่ระบบของคุณรองรับ Personal Access Tokens (PAT) คุณก็สามารถแก้ไขปัญหาการควบคุมการเข้าถึงระหว่างเครื่องมือ AI กับบริการที่มีอยู่ของคุณได้อย่างสมบูรณ์แบบโดยไม่ต้องออกแบบกลไกการยืนยันตัวตนใหม่ ในขณะที่ยังคงไว้ซึ่งความปลอดภัยข้อมูลและการปกป้องความเป็นส่วนตัวของผู้ใช้
ตอนนี้ มาดูกันว่าทำอย่างไรในทางปฏิบัติ
การนำการเข้าถึง MCP Server ไปใช้งาน
ในส่วนนี้ เราจะนำการควบคุมการเข้าถึงสำหรับ MCP Server ไปใช้งานโดยใช้ระบบ CMS ที่มีอยู่เป็นพื้นฐานของเรา
คุณสามารถตรวจสอบตัวอย่างการใช้งาน CMS พร้อมกับซอร์สโค้ดใน RBAC in practice: การใช้การยืนยันตัวตนที่ปลอดภัยสำหรับแอปพลิเคชันของคุณ แต่ไม่จำเป็น เราจะครอบคลุมหลักการสำคัญทั้งหมดที่นี่
ตัวอย่าง CMS นั้นมีพื้นฐานจาก Logto ซึ่งเป็นแพลตฟอร์มการยืนยันตัวตนอันเชิงเปิดที่มอบโซลูชันการยืนยันตัวตนและการอนุญาตที่ครบถ้วน แต่อย่างไรก็ตาม การดำเนินการทางเทคนิคไม่ใช่ประเด็นหลักของบทความนี้
การออกแบบการอนุญาตและนโยบายการควบคุมการเข้าถึงสำหรับบริการของคุณ
ขั้นตอนแรกในการใช้การควบคุมการเข้าถึงคือออกแบบการอนุญาตและนโยบายการควบคุมการเข้าถึงสำหรับระบบของคุณ
ในตัวอย่าง CMS ของเรา เราได้ออกแบบ API endpoints ต่อไปนี้ตาม RBAC (Role-Based Access Control) และระบุสิทธิ์ที่จำเป็นในการเข้าถึงแต่ละ endpoint:
Endpoint | Logic การควบคุมการเข้าถึง |
---|---|
GET /api/articles | - ใครก็ตามที่มีสิทธิ์ list:articles หรือผู้เขียนที่สามารถดูบทความของตัวเอง |
GET /api/articles/:id | - ใครก็ตามที่มีสิทธิ์ read:articles หรือผู้เขียนบทความนั้น |
POST /api/articles | - ใครก็ตามที่มีสิทธิ์ create:articles |
PATCH /api/articles/:id | - ใครก็ตามที่มีสิทธิ์ update:articles หรือผู้เขียนบทความนั้น |
DELETE /api/articles/:id | - ใครก็ตามที่มีสิทธิ์ delete:articles หรือผู้เขียนบทความนั้น |
PATCH /api/articles/:id/published | - เฉพาะผู้ใช้ที่มีสิทธิ์ publish:articles |
การออกแบบสิทธิ์ของระบบเป็นดังนี้:
สิทธิ์ | คำอธิบาย |
---|---|
list:articles | ดูรายการบทความทั้งหมดในระบบ |
read:articles | อ่านเนื้อหาเต็มของบทความใดก็ได้ |
create:articles | สร้ างบทความใหม่ |
update:articles | แก้ไขบทความใดก็ได้ |
delete:articles | ลบบทความใดก็ได้ |
publish:articles | เปลี่ยนสถานะการเผยแพร่ |
จากสิทธิ์เหล่านี้ เราได้กำหนดบทบาทต่อไปนี้สำหรับระบบ CMS ของเรา:
สิทธิ์/บทบาท | 👑 ผู้ดูแลระบบ | 📝 นักเผยแพร่ | ✍️ ผู้เขียน |
---|---|---|---|
คำอธิบาย | การเข้าถึงระบบเต็มที่สำหรับการจัดการเนื้อหา | ดูบทความทั้งหมดและควบคุมสถานะการเผยแพร่ | สร้างบทความใหม่ในระบบ |
list:articles | ✅ | ✅ | ❌ |
read:articles | ✅ | ✅ | ❌ |
create:articles | ✅ | ❌ | ✅ |
update:articles | ✅ | ❌ | ❌ |
delete:articles | ✅ | ❌ | ❌ |
publish:articles | ✅ | ✅ | ❌ |
หมายเหตุ: ผู้เขียนจะมีสิทธิ์ในการอ่าน/อัปเดต/ลบบทความของตนเองโดยอัตโนมัติ ไม่ขึ้นอยู่กับสิทธิ์ของบทบาท
ถัดไป เราจะมอบบทบาทให้ผู้ใช้ในระบบของเรา (โดยใช้ตัวอย่าง CMS):
ผู้ใช้ | บทบาท |
---|---|
Alex | ผู้ดูแลระบบ |
Bob | นักเผยแพร่ |
Charlie | ผู้เขียน |
และใน Logto ตามที่กล่าวในบทความ RBAC in practice ข้างต้น เราได้ตั้งบทบาทให้กับผู้ใช้ของเรา
นำกฎการควบคุมการเข้าถึงไปใช้ในบริการ API ของคุณ
นี่คือวิธีที่ผู้ใช้เข้าสู่ระบบ CMS ของเรา:
ดังนั้น การนำกฎการควบคุมการเข้าถึงไปใช้ในบริการ API ของคุณนั้นง่ายเท่ากับการเพิ่ม middleware เพื่อvalidate token และตรวจสอบสิทธิ์ในขั้นตอนที่ 9
การดำเนินการหลักมีดังนี้ (ตรวจสอบการดำเนินการที่สมบูรณ์ใน RBAC sample - backend):
และนำ middleware ไปใช้กับ endpoint API ที่ต้องการการยืนยันตัวตน:
เราตอนนี้ได้เพิ่มการควบคุมการเข้าถึงในระบบ CMS ของเราและมอบบทบาทให้กับผู้ใช้ของเรา
หลังจากผู้ใช้เข้าสู่ระบบและได้รับ Access Token สำหรับ CMS API พวกเขาสามารถใช้ token นี้เพื่อเข้าถึง CMS API ได้ Access Token จะมีข้อมูลสิทธิ์ของผู้ใช้ ซึ่งช่วยให้เราสามารถควบคุมข้อมูลที่จะแสดงตามสิทธิ์ของผู้ใช้ได้
ขั้นตอนถัดไปของเราคือการนำ MCP Server ไปใช้เพื่อใช้ Personal Access Tokens
ทำความเข้าใจว่า Personal Access Token แทนที่ผู้ใช้อย่างไร
อ้างอิงจากกระแสการยืนยันตัวตนของ CMS ข้างต้น ผู้ใช้จะได้รับ Access Token สำหรับ CMS API หลังจากเข้าสู่ระบบ Access Token นี้เป็นข้อมูลประจำตัวของพวกเขาในการเข้าถึง CMS API
เราต้องการเพียงรับ Access Token ที่คล้ายกับสิ่งที่ผู้ใช้รับหลังจากเข้าสู่ระบบ จากนั้นเราสามารถใช้มันเพื่อเข้าถึง CMS API
นี่คือที่ที่ Personal Access Tokens เข้าช่วย พวกเขาช่วยเราได้รับ Access Token ชนิดเดียวกับที่ผู้ใช้ได้รับตามปกติหลังจากเข้าสู่ระบบ
สิ่งที่ต้องทำคือ:
- สร้าง Personal Access Token สำหรับผู้ใช้
- ใช้ Personal Access Token นี้เพื่อขอ token แลกเปลี่ยนจาก endpoint token ของ Auth Service ซึ่งจะให้ Access Token ที่คล้ายกับสิ่งที่ผู้ใช้ได้รับหลังจากเข้าสู่ระบบ
- ใช้ Access Token นี้ในเครื่องมือบริการ MCP ของเราเพื่อเข้าถึง CMS API
ในตัวอย่างนี้ เราใช้ Logto เป็นการสาธิต เนื่องจาก Logto รองรับ Personal Access Tokens และการแลกเปลี่ยน token หากคุณไม่ได้ใช้ Logto คุณสามารถทำตามแนวทางนี้เพื่อใช้ Personal Access Tokens ของคุณเอง
สร้าง Personal Access Token สำหรับผู้ใช้ของคุณ
ใน Logto Console > การจัดการผู้ใช้ คุณสามารถสร้าง Personal Access Token สำหรับผู้ใช้ได้จากหน้าข้อมูลของผู้ใช้:
เมื่อสร้าง Personal Access Token คุณสามารถกำหนดเวลาหมดอายุได้ตามต้องการ
การใช้ Personal Access Token ใน MCP Server
ตอนนี้เรามี Personal Access Token ของผู้ใช้แล้ว เราสามารถใช้มันใน MCP Server ของเรา
ก่อนอื่น มาเริ่มจากการทำตามเอกสาร Personal Access Token documentation ของ Logto เราจะได้ Access Token สำหรับการเข้าถึง CMS API ที่ endpoint token ของ Logto คุณสามารถตรวจสอบซอร์สโค้ดเต็มได้ ที่นี่
ใน MCP Server เราใช้ Access Token จากฟังก์ชัน exchangeAccessToken
เพื่อดึงข้อมูลจาก CMS API
วิธีนี้ MCP Server ไม่ต้องการข้อมูลหลักของผู้ใช้ในการเข้าถึง CMS API แต่ใช้ Personal Access Token ของผู้ใช้แทน
คุณสามารถดูซอร์สโค้ดที่สมบูรณ์ได้ที่ RBAC sample - mcp-server。
เรียนรู้วิธีการนำ MCP Server นี้ไปใช้งานในพื้นที่ Claude Desktop ท้องถิ่นได้ MCP Server deployment guide。
คุณยังสามารถนำเซิร์ฟเวอร์นี้ไปใช้งานใน IDEs AI ต่างๆ เช่น Cursor, Cline, Windsurf เป็นต้น
ทดสอบการควบคุมการเข้าถึง
ลองทดสอบการนำไปใช้นี้ใน Claude Desktop
ใน CMS ของเรา ทั้ง Alex และ Charles ได้สร้างบทความขึ้นมาคนละหนึ่งบทความ
เนื่องจาก Alex มีบทบาทเป็นผู้ดูแลระบบ พวกเขาสามารถเห็นบทความทั้งหมด Charles ซึ่งเป็นผู้เขียนสามารถเห็นแค่บทความของตัวเองได้เท่านั้น
เมื่อเราถาม Claude ว่ามีบทความพร้อมใช้งานกี่บทความ Claude จะใช้เครื่องมือ get-available-article-count
และขออนุญาตจากเรา:
เมื่อเราใช้ Personal Access Token ของ Alex ใน MCP และถาม Claude เกี่ยวกับจำนวนบทความที่มีอยู่ Claude ก็เรียกใช้เครื่องมือ get-available-article-count
และบอกเราว่ามี 2 บทความ
เมื่อเราสลับไปใช้ Personal Access Token ของ Charles และถามคำถามเดียวกัน Claude ก็บอกเราว่ามีแค่บทความเดียว
เยี่ยมเลย! เราได้ใช้ Personal Access Tokens เพื่เข้าถึง CMS API และได้รับข้อมูลที่ถูกต้องตามที่ต้องการ
นี่คือสิ่งที่เราต้องการ: เราสร้าง Personal Access Token สำหรับผู้ใช้แต่ละคน และเมื่อผู้ใช้ตั้งค่า MCP Server ของพวกเขาด้วย token ของพวกเขาเอง เราก็สร้างประสบการณ์ AI ส่วนบุคคลสำหรับพวกเขา
ให้เราช่วยคุณเขียนสรุป:
สรุป
ในคู่มือนี้ เราได้สำรวจวิธีการเชื่อมต่อเครื่องมือ AI เข้ากับบริการที่มีอยู่ของคุณในขณะที่ยังคงการควบคุมการเข้าถึงที่เหมาะสม เราได้สาธิตสิ่งนี้โดยใชระบบ CMS ที่มีการใช้ RBAC แสดงให้เห็นว่า Personal Access Tokens (PATs) สามารถแก้ปัญหาความท้าทายในการยืนยันตัวตนได้อย่างสง่างาม
คุณสามารถค้นหาซอร์สโค้ดที่สมบูรณ์สำหรับการใช้งานนี้ได้ใน RBAC sample repository ของเรา ซึ่งรวมถึงการใช้งาน backend, frontend, และ MCP server ของ CMS
เมื่อแจกจ่าย MCP Server ให้กับผู้ใช้ อย่าลืมทำให้ Personal Access Token ปรับแต่งได้ สิ่งนี้ทำให้ผู้ใช้แต่ละคนสามารถ:
- ตั้งค่า PAT ของพวกเขาเองใน MCP server
- เข้าถึงทรัพยากรตามสิทธิ์เฉพาะของพวกเขา
- รับประสบการณ์ AI ที่เป็นส่วนบุคคลที่สะท้อนถึงบทบาทและระดับการเข้าถึงของพวกเขาในระบบของคุณ
แนวทางนี้จะประกันว่าการรวม AI ของคุณปลอดภัยในขณะที่มอบประสบการณ์ที่ปรับแต่งให้กับผู้ใช้แต่ละคนอิงตามสิทธิ์และบทบาทในระบบของคุณ
ขอให้ธุรกิจของคุณประสบความสำเร็จอย่างมากเมื่อคุณเริ่มเส้นทางการรวม AI นี้! ขอให้บริการของคุณเติบโตและเฟื่องฟูด้วยศักยภาพ AI ใหม่เหล่านี้! 🚀