2026 में MCP ऑथेंटिकेशन

Model Context Protocol (MCP) ने इस बात को बदल दिया है कि एजेंट्स (agents) सर्वर से कैसे बात करते हैं। इसकी शुरुआत कैलकुलेटर जैसे लोकल टूल्स से हुई थी। अब यह रिमोट सर्वर पर चलता है। इस बदलाव ने ऑथेंटिकेशन (authentication) को एक आवश्यकता बना दिया है।

यदि आप अपने MCP सर्वर में OAuth जोड़ना चाहते हैं, तो एक बदलते लक्ष्य (moving target) के लिए तैयार रहें। इसका स्पेसिफिकेशन (spec) हर कुछ महीनों में बदल जाता है। अलग-अलग एजेंट्स नियमों के अलग-अलग वर्ज़न का उपयोग करते हैं।

MCP ऑथेंटिकेशन की वर्तमान स्थिति यहाँ दी गई है।

मुख्य बदलाव

आपका MCP सर्वर एक ऑथोराइजेशन सर्वर (authorization server) नहीं है। यह एक रिसोर्स सर्वर (resource server) है।

अतीत में, स्पेसिफिकेशन सर्वरों को टोकन और लॉगिन संभालने के लिए मजबूर करता था। इससे सर्वर भारी हो जाते थे और उन्हें स्केल करना कठिन हो जाता था। Aaron Parecki और Christian Posta जैसे विशेषज्ञों ने इस बात की ओर इशारा किया। उनका तर्क था कि MCP सर्वरों को केवल टोकन को वैलिडेट (validate) करना चाहिए।

आज, मानक (standard) इस फ्लो (flow) का पालन करता है:

• एक अन-ऑथेंटिकेटेड (unauthenticated) रिक्वेस्ट को 401 एरर मिलता है। • एरर क्लाइंट को बताता है कि रिसोर्स मेटाडेटा (resource metadata) कहाँ मिलेगा। • क्लाइंट सही ऑथोराइजेशन सर्वर (जैसे Okta या Keycloak) को ढूँढता है। • क्लाइंट एक टोकन प्राप्त करता है और उसे आपके MCP सर्वर को प्रस्तुत करता है। • आपका सर्वर टोकन को वैलिडेट करता है और टूल चलाता है।

विखंडन (Fragmentation) की समस्या

हालाँकि एक मानक मौजूद है, लेकिन हर एजेंट इसे अलग तरह से लागू करता है।

• Claude Desktop: पूरा OAuth फ्लो चलाता है। • Claude API: इसके लिए आपको अपना स्वयं का bearer token पास करना आवश्यक है। • ChatGPT: रजिस्ट्रेशन के लिए CIMD का उपयोग करता है और नवीनतम स्पेसिफिकेशन का समर्थन करता है। • Gemini: Google Cloud IAM और API keys का उपयोग करता है। • VS Code: GitHub और Entra प्रोवाइडर्स का समर्थन करता है।

इसका मतलब है कि एक एजेंट के लिए बनाया गया सर्वर दूसरे पर विफल हो सकता है। एक वेंडर पूरे लॉगिन फ्लो की आवश्यकता कर सकता है, जबकि दूसरा आपसे स्वयं टोकन प्रबंधित करने की अपेक्षा कर सकता है।

डेवलपर्स के लिए तीन सबक

  1. रिसोर्स सर्वर मॉडल को लक्षित करें। आइडेंटिटी प्रोवाइडर (identity provider) बनने की कोशिश न करें। मेटाडेटा प्रदान करने और ऑडियंस को वैलिडेट करने के लिए RFC 9728 का उपयोग करें।

  2. दो दुनियाओं का समर्थन करें। अपने सर्वर को "bring your own token" API कॉल्स और पूर्ण OAuth फ्लो, दोनों को संभालने के लिए बनाएँ।

  3. निरंतर अपडेट की अपेक्षा करें। स्पेसिफिकेशन अभी भी विकसित हो रहा है। OAuth 2.1 अभी भी एक ड्राफ्ट है, और MCP प्रोटोकॉल अभी भी अपनी जगह बना रहा है।

अभी MCP सर्वर बनाना कठिन है। नियम तेज़ी से बदलते हैं। यदि आप लचीले बने रहते हैं और रिसोर्स सर्वर मॉडल पर टिके रहते हैं, तो आप इन बदलावों के बीच बने रहेंगे।

स्रोत: https://dev.to/0ndreu/mcp-authentication-in-2026-how-oauth-flipped-the-servers-role-and-why-every-agent-differs-11fm

वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi