Claude में MCP कनेक्टर्स का OAuth झंझट खत्म करने की Anthropic की नई व्यवस्था

Anthropic ने Claude के Model Context Protocol (MCP) कनेक्टर्स के लिए Enterprise-Managed Authorization (EMA) को आम तौर पर उपलब्ध कर दिया है। 24 अगस्त 2026 की रिपोर्टिंग के अनुसार, इस बदलाव से कनेक्टर की अनुमति देने का काम हर कर्मचारी के लिए अलग-अलग OAuth प्रक्रिया के बजाय कंपनी के मौजूदा identity और access-management सिस्टम से किया जा सकेगा। 3943

MCP एक खुला मानक है, जो AI assistants को बाहरी टूल, कारोबारी ऐप, डेटा रिपॉजिटरी और development environments से जोड़ता है। 12 EMA का उद्देश्य इन कनेक्शन्स को enterprise स्तर पर provision और govern करना है—बिना संगठन की केंद्रीय access policies को कमजोर किए।

कर्मचारियों और IT admins के लिए क्या बदला?

पहले प्रक्रिया के दो अलग चरण होते थे:

1. IT admin संगठन के लिए किसी कनेक्टर को enable या approve करता था।
2. इसके बाद हर कर्मचारी को संबंधित सेवा में अलग से sign in करके उसका OAuth consent flow पूरा करना पड़ता था।

EMA में admin कंपनी के identity provider के जरिए कनेक्टर और उसकी access policy configure करता है। जिन कर्मचारियों को संगठन के मौजूदा groups या policies के आधार पर अनुमति मिली है, वे अपने पहले से सक्रिय single sign-on (SSO) session से approved कनेक्टर इस्तेमाल कर सकते हैं। उन्हें अलग browser redirect या हर कनेक्टर के लिए नई consent स्क्रीन पूरी नहीं करनी पड़ती। 4962

इसका मतलब यह नहीं है कि access बिना नियंत्रण के मिल जाता है। संगठन का identity provider ही authorization का केंद्रीय स्रोत बना रहता है। Admin यह तय कर सकते हैं कि किन users या groups को access मिले और जरूरत पड़ने पर उसी centralized policy system से access हटाया भी जा सकता है। 4142

Identity-provider आधारित flow कैसे काम करता है?

इसके पीछे MCP Enterprise-Managed Authorization extension और Identity Assertion JWT Authorization Grant profile का इस्तेमाल होता है। सरल रूप में flow इस तरह है:

1. कर्मचारी संगठन के मौजूदा SSO सिस्टम से sign in करता है।
2. Identity provider signed identity assertion के रूप में एक JSON Web Token (JWT) जारी करता है।
3. Claude यह assertion MCP connector के authorization server को भेजता है।
4. Authorization server assertion की वैधता जांचता है और, यदि संगठन की policy access की अनुमति देती है, तो connector का सामान्य access token जारी करता है।
5. Claude उस token की मदद से approved MCP server तक पहुंच बनाता है।

कर्मचारी को connector का अपना OAuth consent process दोहराना नहीं पड़ता, क्योंकि connector को user की enterprise identity और authorization context के बारे में सत्यापित की जा सकने वाली जानकारी मिल जाती है। 4963

Okta इस pattern को Cross App Access (XAA) के जरिए लागू करता है। XAA, identity-provider-mediated approach का Okta implementation है। MCP extension का उद्देश्य एक खुली protocol layer देना है, ताकि हर संगठन को किसी एक proprietary connector mechanism पर निर्भर न रहना पड़े। 3538

Claude, Claude Code और Cowork में कवरेज

MCP project की घोषणा के अनुसार, Anthropic ने इस extension को अपनी shared MCP layer में लागू किया है। इससे admins Claude, Claude Code और Cowork में MCP servers के लिए एक समान authorization model अपना सकते हैं। 62

इसका अर्थ है कि interactive Claude use, developer workflows और desktop या agent-oriented कामों में connector access को एक ही enterprise policy framework से नियंत्रित करने का लक्ष्य रखा गया है।

Claude Code में MCP configuration के लिए अलग enterprise controls भी मौजूद हैं। Anthropic के अनुसार managed policy settings tool permissions, file-access restrictions और MCP server configurations लागू कर सकती हैं। इनमें संगठन द्वारा नियंत्रित server lists भी शामिल हैं। 13 इसलिए EMA identity और authorization handoff को संभालता है, जबकि managed Claude Code settings यह सीमित कर सकती हैं कि users किन MCP servers को configure कर सकते हैं।

