LiteLLM v1.93.0 เพิ่มโหมด auth ใหม่สามแบบให้ MCP — true_passthrough, oauth_delegate และ dcr_bridge ที่บังคับ S256

วันที่ 19 กรกฎาคม 2026 (ตาม timestamp ของ GitHub API — หน้า release notes ในเอกสารระบุเป็นวันที่ 18) LiteLLM ปล่อยเวอร์ชัน v1.93.0 ออกมาเป็น stable release ที่รวม PR ไว้ราว 150 รายการ

LiteLLM คือ proxy/gateway ที่หลายองค์กรวางไว้หน้าโมเดลทั้งหมดที่ใช้ เพื่อให้ทีมต่าง ๆ เรียกผ่านอินเทอร์เฟซเดียว มีที่เก็บ log ค่าใช้จ่ายรวม และมีจุดบังคับนโยบายจุดเดียว รีลีสนี้มีของหลายอย่าง แต่ไล่ดูรายการ PR แล้วชัดว่าน้ำหนักงานส่วนใหญ่ลงไปที่เรื่องเดียว — การยืนยันตัวตนของ MCP

ปัญหาที่โหมดใหม่สามแบบพยายามแก้

เมื่อ gateway ยืนอยู่ระหว่าง agent กับ MCP server คำถามที่ตอบยากคือ ใครเป็นเจ้าของ credential ที่ใช้คุยกับ MCP server ปลายทาง

วิธีดั้งเดิมคือให้ gateway ถือ credential ไว้เอง ซึ่งง่ายแต่แลกมาด้วยข้อเสียที่หนัก: MCP server ปลายทางจะเห็นทุกคำขอเป็น “gateway” เหมือนกันหมด แยกไม่ออกว่าผู้ใช้จริงคือใคร สิทธิ์ระดับผู้ใช้ที่ตั้งไว้ฝั่ง MCP server จึงบังคับไม่ได้ และ audit log ปลายทางก็เหลือชื่อเดียว

v1.93.0 เพิ่มทางเลือกฝั่งตรงข้าม — โหมดที่รีลีสโน้ตเรียกว่า client-forwarded auth modes สามแบบ:

• true_passthrough — ส่ง credential ของ client ทะลุไปยัง MCP server ตรง ๆ gateway ไม่แตะ
• oauth_delegate — ให้ gateway ทำหน้าที่ delegate ใน flow ของ OAuth แทนที่จะเป็นเจ้าของ token
• dcr_bridge — ตัวที่ซับซ้อนที่สุด ทำ bridge สำหรับ Dynamic Client Registration โดยมี discovery facade, register relay และการ relay ขั้น authorize/token

สองตัวแรกมาจาก PR #31989 ส่วน dcr_bridge เป็นงานที่กระจายอยู่ในหลาย PR ต่อเนื่องกัน (#32745, #32747, #32753, #32748, #32794) รวมถึง sealed envelope module สำหรับเก็บ credential ที่ฝั่ง client ถือไว้ และมี PR #32824 ที่ทำให้ client แบบ oauth_delegate เข้ามาผ่าน dcr_bridge ได้ด้วย bearer ตัวเดียว

จุดที่ควรชม: หัวข้อ PR #32747 ระบุตรง ๆ ว่า “with mandatory S256” — คือบังคับใช้ code challenge แบบ SHA-256 ใน PKCE โดยไม่เปิดทางให้เลือก plain ซึ่งเป็นการตัดสินใจที่ถูกต้อง เพราะ plain แทบไม่ให้การป้องกันอะไรเลยและมักถูกปล่อยเปิดไว้ “เผื่อความเข้ากันได้”

มีอีก PR ที่อ่านแล้วเห็นภาพว่าของจริงมันยุ่งแค่ไหน — #32735 แก้บั๊กที่ระบบยังเผลอบันทึก DCR client ลงในแถวของเซิร์ฟเวอร์ที่ตั้งเป็น true_passthrough และ oauth_delegate ทั้งที่สองโหมดนี้ทั้งหมดคือ อย่า เก็บอะไรไว้ฝั่ง gateway

