Zero-Touch OAuth สำหรับ MCP

 (blog.modelcontextprotocol.io)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ส่วนขยาย Enterprise-Managed Authorization (EMA) เข้าสู่สถานะเสถียร ทำให้องค์กรสามารถจัดการสิทธิ์ของเซิร์ฟเวอร์ MCP จากศูนย์กลาง และผู้ใช้สามารถล็อกอินครั้งเดียวเพื่อเข้าถึงเซิร์ฟเวอร์ที่ได้รับอนุญาตได้
  • วิธีการเดิมพึ่งพา การอนุมัติ OAuth แยกเป็นรายผู้ใช้และรายเซิร์ฟเวอร์ ทำให้การออนบอร์ด การบังคับใช้นโยบายความปลอดภัย การตรวจสอบย้อนหลัง และการแยกบัญชีงานกับบัญชีส่วนตัวทำได้ยาก
  • EMA กำหนดให้ IdP ขององค์กรเป็นผู้ตัดสินสิทธิ์การเข้าถึง และเมื่อผู้ดูแลกำหนดนโยบายครั้งเดียว ผู้ใช้จะสืบทอดการเชื่อมต่อ MCP ที่จำเป็นผ่านบัญชีองค์กรเดิมได้
  • ID-JAG ที่ออกระหว่าง SSO จะถูกนำไปแลกเป็น access token ที่ authorization server ของเซิร์ฟเวอร์ MCP ดังนั้นผู้ใช้จึงไม่ถูกรีไดเร็กต์ไปยังหน้าขอความยินยอมของแต่ละเซิร์ฟเวอร์
  • Okta, Anthropic, Visual Studio Code รวมถึง Asana, Atlassian, Canva, Figma, Granola, Linear และ Supabase อยู่ในกลุ่มที่รองรับชุดแรก และ Slack กำลังเพิ่มการรองรับอยู่

EMA เข้าสู่สถานะเสถียรและเป้าหมายสำหรับการใช้งานในองค์กร

  • Enterprise-Managed Authorization (EMA) extension เข้าสู่สถานะ stable แล้ว
  • ในการจัดการการเชื่อมต่อเซิร์ฟเวอร์ MCP ในสภาพแวดล้อมองค์กร การอนุมัติซ้ำและหน้าต่างขอความยินยอมเป็นความไม่สะดวกสำคัญ และ EMA คือส่วนขยายที่ออกแบบมาเพื่อลดปัญหานี้
  • องค์กรสามารถควบคุมการเข้าถึงเซิร์ฟเวอร์ MCP จากศูนย์กลางผ่าน ผู้ให้บริการตัวตน (IdP) ที่เชื่อถือได้
  • ผู้ใช้ปลายทางล็อกอินด้วยบัญชีองค์กรเดิมแล้วเชื่อมต่อกับเซิร์ฟเวอร์ MCP ที่ได้รับอนุญาต โดยลดภาระจากการยินยอม OAuth รายเซิร์ฟเวอร์หรือการตั้งค่าแบบครั้งเดียว

ข้อจำกัดของโมเดลการยืนยันตัวตนแบบรายผู้ใช้

  • โมเดลสิทธิ์มาตรฐานของ MCP ถูกออกแบบให้สอดคล้องกับขอบเขตแบบ user-scoped และแนวปฏิบัติการยืนยันตัวตนเชิงโต้ตอบแบบดั้งเดิม
  • แม้อาจเหมาะกับสถานการณ์แบบผู้บริโภคที่แต่ละคนตัดสินใจเองว่าจะเข้าถึงข้อมูลใด แต่สำหรับการใช้งานในองค์กรกลับขยายได้ไม่ดี
  • ในสภาพแวดล้อมองค์กร มีปัญหาเด่นชัดอยู่สามข้อ
    • พนักงานแต่ละคนต้องอนุมัติเซิร์ฟเวอร์แยกกัน จึงต้องเชื่อมต่อบริการต่าง ๆ ด้วยตนเองระหว่างการออนบอร์ด
    • ทีมความปลอดภัยต้องพึ่งพาการเข้าถึงที่ผู้ใช้แต่ละคนอนุมัติ โดยไม่มีการควบคุมจากส่วนกลางหรือการตรวจสอบย้อนหลัง
    • บังคับใช้บัญชีบริษัทได้ยาก ทำให้ผู้ใช้อาจเชื่อมต่อบัญชีส่วนตัวเข้ากับเครื่องมือทำงาน
  • ความฝืดเหล่านี้ทำให้การนำ MCP มาใช้ช้าลง และเพิ่มโอกาสเกิดการทำทางลัดที่เปราะบาง
  • หากไม่มีมาตรฐานสากลสำหรับเก็บรักษาสถานะการยืนยันตัวตนที่ใช้ร่วมกัน ผู้พัฒนาแต่ละรายก็ต้องสร้างวิธีแก้เอง และแม้มีข้อมูลกับเครื่องมือพร้อมใช้งาน แต่หลายอย่างอาจยังถูกปล่อยให้ปิดไว้เพราะต้นทุนสิทธิ์แบบรายผู้ใช้

อนุมัติครั้งเดียวแล้วสืบทอดได้ทุกที่

  • Enterprise-Managed Authorization ทำให้ IdP ขององค์กรเป็นผู้ตัดสินสิทธิ์การเข้าถึงเซิร์ฟเวอร์ MCP
  • ผู้ดูแลกำหนดนโยบายครั้งเดียว และผู้ใช้ยืนยันตัวตนกับโฮสต์ MCP ด้วย ID องค์กรเดิม
  • IdP สามารถอนุญาตหรือปฏิเสธการเข้าถึงตามสมาชิกกลุ่ม บทบาท และกฎการเข้าถึงแบบมีเงื่อนไข
  • ลำดับการทำงานภายในเป็นดังนี้
    • ไคลเอนต์รับ Identity Assertion JWT Authorization Grant (ID-JAG) จาก IdP ระหว่าง SSO
    • ไคลเอนต์ส่งสิ่งนี้ไปยัง authorization server ของเซิร์ฟเวอร์ MCP เพื่อแลกเป็น access token
    • ผู้ใช้ไม่ต้องผ่านหน้าขอความยินยอมของแต่ละเซิร์ฟเวอร์
  • โครงสร้างนี้ให้ผลลัพธ์สำคัญสามประการ
    • เมื่อผู้ดูแลเปิดใช้เซิร์ฟเวอร์ให้กับองค์กร ผู้ใช้จะเข้าถึงได้โดยอัตโนมัติภายในขอบเขตของกลุ่มและบทบาทเดิม
    • การตัดสินใจเรื่องการเข้าถึงจะถูกบันทึกไว้ในคอนโซลผู้ดูแลของ IdP ทำให้มีบันทึกเดียวที่ตรวจสอบย้อนหลังได้สำหรับคอนเน็กเตอร์ทั้งหมด
    • การตัดขั้นตอนเลือกบัญชีแบบโต้ตอบออกไป ช่วยลดความสับสนของการไหลของข้อมูลระหว่างบัญชีส่วนตัวกับบัญชีองค์กรได้ง่ายขึ้น
  • เป้าหมายของการใช้งาน MCP ในองค์กรคือ เมื่อผู้ใช้ล็อกอินแล้ว ไคลเอนต์จะเชื่อมต่อกับเครื่องมือและข้อมูลที่ได้รับอนุญาตได้โดยไม่มีขั้นตอนเพิ่มเติม

ผลิตภัณฑ์ที่รองรับช่วงแรกและระบบนิเวศ

  • การเปิดตัวครั้งนี้มีผู้ร่วมพัฒนาจากสามกลุ่มคือ ผู้ให้บริการตัวตน ไคลเอนต์ และเซิร์ฟเวอร์

  • ผู้ให้บริการตัวตน

    • Okta เป็นผู้ให้บริการตัวตนรายแรกที่รองรับ
    • องค์กรที่ใช้ Okta สามารถ provision การเข้าถึง MCP ให้กับไคลเอนต์และเซิร์ฟเวอร์ที่รองรับผ่าน Okta’s Cross App Access (XAA)

  • ไคลเอนต์

    • Anthropic นำ EMA ไปใช้ในชั้น MCP แบบแชร์ของ Claude
    • ผู้ดูแลสามารถอนุมัติเซิร์ฟเวอร์ MCP สำหรับผู้ใช้ได้ครอบคลุมทั้ง Claude, Claude Code และ Cowork
    • Visual Studio Code ก็เพิ่มการรองรับ EMA ภายใน IDE เช่นกัน

  • เซิร์ฟเวอร์

    • Asana, Atlassian, Canva, Figma, Granola, Linear และ Supabase รองรับ EMA แล้ว
    • Slack และเซิร์ฟเวอร์อื่น ๆ ก็กำลังเพิ่มการรองรับอยู่
    • Aaron Parecki แห่ง Okta กล่าวว่า การฝังโปรโตคอล Cross App Access เข้าในส่วนขยาย EMA ของ MCP ทำให้ identity กลายเป็นชั้น governance จากศูนย์กลาง มอบการควบคุมด้าน compliance ให้ทีมความปลอดภัย และมอบประสบการณ์ที่ลื่นไหลแก่ผู้ใช้
    • Devdatta Akhawe แห่ง Figma กล่าวว่า เมื่อการนำ MCP ไปใช้เพิ่มขึ้น XAA จะช่วยให้องค์กรขยายการใช้งาน MCP ได้อย่างปลอดภัยง่ายขึ้น
    • Tom Moor แห่ง Linear กล่าวถึงประสบการณ์ที่เมื่อล็อกอินครั้งเดียวแล้ว คอนเน็กเตอร์ MCP ทั้งหมดจะถูกตั้งค่าให้อัตโนมัติ