Anthropic की platform documentation organization के identity provider से मिलने वाले short-lived OIDC credentials का भी उल्लेख करती है। इनका इस्तेमाल workloads को authenticate करने के लिए long-lived static API keys के विकल्प के रूप में किया जा सकता है। हालांकि यह enterprise identity की इसी व्यापक दिशा से जुड़ा विषय है, इसे connector-specific EMA flow के साथ मिलाकर नहीं देखना चाहिए। 18

अभी कौन-से MCP connectors समर्थित हैं?

उपलब्ध सामग्री Okta program से जुड़े शुरुआती MCP providers के तौर पर इन नामों की पुष्टि करती है:

• Asana
• Atlassian
• Canva
• Figma
• Granola
• Linear
• Supabase

3856

हालांकि, उपलब्ध evidence से 24 अगस्त 2026 के general-availability release में समर्थित हर connector की निर्णायक सूची स्थापित नहीं होती। इसी तरह, मौजूदा connectors और planned additions के बीच भी भरोसेमंद, पूर्ण अंतर स्पष्ट नहीं है। Okta के documented XAA implementation के अलावा अन्य identity providers की पूरी सूची भी उपलब्ध सामग्री में नहीं दी गई है।

इसलिए कंपनियों को feature को universally supported मानने से पहले connector-level availability और identity-provider compatibility की पुष्टि करनी चाहिए।

EMA को अपनाने का दायरा केवल Okta तक सीमित नहीं है। Identity-provider vendors को संबंधित assertions जारी करने होंगे, जबकि MCP connector developers के authorization servers को उन assertions को स्वीकार और validate करना होगा। Anthropic की connector documentation उन developers के लिए आवश्यकताओं का वर्णन करती है, जो अपने MCP servers को enterprise identity assertions स्वीकार करने और अलग user-consent step के बिना access tokens लौटाने योग्य बनाना चाहते हैं। 49

Ramp की भूमिका के बारे में क्या पता है?

Okta ने Ramp, Webflow, HubSpot और अन्य joint customers को शुरुआती program में भाग लेने वाले संगठनों के रूप में चिन्हित किया था। इस program का उद्देश्य participating MCP providers के applications तक Claude की पहुंच को govern करना था। 38

लेकिन उपलब्ध sources Ramp के specific deployment, rollout का आकार, इस्तेमाल किए गए connectors या मापे गए परिणामों के बारे में पर्याप्त जानकारी नहीं देते। इसलिए इन पहलुओं के बारे में अनुमान लगाना उचित नहीं होगा।

Enterprise rollout के लिए यह बदलाव महत्वपूर्ण क्यों है?

EMA enterprise स्तर पर AI-connected tools deploy करने की एक व्यावहारिक समस्या को संबोधित करता है। हर user के लिए अलग OAuth prompt onboarding का काम बढ़ाता है, access को standardize करना कठिन बनाता है और admins को कर्मचारियों पर setup सही ढंग से पूरा करने के लिए निर्भर रखता है। Centralized identity-provider flow में access decisions संगठन की मौजूदा roles और group policies के अनुसार लिए जा सकते हैं।

Security boundary भी अधिक स्पष्ट हो जाती है: identity provider तय करता है कि user connector इस्तेमाल करने का हकदार है या नहीं, जबकि MCP connector का authorization server assertion को validate करने के बाद अपना access token जारी करता है। फिर भी संगठनों को हर MCP server का मूल्यांकन, least-privilege policies का configuration और users द्वारा जोड़े जा सकने वाले servers पर नियंत्रण बनाए रखना होगा। Anthropic के Claude Code documentation में trusted MCP servers इस्तेमाल करने की सलाह दी गई है और managed या source-controlled settings के जरिए server configuration सीमित करने का विकल्प बताया गया है। 13

इसलिए headline बदलाव यह नहीं है कि “OAuth पूरी तरह खत्म हो गया।” असल में, employee-facing consent loop की जगह एक enterprise-managed authorization exchange ने ले ली है, जो मौजूदा SSO policy को MCP connector access से जोड़ता है। Claude को अलग-अलग teams में deploy करने वाली कंपनियों के लिए यह Claude, Claude Code और Cowork में connector provisioning को अधिक consistent बना सकता है, जबकि administrative control केंद्रीय रूप से कायम रहता है। 4962