ฝั่งองค์กรยังได้ โปรไฟล์ entra_obo สำหรับ token exchange แบบ on-behalf-of (#31983) พร้อมตัวเลือกใน UI และ API (#32144) — แปลว่าองค์กรที่ยืนอยู่บน Microsoft Entra ID สามารถให้ agent เรียก MCP server ในนามของผู้ใช้จริงได้ ตามสิทธิ์ที่ผู้ใช้คนนั้นมีจริง ๆ

ที่เหลือในรีลีส

• provider ใหม่ Meta Model API พร้อมรองรับ muse-spark-1.1 แบบ day-0 (#32701)
• รองรับโมเดลใหม่หลายตัว: GPT-5.6 (sol/terra/luna), metadata และราคาของ Grok-4.5, ราคาราย region ของ Azure GPT-5.6, OpenAI Realtime 2.1 และ Google Cloud Chirp 3 STT
• จำกัด RPM แยกราย tag บนคีย์เดียว (#31502) — ก่อนหน้านี้ถ้าจะให้ทีม A กับทีม B มีเพดานคนละค่า ต้องออกคีย์แยก ตอนนี้ใช้คีย์เดียวแล้วตั้งเพดานตาม tag ได้
• งานด้านความปลอดภัยเสริม: hash คีย์ที่มี prefix Bearer ใน spend log ให้ถูกต้อง, ตรวจสอบชื่อ secret เข้มขึ้น และปิดบัง credential ใน response ของ guardrail
• งาน UI: ย้ายจาก Radix ไป Base UI primitives และแปลง dashboard ไปใช้ shadcn/recharts

มุมมอง AI Curator

รีลีสนี้ไม่ใช่ข่าวที่จะได้ขึ้นหน้าแรกที่ไหน แต่มันบอกอะไรบางอย่างเกี่ยวกับว่า MCP กำลังอยู่ตรงไหนของเส้นทางสู่การใช้งานจริง

ปีที่ผ่านมาบทสนทนาเรื่อง MCP วนอยู่กับ “ต่ออะไรได้บ้าง” — เชื่อม Slack เชื่อม GitHub เชื่อมฐานข้อมูล ยิ่งเยอะยิ่งดี รีลีสแบบนี้เป็นสัญญาณว่าคำถามเปลี่ยนไปแล้วเป็น “แล้วใครได้รับอนุญาตให้ทำอะไรบ้าง และเรารู้ได้ยังไง” ซึ่งเป็นคำถามที่โผล่มาเสมอเมื่อของเล่นเริ่มถูกเอาไปวางในองค์กรจริง โปรโตคอลใหม่แทบทุกตัวเดินเส้นนี้เหมือนกัน ต่างกันแค่ว่าใช้เวลานานแค่ไหนกว่าจะถึง

มันยังเชื่อมกับข่าว Smartsheet ที่เราเขียนถึงเมื่อเช้านี้ พอดี — ฝั่งนั้นคือผู้ให้บริการ SaaS เปิด remote MCP server ระดับ production ฝั่งนี้คือชั้น gateway ที่องค์กรจะใช้ต่อเข้าไปโดยยังรักษาตัวตนของผู้ใช้ไว้ได้ สองข่าวนี้คือสองด้านของปัญหาเดียวกัน และการที่มันมาในสัปดาห์เดียวกันไม่น่าจะเป็นเรื่องบังเอิญ

สำหรับทีมในไทยที่กำลังจะเอา agent ไปต่อกับระบบภายในองค์กร ประเด็นที่ควรหยิบไปใช้จริงคือ อย่าให้ gateway เป็นเจ้าของ credential ถ้าเลี่ยงได้ เพราะรูปแบบนั้นทำให้สิทธิ์ทั้งหมดยุบรวมเป็นตัวตนเดียว ซึ่งเป็นปัญหาทั้งตอนออกแบบสิทธิ์และตอนที่มีเหตุแล้วต้องสืบว่าใครทำอะไร โหมดอย่าง oauth_delegate และ entra_obo มีไว้เพื่อสิ่งนี้ — องค์กรที่ใช้ Microsoft 365 อยู่แล้ว (ซึ่งในไทยคือแทบทุกองค์กรขนาดกลางขึ้นไป) ได้ของที่ต่อเข้ากับ Entra ID เดิมโดยไม่ต้องสร้างระบบสิทธิ์ชุดที่สองขึ้นมาคู่ขนาน

ข้อสังเกตปิดท้ายที่ควรพูดอย่างเป็นธรรม: ฟีเจอร์กลุ่มนี้เพิ่งลงในรีลีสแรก และรายการ PR เองก็มีทั้งฟีเจอร์และการตามแก้บั๊กของฟีเจอร์นั้นปนกันอยู่ในรีลีสเดียว (อย่าง #32735 ที่กล่าวถึงข้างบน) ทีมที่จะเอาไปใช้กับระบบที่แตะข้อมูลจริงควรทดสอบ flow ทั้งเส้นด้วยตัวเองก่อน มากกว่าจะเชื่อว่าเปิดสวิตช์แล้วจบ — โค้ดด้าน auth เป็นโค้ดประเภทที่บั๊กไม่ค่อยแสดงตัวออกมาเป็น error แต่แสดงตัวเป็นการอนุญาตที่ไม่ควรอนุญาต

แหล่งข่าว

• LiteLLM v1.93.0 — GitHub Releases
• LiteLLM Release Notes — เอกสารทางการ
• LiteLLM MCP Gateway — เอกสาร