เอกสารและช่องทางการมีส่วนร่วม

  • ไคลเอนต์ เซิร์ฟเวอร์ และ identity platform สามารถทบทวนสเปกของส่วนขยายและเพิ่มการรองรับมาตรฐานใหม่นี้ในผลิตภัณฑ์ของตนได้
  • Enterprise-Managed Authorization page จัดทำเอกสารข้อกำหนดของลำดับการทำงานสำหรับไคลเอนต์ เซิร์ฟเวอร์ และ authorization server
  • สามารถติดตามการเปลี่ยนแปลงล่าสุดและเอกสารสนับสนุนของ EMA ได้ที่ ext-auth repository และ draft specification
  • การอภิปรายเกี่ยวกับส่วนขยาย การรายงานความเข้ากันได้ และการปรับปรุงแบบวนซ้ำ ใช้ EMA Interest Group
  • EMA เป็นผลงานของชุมชน MCP โดยมีผู้เขียน SEP-990 ผู้ดูแล ext-auth repository และผู้ให้บริการด้าน identity กับ MCP ที่ทดสอบการใช้งานระยะแรกและช่วยผลักดันสเปกเข้ามามีส่วนร่วม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ก่อนจะไปสู่ข้อถกเถียงแบบเดิม ๆ ว่า “MCP ตายแล้ว และ Skills คืออนาคต” จุดที่ MCP มีคุณค่าจริงเหนือกว่า skills/CLI คือการแยก ขั้นตอนการยืนยันตัวตนออกจากหน้าต่างคอนเท็กซ์ของเอเจนต์ และในบางกรณีก็แยกออกไปนอก harness ได้ด้วย
    เรื่องนี้สำคัญมากในมุมความปลอดภัยอยู่แล้ว และยังทำให้ประสบการณ์ใช้งานง่ายขึ้นมากสำหรับผู้ใช้ทั่วไปหรือองค์กรขนาดใหญ่ที่ต้องการนำเครื่องมือ AI มาใช้
    เข้าใจได้ถ้าจะบ่นเรื่องคอนเท็กซ์บวมเกินไปหรือการเรียกใช้เครื่องมือซ้ำซ้อน แต่สถาปัตยกรรมที่จัดการการยืนยันตัวตนแบบนี้มีคุณค่าชัดเจน
    MCP ในอุดมคติอาจให้ประโยชน์ได้มากพอแล้วแม้จะทำหน้าที่เป็นเพียง authentication gateway ที่อยู่หน้าชั้น API

    • ส่วนขยายนี้ยังแสดงให้เห็นข้อดีอื่นของ MCP เมื่อเทียบกับ skills ได้ดีด้วย: การควบคุมจากศูนย์กลาง, ความสะดวกในการใช้งานสำหรับพนักงาน, การตรวจสอบ/คอมพลายแอนซ์, และโมเดลการกระจายใช้งาน
      ตอนนี้วิธี deploy skills ที่ดีที่สุดก็ดูจะเป็นประมาณ “คัดลอกไฟล์นี้ไปใส่ตรงนี้”, “checkout รีโพนี้แล้วเพิ่ม symbolic link”, หรือ “ติดตั้งด้วยคำสั่ง slash”
      แม้จะเรียบง่าย แต่ก็ยังไม่ง่ายเท่ากับแนวทางขยายแบบนี้ในการแจกจ่าย MCP server ใหม่ให้พนักงาน
    • MCP ยังช่วยให้มี audit trail ที่ยอดเยี่ยมได้ด้วย
      ตัวอย่างเช่น ยืนยันตัวตนบัญชี Linear ของลูกค้า 6 รายไว้ทั้ง 6 บัญชี แล้วเลือกว่าจะใช้บัญชีไหนด้วยวิธีที่กำหนดแน่นอนและตรวจสอบย้อนหลังได้ ซึ่งทำให้เกิด การแยกความรับผิดชอบ ได้ด้วย
    • บทเรียนที่แท้จริงคือ MCP ปะทะ skills ไม่ใช่เรื่องแบบต้องเลือกข้าง
      มันเป็นแค่เครื่องมือคนละแบบ และขึ้นอยู่กับความต้องการว่าแบบไหนจะเหมาะกว่าหรือไม่เหมาะกว่า
      คล้ายกับการถามว่าระหว่างมีดกับเลื่อย อะไรดีกว่ากัน
    • นอกจากนี้ MCP ยังช่วยให้ เชื่อมต่อแพลตฟอร์มภายนอกได้โดยไม่ต้องมี runtime environment
      ทุกครั้งที่มีหัวข้อนี้ วิศวกรมักทำเหมือนว่า Claude Code คือแอป AI agent เพียงตัวเดียว แต่จริง ๆ แล้วยังมีกรณีใช้งานอีกมากในหลายอุตสาหกรรมนอกเหนือจากงานเขียนโค้ด
      harness อาจไม่ได้รันบนเครื่องโลคัล แต่อยู่ในคอนเทนเนอร์บนคลาวด์ที่แยกขาดและถูกจำกัด และอาจเป็นสภาพแวดล้อมที่ห้ามรันโค้ดตามอำเภอใจโดยเด็ดขาด
      ถึงอย่างนั้น ถ้าลูกค้าต้องการเชื่อมเครื่องมือเดิมเข้ากับเอเจนต์ MCP ก็เหมาะมาก เพราะให้คอนเนกเตอร์ที่มีการยืนยันตัวตนในตัว ส่วน skills ไม่ได้อยู่ในขอบเขตนี้
    • ผมกำลังสร้างแพลตฟอร์มสำหรับรีวิวร้านอาหารกับเพื่อน ๆ และหลังจากลองผิดลองถูกมาหลายรอบ ก็ดูว่า MCP คือทิศทางที่ใช่
      ผู้ใช้ทั่วไปไม่ได้ไปเปิดไดเรกทอรี Claude แล้ววางไฟล์ skill
      “Connections” เข้าใจง่ายกว่า และการวาง MCP หรือค้นหาจาก marketplace ก็ง่ายกว่า
      ส่วนการที่เอเจนต์จะเข้าถึงสถานที่และรีวิวจะมีประโยชน์จริงไหมนั้นยังไม่แน่ชัด

  • ขอแสดงความยินดีอย่างยิ่งกับผู้ที่สร้างงานนี้จาก Okta, Anthropic, Microsoft, Figma, Linear และที่อื่น ๆ
    แม้แต่คนที่ไม่เชื่อใน MCP ก็น่าจะได้อะไรที่นำไปใช้ได้
    สิ่งนี้ทำงานด้วยรูปแบบโทเค็นใหม่ชื่อ ID-JAG และอยู่ที่ https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
    มันไม่ใช่ของเฉพาะ MCP เลย และสามารถใช้ ID-JAG ได้ทุกที่ที่แอปพลิเคชันซึ่งใช้ผู้ให้บริการ SSO รายเดียวกันจำเป็นต้องแชร์ข้อมูลกันอย่างปลอดภัย

    • บริษัทพวกนี้ทำให้ซอฟต์แวร์และคุณภาพชีวิตแย่ลง ดังนั้นจะบอกว่าน่ายินดีจริง ๆ ก็ฟังดูประชดประชันดี

  • ตอนนี้กำลังพยายามใส่ การยืนยันตัวตนด้วย Microsoft Entra ID ให้กับ MCP server ที่กำลังทำอยู่ แต่พูดตรง ๆ คือรู้สึกเหมือนตัวเองโง่ไปเลย
    ใช้ header WWW-Authenticate เพื่อบอก URL ของ resource metadata ให้กับ client ได้ และผ่านสิ่งนี้ก็สามารถระบุได้ทั้ง Microsoft Entra ที่เป็น authorization server และขอบเขตของการลงทะเบียนแอป
    แต่ระบุ client_id ไม่ได้ และดูเหมือนแนวคิดคือให้แต่ละ client หรือก็คือ agent สร้างขึ้นมาเอง
    แต่ถ้าจะเริ่มล็อกอินผ่าน URL .../authorize ของ Microsoft Entra ก็ต้องมี client_id ที่รู้ล่วงหน้าและตรงกับ app registration ใน Entra ซึ่งค่าที่ client สร้างขึ้นมาเองตามใจไม่มีทางตรงกับ Entra อยู่แล้ว
    ในทางทฤษฎีอาจรองรับ dynamic client registration ได้ แต่แน่นอนว่า Microsoft Entra ไม่รองรับ
    สุดท้ายเลยดูเหมือนเหลือทางเดียวคือต้องทำ dynamic client registration shim ของตัวเองไว้หน้า Microsoft Entra แล้วคืน client_id แบบ static ตัวเดียวกันให้ทุกคน
    เลยรู้สึกว่าหรือจริง ๆ แล้วโปรโตคอลนี้มันควรทำงานได้ใน enterprise โดยไม่ต้องมีทางอ้อมแบบนี้ และผมอาจพลาดอะไรที่ชัดเจนอยู่

    • ดูเหมือนคุณจะไม่ได้พลาดอะไรที่ชัดเจนนะ
      Entra ID ไม่รองรับ dynamic client registration และสถานะของ ecosystem นี้ก็ยังไม่ค่อยดีนัก
      ปกติ MCP OAuth มักจัดการด้วย client แบบดั้งเดิมที่ลงทะเบียนไว้ล่วงหน้า แต่ในความเป็นจริง MCP client จำนวนมากกลับตั้งสมมติฐานว่า dynamic client registration ใช้ได้ และไม่ได้มีตัวเลือกให้ระบุ client_id
      แต่ client บางตัวรองรับ และขอขายของนิดหนึ่ง เครื่องมือของเรา Erato ก็รองรับด้วย: https://erato.chat/docs
      โซลูชันทั่วไปที่ deploy ใน enterprise ก็มักรวมศูนย์การเข้าถึง MCP ผ่านเว็บ UI อยู่แล้ว เลยรองรับแนวทางนี้ได้
      อีกทางเลือกหนึ่งคือใช้ MCP gateway โดยระหว่าง gateway กับ service ใช้ OAuth แบบลงทะเบียนล่วงหน้า และระหว่าง gateway กับ client อนุญาต dynamic client registration ได้
    • เราก็เจอปัญหาเดียวกันเรื่อง client_id และไม่อยากเปิด dynamic client registration ด้วยเหตุผลด้านความปลอดภัย
      สุดท้ายเลยทำให้แอปทำตัวเป็น proxy ให้กับ OAuth flow พร้อม inject client_id ที่ hardcode ไว้
      ฝั่ง MCP client ก็หลอกว่ารองรับ dynamic client registration แต่ข้างในจริง ๆ ใช้ client_id แยกสำหรับ MCP ตามปกติ
      ดูตัวอย่างได้ที่นี่: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • เพิ่งทำเรื่องนี้เสร็จเมื่อวานนี้เอง โดยใจความคือไลบรารีนี้จะรัน MCP server: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      จากนั้นเราก็สร้าง แอปพลิเคชัน authentication broker ที่จัดการการลงทะเบียน client ด้วย OpenID และสร้าง JWT
      ผลลัพธ์คือเราสามารถตัดสินได้ว่าอนุญาตให้ใช้เครื่องมือหรือให้สิทธิ์อะไรบ้าง โดยอิงจากแผนกของพนักงานหรือเกณฑ์อื่น ๆ
      สุดท้ายแล้ว dynamic client registration ยังจำเป็นอยู่
    • เมื่อไม่นานมานี้ FusionAuth ได้เขียนเอกสารวิธีใช้ pre-registered client ไว้: https://fusionauth.io/docs/extend/examples/controlling-acces...
      พวกเขายังกำลังพิจารณา CIMD ซึ่งเป็นเหมือนพี่น้องรุ่นใหม่และดีกว่าของ DCR และมีการพูดคุยกันอย่างคึกคัก แต่ยังไม่มีให้ใช้: https://github.com/FusionAuth/fusionauth-issues/issues/3230
      อีกทางเลือกนอกเหนือจาก proxy ที่คุณเสนอคือสร้าง Entra client_id ใหม่สำหรับ MCP client แต่ละตัวพร้อมเปิด PKCE ไว้ ผ่าน developer portal หรือช่องทางคล้ายกัน แล้วให้ผู้ใช้เอาค่านั้นไปตั้งค่าใน client เอง
      ผมหาคำสั่ง CLI สำหรับเรื่องนี้เจอที่นี่ และน่าจะมี API ด้วย: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      การตั้งค่า Claude Code อยู่ที่ https://code.claude.com/docs/en/mcp และการตั้งค่า ChatGPT อยู่ที่ https://developers.openai.com/api/docs/guides/developer-mode
      การลงทะเบียน client ล่วงหน้าอาจไม่ดีที่สุดสำหรับนักพัฒนา แต่ก็ยังพอยอมรับได้ และในสเปกก็ถือเป็นแนวทางระดับ first-class: https://modelcontextprotocol.io/specification/2025-11-25/bas...
      ถ้าผู้ใช้หลักคือพนักงานภายในและพวกเขาสามารถทำตามคู่มือการตั้งค่าเพื่อเข้าถึง MCP server ได้ วิธีนี้ก็ใช้ได้
      แต่ถ้ากลุ่มเป้าหมายเป็นการเชื่อมต่อสาธารณะวงกว้างที่ไม่ใช่นักพัฒนา แบบนั้นมันก็ไม่ค่อยยอมรับได้แน่นอน และตรงนั้นเองก็เป็นทั้งพลังสำคัญและโอกาสใหญ่ของ MCP

  • ฉันเป็นหนึ่งในคนที่สร้างสิ่งนี้ร่วมกับ Anthropic, Okta และพาร์ตเนอร์ MCP หลายราย
    รู้สึกตื่นเต้นมากที่รูปแบบนี้กำลังเป็นรูปเป็นร่างใน Claude และตอนนี้ในสเปก MCP นั้น EMA ได้กลายเป็นส่วนขยายที่เสถียร แล้ว ก็อยากให้มีการนำไปใช้กับผู้ให้บริการตัวตนและไคลเอนต์รายอื่น ๆ มากขึ้น
    ถ้ามีข้อเสนอแนะก็ฝากไว้ที่นี่ได้เลย และอยากฟังประสบการณ์ใช้งานจริงรวมถึงวิธีปรับปรุงอยู่เสมอ

    • ไม่ได้ตามมานานเลย
      ไม่ได้ดู MCP มาสักพัก แต่สิ่งนี้ดูเข้ากันได้ดีทีเดียวกับการทำให้ MCP ปลอดภัยขึ้นในองค์กร และช่วยแก้ จุดอ่อนของการลงทะเบียนไคลเอนต์แบบไดนามิก
      ตอนนี้ผู้ให้บริการตัวตนและองค์กรสามารถตั้งค่าไคลเอนต์กับ approved redirect URI ได้โดยตรง จึงช่วยบรรเทาการโจมตีที่อาศัย DCR ในวงกว้างขึ้น เช่น confused deputy attack หรือ phishing
      อีกข้อดีใหญ่คือช่วยลดตรรกะด้าน authorization ที่เซิร์ฟเวอร์ MCP ต้อง implement เอง ในกรณีที่ผู้ให้บริการตัวตนหรือองค์กรไม่รองรับ DCR
      ข้อเสียคือสำหรับการใช้งานฝั่งผู้บริโภคก็ดูเหมือนว่ายังต้องใช้ DCR อยู่
      อาจแก้ได้ถ้าผู้ให้บริการ OAuth ฝั่งผู้บริโภคอย่าง GitHub, GitLab, Google รองรับการลงทะเบียน MCP client/server แบบ static และไคลเอนต์ฝัง client_id แบบ static ไว้ พร้อมให้ผู้ใช้ล็อกอินกับผู้ให้บริการตัวตนนั้นและจัดการการเชื่อมต่อได้เอง
      โดยรวมแล้ว XAA/EMA ดูเหนือกว่า DCR มากทั้งด้านความปลอดภัยและการใช้งาน
      ส่วนที่น่ากังวลก็แก้ได้ง่ายกว่า DCR มาก และมีผลกระทบด้านความปลอดภัยน้อยกว่า เพราะผู้โจมตีไม่สามารถลงทะเบียนไคลเอนต์ของตัวเองได้ และยังลดกับดักที่นักพัฒนาเซิร์ฟเวอร์ MCP อาจพลาดได้ด้วย
    • ยอดเยี่ยมมากสำหรับ “แอป” ทั่วไป แต่สำหรับเรา สิ่งที่ต้องการมากคือวิธีให้ผู้ใช้โต้ตอบแบบเอเจนต์ได้โดยมีแรงเสียดทานต่ำกว่า โดยไม่ต้องตั้งค่า MCP ก่อน
      ถ้ามีอะไรอย่าง เซสชันชั่วคราว หรือ token store แบบ out-of-band ก็น่าจะดี
      use case คือในกระบวนการขาย ผู้ซื้อและผู้ขายต้องแลกเปลี่ยนข้อมูลจำนวนมากและต้องวิเคราะห์ ซึ่งการวิเคราะห์นี้กำลังกลายเป็นลักษณะเอเจนต์มากขึ้นเรื่อย ๆ
      ปัญหาของ MCP คือแรงเสียดทานในการตั้งค่าเริ่มต้นสูงกว่าการที่ผู้ใช้ล็อกอินเองแล้วดึงข้อมูลที่ต้องการมามาก
      MCP เหมาะกับการโต้ตอบที่เป็นประจำและเกิดบ่อย แต่มีปัญหามากกับเซสชันแบบรวดเร็วใช้ครั้งเดียว
      ถ้าใน Claude สามารถพูดว่า “ดึงเอกสารจาก X, Y, Z มา” แล้ว Claude เข้าเว็บเหล่านั้นได้ โดยเว็บส่งกลับข้อมูลผู้ใช้พื้นฐานและลิงก์ล็อกอินที่ผู้ใช้เปิดในเบราว์เซอร์ได้ ก็คงดี
      จากนั้นผู้ใช้ยืนยันตัวตนในเบราว์เซอร์ และ callback ส่งคืนโทเคนใช้ครั้งเดียวที่มีอายุสั้นและไม่ซ้ำกัน เพื่อนำไปแลกในการเรียกขอของเว็บไซต์ภายหลัง
      แบบนี้จะช่วยยืนยันตัวตนผู้ใช้ได้รวดเร็ว พร้อมรักษาสถานะเซสชันระหว่างทำงานไว้ได้ด้วย
    • สงสัยว่ามีการพูดคุยกับทีม Microsoft Entra หรือ Azure AD อยู่ไหม
      อยากรู้ว่าพอจะคาดหวังได้ในเร็ว ๆ นี้หรือว่าจะต้องใช้เวลาอีกพอสมควร
    • ขอแสดงความยินดีกับการเปิดตัว
      ดูเหมือน use case หลักจะเป็นพนักงานในบริษัท แต่สงสัยว่ามันมีคุณค่าแบบเดียวกันสำหรับ ผู้ใช้ที่ไม่ได้ถูกรวมศูนย์ อย่างลูกค้าหรือผู้ใช้ฟรีแบบพรีเมียมไหม
      ฉันยังนึกภาพไม่ค่อยออก เลยอยากรู้ว่าตัวเองพลาดอะไรไปหรือเปล่า และเหมือนจะเห็นคำตอบที่เกี่ยวข้องอยู่ที่นี่: https://news.ycombinator.com/item?id=48594381
    • อยากยืนยันว่าตอนนี้ยังไม่ใช่สิ่งที่ใช้งานได้จริง และยังอยู่ใน ขั้น SEP ใช่ไหม

  • นี่ดีมากจริง ๆ
    ช่วงหลายเดือนที่ผ่านมาโชคดีที่ได้ทำงานกับคนฝั่ง MCP ใน SEP หลายตัวและ SDK ทดลองของ Go
    แต่ก่อนฉันเป็นพวกขี้สงสัยที่พูดว่า “มันก็แค่ API”, “สร้าง abstraction ขึ้นมาอีกอันแล้วสินะ”
    สิ่งที่คนมักพลาดคือ “P” ใน MCP ทำให้เข้าใจผิด
    เวลาสร้างแอปแบบดั้งเดิม คุณต้องทำฟอร์ม, UI, การจัดการ request/response, ช่องทางสองทิศทาง, งานที่ใช้เวลานาน, authentication ฯลฯ
    แต่ถ้าใช้ MCP ชั้นกลางร่วมเหล่านี้ 80% จะถูกจัดการให้แล้ว ดังนั้น MCP จึงเป็นได้ทั้งโปรโตคอล แต่ในความเป็นจริงก็ใกล้เคียงกับ application framework มาก
    การรวม authentication เข้ามาเป็นการยกระดับครั้งใหญ่ และน่าตื่นเต้นกับสิ่งเจ๋ง ๆ ที่จะตามมา

  • รู้สึกแปลกดีที่งานที่ฉันทำถูกมองเห็นจากภายนอก
    ฉันรับผิดชอบ implementation ฝั่ง RAS ของ flow นี้ที่ Atlassian
    flow นี้น่าจะมีการปรับปรุงแบบ iterative อีกแน่นอน ทั้งเรื่อง CIMD, การรองรับ tenancy ที่ดีขึ้น และอื่น ๆ
    ทุกคนจาก Anthropic, Okta และ Atlassian ที่ช่วยส่งมอบสิ่งนี้ยอดเยี่ยมมาก

  • น่าจะรองรับเว็บเพื่อให้สามารถออก คุกกี้ระยะยาว ได้เลย
    ฉันต้อง hack สเปกให้ส่งคุกกี้ผ่าน OAuth handshake เพื่อจะทำสิ่งนี้โดยไม่มี OAuth server
    การไม่ยอมให้ทำแบบนี้มันน่าหงุดหงิดจริง ๆ
    ถ้าไม่มีคุกกี้ก็เปิดเว็บเพจ พอตั้งค่าคุกกี้เสร็จก็ปิดแล้วบันทึกไว้ได้เลย
    ฉันถึงขั้นเขียนมินิบุ๊ก 80 หน้าเกี่ยวกับ MCP แต่ก็ยังหงุดหงิดไม่รู้จบ

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

  • อ่านหลายรอบแล้ว และมันมีประโยชน์ชัดเจน
    ผู้ให้บริการตัวตนสามารถรวมศูนย์ทั้ง auditing และ access control ไว้ที่จุดเดียว และยังอาจทำงานเหมือน proxy API gateway ที่รับหน้าที่ token exchange เมื่อจำเป็น
    นี่เป็นแนวทางที่ผู้เล่นรายอื่นในวงการนี้ก็นำไปใช้เช่นกัน
    ส่วนตัวฉันยังรู้สึกไม่ค่อยสบายใจเล็กน้อยกับการที่ผู้ให้บริการตัวตนมอบสิทธิ์ของฉันให้ไคลเอนต์ทั้งที่ฉันไม่รับรู้อยู่ตลอด
    อาจเป็นเพราะฉันชินกับ flow ที่มีผู้ใช้อยู่ในเบราว์เซอร์มากกว่า และมันให้ความรู้สึกเหมือนกำลังค่อย ๆ พัฒนาไปสู่การรวมศูนย์การเข้าถึงสำหรับเครื่องมากขึ้น
    ในสภาพแวดล้อมแบบ enterprise เรื่องนี้อาจยอมรับได้ เพราะตัวตนเป็นของบริษัทมากกว่าของปัจเจกบุคคล
    แต่การเอาไปผนวกเข้ากับฝั่ง customer identity เป็นโจทย์ที่ยากคนละแบบ และคงไม่ง่ายที่จะสร้างความเชื่อใจลักษณะนี้ระหว่างผู้ให้บริการตัวตน, ไคลเอนต์ และ resource authorization server

    • ไม่มีอุปสรรคเชิงทฤษฎีที่ทำให้ integration นี้ใช้กับฝั่งผู้บริโภคไม่ได้
      ตัวอย่างเช่น ถ้าคุณล็อกอิน GitHub อยู่ ก็อาจสร้าง ความสัมพันธ์แบบเชื่อใจ ที่ทำให้ล็อกอิน Sentry อัตโนมัติได้
      ยังมีงานต้องทำอีกมาก แต่ตอนนี้ use case ที่ชัดที่สุดก็อย่างที่บอกคือฝั่ง enterprise
      ผู้ดูแลระบบไม่อยากให้พนักงานแต่ละคนต้องไปคลิกนั่นคลิกนี่แล้วเลือกข้อมูลรับรองแบบสุ่มเอง

  • ใน C1 ทั้งการใช้ MCP ภายในและ MCP Gateway ในตัวผลิตภัณฑ์ต่างก็มีปัญหาใหญ่เรื่อง การยืนยันตัวตนของ MCP มาตลอด ดังนั้นดีใจมากที่จะได้สิ่งนี้เข้ามา
    วันนี้ C1 เปิดตัวการรองรับให้ทำงานเป็นผู้ให้บริการ EMA ID และออกโทเค็นแบบกำหนดขอบเขตและมีอายุสั้น
    ตอนนี้อยากเชื่อมต่อกับ Linear และ MCP อื่น ๆ ที่เราใช้ เพื่อจะได้หลุดพ้นจากขั้นตอน OAuth แบบวนซ้ำ
    Claude ทำเรื่องแบบนี้ได้อย่างกับเวทมนตร์มาสักพักแล้วกับคอนเน็กเตอร์ในตัวบางตัว อย่างน้อยก็ใน Slack และประสบการณ์ใช้งานก็ดีมาก
    เพื่อเปิดเผยข้อมูล ผมเป็น VPE ของ C1 และได้เขียนเอกสารอธิบายแนวทางไว้สำหรับคนที่อยากลงลึก: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • ยังไม่ค่อยเข้าใจว่ามันมีข้อดีเหนือกว่า OAuth ทั่วไปอย่างไร
    น่าจะต้องมีตัวอย่างเปรียบเทียบ authorization flow

    • ใน OAuth ทั่วไป ผู้ใช้ปลายทางจะยินยอมแยกกันเป็นรายแอปว่าจะให้แชร์ข้อมูลของตัวเองกับแต่ละแอปหรือไม่
      มันสมเหตุสมผลในกรณีใช้งานแบบผู้บริโภค ซึ่งผู้ใช้ปลายทางเป็นเจ้าของข้อมูลของตัวเอง
      แต่ในกรณีการใช้งานทางธุรกิจจำนวนมาก ผู้ที่ควรตัดสินใจเรื่องการแชร์ข้อมูลและควบคุมการเข้าถึงไม่ใช่ผู้ใช้ปลายทาง แต่เป็นบริษัท
      ถ้าผมเป็นพนักงานของ Acme ผมไม่ควรเป็นคนตัดสินใจว่าจะเชื่อมข้อมูล Google Drive ของ Acme เข้ากับ Claude หรือ ChatGPT หรือไม่ แต่ฝ่าย IT ควรเป็นผู้ตัดสินใจ
      Enterprise-Managed OAuth หรือ Cross App Access (XAA) นำโมเดลการแชร์ที่ผู้ดูแล IT ควบคุมจากศูนย์กลางเข้ามาอยู่ในเฟรมเวิร์ก OAuth เพื่อให้ทำงานร่วมกับ ecosystem เดิมได้
      อีกทั้งเมื่อย้ายการจัดการความยินยอมในการแชร์ข้อมูลจากพนักงานไปให้ผู้ดูแล IT ก็มีข้อดีด้านประสบการณ์ผู้ใช้มากเช่นกัน
      พนักงานไม่ต้องผ่านหลายขั้นตอนของ OAuth เพื่อเชื่อมต่อบัญชี และผู้ดูแล IT ก็สามารถตั้งค่าการควบคุมการแชร์ไว้ล่วงหน้าได้แล้ว
      ลองนึกถึงสถานการณ์ที่ในวันแรกของการเข้าทำงาน Slack เชื่อมกับ Zoom, Drive, Calendar ฯลฯ ไว้ให้แล้ว
    • ข้อดีก็คือผู้ใช้ไม่จำเป็นต้องควบคุมหรือยินยอมว่าแอปใดบ้างจะได้รับอนุญาตให้แชร์ข้อมูลของตนระหว่างกัน
      เพราะการตัดสินใจมอบสิทธิ์การเข้าถึงถูกกำหนดไว้ที่ ระดับนโยบายของผู้ให้บริการ ID
      ผู้ใช้อาจไม่มีทางรู้เลยตลอดไปด้วยซ้ำว่ามีแอปหรือบริการใดบ้างที่ได้รับอนุญาตให้แชร์ข้อมูลของตน
      เดี๋ยวก่อน นั่นเป็นข้อดีจริง ๆ เหรอ? ;-)