MCP के लिए Zero-Touch OAuth

 (blog.modelcontextprotocol.io)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Enterprise-Managed Authorization(EMA) एक्सटेंशन अब स्थिर हो गया है, जिससे कंपनियां MCP server permissions को केंद्रीय रूप से मैनेज कर सकती हैं और उपयोगकर्ता एक बार लॉगिन करके अधिकृत servers तक पहुंच सकते हैं
  • मौजूदा तरीका user-by-user और server-by-server individual OAuth approvals पर निर्भर था, जिससे onboarding, security policy enforcement, audit trail, और work/personal account separation मुश्किल हो जाती थी
  • EMA में संगठन का IdP authorization decisions का मुख्य आधार बनता है; admin एक बार policy define करते हैं और उपयोगकर्ता अपने मौजूदा org account के जरिए आवश्यक MCP connections inherit कर लेते हैं
  • SSO के दौरान जारी किया गया ID-JAG MCP server के authorization server पर access token में exchange होता है, इसलिए उपयोगकर्ताओं को हर server के लिए consent screen पर redirect नहीं किया जाता
  • शुरुआती support में Okta, Anthropic, Visual Studio Code और Asana·Atlassian·Canva·Figma·Granola·Linear·Supabase शामिल हैं, और Slack भी support जोड़ रहा है

EMA की स्थिरता और enterprise deployment का लक्ष्य

  • Enterprise-Managed Authorization(EMA) extension अब stable स्थिति में है
  • enterprise environment में MCP server connections मैनेज करते समय बार-बार approval और consent prompts बड़ी असुविधा माने जाते थे, और EMA इन्हें कम करने के लिए बनाया गया एक्सटेंशन है
  • organizations, trusted identity provider(IdP) के जरिए MCP server access को केंद्रीय रूप से नियंत्रित कर सकती हैं
  • end users अपने मौजूदा organizational account से लॉगिन करने के बाद अधिकृत MCP servers से कनेक्ट होते हैं, जिससे server-by-server OAuth consent या one-time setup का बोझ कम होता है

user-specific authentication model की सीमाएं

  • standard MCP authorization model को user-scoped और पारंपरिक interactive authentication conventions के अनुसार डिजाइन किया गया था
  • यह उन consumer scenarios के लिए उपयुक्त हो सकता है जहां व्यक्ति खुद तय करता है कि उसकी data access किसे मिले, लेकिन enterprise deployment में यह अच्छी तरह scale नहीं करता
  • enterprise environment में खास तौर पर तीन समस्याएं बड़ी हो जाती हैं
    • हर employee को हर server अलग से approve करना पड़ता है, इसलिए onboarding के समय service-by-service manual connection की जरूरत होती है
    • security teams केंद्रीय नियंत्रण या audit trail के बिना हर user द्वारा स्वीकृत access पर निर्भर हो जाती हैं
    • company accounts को enforce करना कठिन होता है, इसलिए उपयोगकर्ता अपने personal accounts को work tools से जोड़ सकते हैं
  • यह friction MCP adoption को धीमा करता है और कमजोर workaround implementations बनने की संभावना बढ़ाता है
  • अगर shared authentication state को सुरक्षित रखने के लिए कोई universal standard न हो, तो implementers अलग-अलग समाधान बनाने लगते हैं; data और tools उपलब्ध होने पर भी user-specific authorization cost के कारण अधिकांश चीजें बंद रह सकती हैं

एक बार अनुमति, फिर हर जगह inherited access

  • Enterprise-Managed Authorization संगठन के IdP को MCP server access के authorization decision maker में बदल देता है
  • admins एक बार policy define करते हैं, और users अपने मौजूदा organizational ID से MCP host पर authenticate करते हैं
  • IdP group membership, roles, और conditional access rules के आधार पर access allow या deny कर सकता है
  • अंदरूनी flow इस प्रकार है
    • client SSO के दौरान IdP से Identity Assertion JWT Authorization Grant(ID-JAG) प्राप्त करता है
    • client इसे MCP server के authorization server को भेजता है और access token में exchange करता है
    • user को server-specific consent screens से नहीं गुजरना पड़ता
  • इस संरचना के तीन मुख्य प्रभाव हैं
    • admin संगठन के लिए server enable करते ही users अपने मौजूदा groups और role scope के भीतर अपने-आप access पा लेते हैं
    • access decisions IdP admin console में दर्ज रहते हैं, जिससे सभी connectors के लिए एक audit-friendly record मिलता है
    • interactive account selection step हट जाने से personal और enterprise accounts के बीच data flow confusion कम करना आसान हो जाता है
  • MCP के enterprise use में लक्ष्य यह है कि user के लॉगिन करते ही client बिना अतिरिक्त steps के अधिकृत tools और data से कनेक्ट हो जाए

शुरुआती support products और ecosystem

  • इस रिलीज में तीन समूहों ने implementation में भाग लिया: identity providers, clients, और servers

  • identity providers

    • Okta पहला supported identity provider है
    • Okta इस्तेमाल करने वाले organizations Okta’s Cross App Access(XAA) के जरिए supported clients और servers के लिए MCP access provision कर सकते हैं

  • clients

    • Anthropic ने Claude की shared MCP layer में EMA लागू किया है
    • admins Claude, Claude Code, और Cowork में users के लिए MCP servers approve कर सकते हैं
    • Visual Studio Code ने भी IDE के भीतर EMA support जोड़ा है

  • servers

    • Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase EMA को support करते हैं
    • Slack और अन्य servers भी support जोड़ रहे हैं
    • Okta के Aaron Parecki का कहना है कि Cross App Access protocol को MCP के EMA extension में embed करके identity को एक centralized governance plane बनाया गया है, जो security teams को compliance controls और users को seamless experience देता है
    • Figma के Devdatta Akhawe ने कहा कि MCP adoption बढ़ने के साथ XAA enterprise MCP deployments को सुरक्षित तरीके से scale करना आसान बनाता है
    • Linear के Tom Moor ने उस अनुभव का उल्लेख किया जिसमें एक बार लॉगिन करने पर सभी MCP connectors अपने-आप setup हो जाते हैं

दस्तावेज़ और participation channels

  • clients, servers, और identity platforms extension specification की समीक्षा कर सकते हैं और अपने products में नए standard का support जोड़ सकते हैं
  • Enterprise-Managed Authorization page client, server, और authorization server के लिए flow requirements को document करता है
  • ext-auth repository और draft specification में EMA के नवीनतम changes और support materials देखे जा सकते हैं
  • extension discussions, compatibility reports, और iterative improvements के लिए EMA Interest Group का उपयोग किया जाता है
  • EMA, MCP community का एक प्रयास है, जिसमें SEP-990 authors, ext-auth repository maintainers, और शुरुआती implementations को test करके specification को आगे बढ़ाने वाले identity और MCP providers ने योगदान दिया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • आम "MCP मर चुका है और Skills ही भविष्य हैं" बहस पर जाने से पहले, MCP की skills/CLI की तुलना में असली वैल्यू यह है कि यह authentication flow को agent की context window के बाहर रखता है, और कुछ मामलों में harness के बाहर तक अलग कर देता है
    यह security के नज़रिए से भी स्वाभाविक रूप से महत्वपूर्ण है, और आम users या बड़े enterprises के लिए AI tools अपनाते समय कहीं आसान user experience देता है
    context के फूले जाने या duplicate tool calls की शिकायतें समझ में आती हैं, लेकिन authentication को इस तरह संभालने वाली architecture में साफ़ वैल्यू है
    आदर्श MCP सिर्फ API के आगे एक authentication gateway हो, तब भी पर्याप्त फ़ायदा दे सकता है

    • यह extension, skills के मुकाबले MCP के दूसरे फ़ायदे भी अच्छी तरह दिखाता है: centralized control, कर्मचारियों के नज़रिए से आसान उपयोग, audit/compliance, deployment model
      अभी skills deployment का सबसे अच्छा तरीका कुछ ऐसा दिखता है: "इस फ़ाइल को कॉपी करके यहाँ डालो", "इस repository को checkout करके symbolic link जोड़ो", "slash command से install करो"
      यह भले सरल हो, लेकिन कर्मचारियों तक नया MCP server पहुँचाने के लिए इस extension जितना आसान नहीं है
    • MCP बेहतरीन audit trail भी संभव बनाता है
      उदाहरण के लिए, 6 ग्राहक कंपनियों के 6 Linear accounts authenticate करके रखना, और किस account का उपयोग करना है इसे deterministic और auditable तरीके से चुनना — ऐसी separation of responsibilities भी संभव है
    • MCP बनाम skills कोई binary choice नहीं है — यही असली सीख है
      दोनों बस अलग-अलग tools हैं, और requirements के हिसाब से कोई एक बेहतर हो सकता है या नहीं भी
      यह पूछने जैसा है कि चाकू और आरी में कौन बेहतर है
    • इसके अलावा MCP, runtime environment के बिना external platforms को connect करने देता है
      जब भी यह विषय आता है, engineers Claude Code को ऐसे लेते हैं जैसे वही AI agent का इकलौता app हो, लेकिन coding के बाहर भी कई industries में ढेरों use cases हैं
      harness local machine पर नहीं, बल्कि cloud के isolated और restricted container में चल सकता है, जहाँ arbitrary code execution कभी भी अनुमति नहीं होती
      फिर भी अगर ग्राहक अपने मौजूदा tools को agent से जोड़ना चाहते हैं, तो MCP built-in authentication वाले connectors देता है, इसलिए यह बिल्कुल उपयुक्त है; skills इस क्षेत्र के लिए नहीं हैं
    • मैं दोस्तों के साथ restaurant reviews का एक platform बना रहा हूँ, और कुछ trial and error के बाद MCP सही दिशा लग रहा है
      आम users Claude directory ढूँढकर उसमें skill files paste नहीं करेंगे
      "Connections" समझना आसान है, और MCP को paste करना या marketplace में ढूँढना ज़्यादा आसान है
      places और reviews तक agent की पहुँच वास्तव में उपयोगी होगी या नहीं, यह अभी तय नहीं है

  • Okta, Anthropic, Microsoft, Figma, Linear आदि में इस काम को बनाने वाले लोगों को बहुत-बहुत बधाई
    MCP skeptics के लिए भी यहाँ काम की चीज़ है
    यह ID-JAG नाम के नए token format पर काम करता है, और https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... में है
    यह बिल्कुल भी MCP-specific नहीं है, और जहाँ भी एक ही SSO provider का उपयोग करने वाले applications के बीच data को सुरक्षित रूप से share करना हो, वहाँ ID-JAG इस्तेमाल किया जा सकता है

    • ऐसी कंपनियों की वजह से software और जीवन की गुणवत्ता और खराब हुई है, इसलिए इसे सचमुच बधाई देने लायक मानना एक तरह का व्यंग्य लगता है

  • मैं अभी इम्प्लीमेंट कर रहे MCP server में Microsoft Entra ID authentication जोड़ने की कोशिश कर रहा हूँ, और सच कहूँ तो लग रहा है जैसे मैं बेवकूफ़ बन गया हूँ
    WWW-Authenticate header से client को resource metadata URL बताया जा सकता है, और उसके ज़रिए authentication server के रूप में Microsoft Entra और app registration scope भी तय किया जा सकता है
    लेकिन client_id तय नहीं किया जा सकता, और बात कुछ ऐसी है कि हर client, यानी agent, उसे खुद बना लेता है
    Microsoft Entra के .../authorize URL पर login शुरू करने के लिए Entra के app registration से मेल खाने वाला एक ज्ञात client_id चाहिए, लेकिन client ने मनमाने ढंग से जो value बनाई हो उसका Entra से मेल खाना संभव नहीं है
    सिद्धांततः dynamic client registration को support किया जा सकता है, लेकिन Microsoft Entra स्वाभाविक रूप से इसे support नहीं करता
    नतीजतन Microsoft Entra के आगे अपना dynamic client registration shim बनाकर सभी को वही static client_id लौटाने का तरीका ही एकमात्र रास्ता दिख रहा है
    क्या यह protocol वास्तव में enterprise में बिना किसी workaround के काम करने के लिए बना है, या फिर मुझसे कोई बहुत obvious चीज़ छूट रही है, ऐसा लग रहा है

    • लगता नहीं कि आपसे कोई obvious चीज़ छूटी है
      Entra ID dynamic client registration को support नहीं करता, और इस ecosystem की मौजूदा स्थिति अभी अच्छी नहीं है
      आम तौर पर MCP OAuth को पहले से registered पारंपरिक clients के साथ संभाला जाता है, लेकिन व्यवहार में बहुत-से MCP clients यह मानकर चलते हैं कि dynamic client registration उपलब्ध होगा और client_id specify करने का option नहीं देते
      हालांकि कुछ clients इसे support करते हैं, और थोड़ा प्रचार करूँ तो हमारा tool Erato भी इसे support करता है: https://erato.chat/docs
      Enterprise में deploy किए जाने वाले सामान्य solutions भी अक्सर web UI के ज़रिए MCP access को centralize करते हैं, इसलिए वे इसे support करते हैं
      एक दूसरा विकल्प MCP gateway है, जहाँ gateway और service के बीच pre-registered OAuth इस्तेमाल किया जा सकता है और gateway व client के बीच dynamic client registration की अनुमति दी जा सकती है
    • हमने भी client_id की वजह से यही समस्या झेली थी, और security कारणों से dynamic client registration चालू नहीं करना चाहते थे
      आखिर में हमने app को OAuth flow proxy करने और hardcoded client_id inject करने दिया
      MCP client से ऐसा दिखाया जाता है जैसे dynamic client registration support हो, लेकिन अंदरूनी तौर पर MCP के लिए अलग client_id सामान्य तरीके से इस्तेमाल होता है
      उदाहरण यहाँ है: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • मैंने भी यह ठीक कल ही इम्प्लीमेंट किया, और सार यह है कि यह library MCP server चलाती है: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      उसके बाद मैंने OpenID के साथ client registration संभालने और JWT बनाने के लिए एक authentication broker application बनाया
      नतीजतन अब यह तय किया जा सकता है कि कर्मचारी के department या अन्य मानदंडों के आधार पर कौन-से tools इस्तेमाल किए जा सकते हैं और क्या permissions मिलेंगी
      अंततः dynamic client registration की ज़रूरत पड़ती है
    • हाल ही में FusionAuth ने pre-registered clients इस्तेमाल करने का तरीका document किया है: https://fusionauth.io/docs/extend/examples/controlling-acces...
      DCR के नए और बेहतर sibling CIMD पर भी विचार चल रहा है और उस पर सक्रिय चर्चा हो रही है, लेकिन वह अभी उपलब्ध नहीं है: https://github.com/FusionAuth/fusionauth-issues/issues/3230
      आपके सुझाए proxy का एक विकल्प यह है कि developer portal वगैरह के ज़रिए हर MCP client के लिए PKCE enabled नया Entra client_id बनाया जाए, और user से कहा जाए कि वह उस value को client में configure करे
      इसके लिए CLI command यहाँ मिला, और शायद API भी होगा: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      Claude Code की settings https://code.claude.com/docs/en/mcp पर हैं, और ChatGPT की settings https://developers.openai.com/api/docs/guides/developer-mode पर हैं
      Pre-registered client developer के लिए ideal न भी हो, फिर भी स्वीकार्य हो सकता है, और specification में भी इसे first-class approach की तरह माना गया है: https://modelcontextprotocol.io/specification/2025-11-25/bas...
      अगर मुख्य users आंतरिक कर्मचारी हैं और वे MCP server access के लिए setup instructions का पालन कर सकते हैं, तो यह तरीका काम कर सकता है
      लेकिन अगर target developers नहीं बल्कि व्यापक public integrations हैं, तो यह निश्चित रूप से स्वीकार्य नहीं है, और MCP की बड़ी ताकत और अवसर भी ठीक वहीं है

  • Anthropic में Okta और कई MCP पार्टनर्स के साथ मिलकर इसे बनाने वालों में मैं भी एक हूँ
    Claude में इस फ़ॉर्मेट का आकार लेना बहुत उत्साहजनक है, और MCP spec में भी EMA अब stable extension बन चुका है, इसलिए इसे दूसरे ID providers और clients तक भी अपनवाना चाहता हूँ
    अगर कोई feedback हो तो यहाँ छोड़ें, और वास्तविक usage experience तथा इसे बेहतर बनाने के तरीक़ों के बारे में सुनना हमेशा अच्छा लगेगा

    • काफ़ी समय बाद
      कुछ समय से MCP पर नज़र नहीं डाली थी, लेकिन यह संगठनों में MCP को अधिक सुरक्षित बनाने और dynamic client registration की कमजोरियों को दूर करने के लिए काफ़ी उपयुक्त लगता है
      अब clients और approved redirect URIs को ID provider और organization सीधे सेट कर सकते हैं, इसलिए confused deputy attacks या phishing जैसे DCR-आधारित हमलों को अधिक व्यापक रूप से कम किया जा सकता है
      साथ ही, जिन मामलों में ID provider या organization DCR support नहीं करते थे, वहाँ MCP server को जो authorization logic implement करना पड़ता था, वह भी कम हो जाता है, जो एक बड़ा फ़ायदा है
      कमी यह है कि consumer use के लिए अब भी DCR की ज़रूरत पड़ती दिखती है
      GitHub, GitLab, Google जैसे consumer OAuth providers अगर static MCP client/server registration support करें, client एक static client_id embed करे, और user उस ID provider से login करके connection को सीधे manage करे, तो शायद इसका हल निकल सकता है
      कुल मिलाकर XAA/EMA सुरक्षा और usability दोनों में DCR से काफ़ी बेहतर लगता है
      चिंता वाले हिस्से भी DCR की तुलना में कहीं ज़्यादा आसानी से सुलझाए जा सकते हैं और उनका security impact भी छोटा है, क्योंकि attacker अपना client register नहीं कर सकता और MCP server developers के लिए फँसने वाले traps भी कम हो जाते हैं
    • सामान्य “ऐप” के लिए यह शानदार है, लेकिन हमारे लिए यह बहुत ज़रूरी है कि user MCP set up किए बिना भी agent-style interaction को कम friction के साथ कर सके
      किसी तरह का temporary session या out-of-band token store अच्छा रहेगा
      use case यह है कि sales process में buyer और seller को बहुत-सी जानकारी का आदान-प्रदान और analysis करना होता है, और यह analysis धीरे-धीरे अधिक agentic होता जा रहा है
      MCP की समस्या यह है कि शुरुआती setup friction, user के सीधे login करके ज़रूरी जानकारी लाने की तुलना में बहुत अधिक है
      MCP नियमित और frequent interactions के लिए अच्छा है, लेकिन तेज़ one-off sessions के लिए इसमें काफ़ी दिक्कतें हैं
      अगर Claude में “X, Y, Z से documents लाओ” कहा जाए, तो Claude उन websites तक पहुँचे, और site basic user info तथा एक login link लौटाए जिसे user browser में खोल सके
      user browser में authenticate करे, callback एक unique और short-lived one-time token लौटाए, और बाद की site requests में उसका exchange किया जाए — ऐसा होना अच्छा रहेगा
      इससे user को जल्दी authenticate किया जा सकेगा और साथ ही काम के दौरान session state भी बनी रहेगी
    • जानना चाहता हूँ कि क्या Microsoft Entra, यानी Azure AD टीम के साथ कोई बातचीत चल रही है
      क्या इसे जल्द expect किया जा सकता है, या इसमें काफ़ी समय लगेगा?
    • रिलीज़ के लिए बधाई
      मुख्य use case कंपनी के employees लगते हैं, लेकिन सोच रहा था कि क्या decentralized users जैसे customers या premium free users के लिए भी इसका वैसा ही value proposition है
      मुझे साफ़ समझ नहीं आ रहा, इसलिए जानना चाहता था कि मैं क्या मिस कर रहा हूँ, और लगता है इसका एक संबंधित जवाब यहाँ दिखा: https://news.ycombinator.com/item?id=48594381
    • बस यह confirm करना चाहता हूँ कि यह अभी वास्तव में usable नहीं है और अभी SEP stage में है

  • यह सच में शानदार है
    पिछले कुछ महीनों में मैं MCP समुदाय के लोगों के साथ कुछ SEP और Go experimental SDKs पर काम कर सका, यह मेरे लिए सौभाग्य की बात रही
    पहले मैं उन skeptics में था जो कहते थे, “यह तो बस API है”, “फिर एक और abstraction बना दी गई”
    लोग जो चूक जाते हैं, वह यह है कि MCP का “P” ग़लतफ़हमी पैदा करता है
    पारंपरिक app बनाते समय forms, UI, request/response handling, bidirectional channels, long-running tasks, authentication वगैरह सब बनाना पड़ता है
    MCP इस्तेमाल करने पर इस common layer का 80% संभल जाता है, इसलिए MCP protocol तो है ही, लेकिन असल में यह app framework के काफ़ी क़रीब है
    integrated authentication एक बहुत बड़ा सुधार है, और आगे और भी शानदार चीज़ें आने की उम्मीद है

  • मेरा बनाया हुआ काम बाहर दिखना काफ़ी अजीब-सा लेकिन अच्छा लग रहा है
    Atlassian में मैंने इस flow के RAS-side implementation पर काम किया
    CIMD, बेहतर tenancy support आदि के साथ इस flow में आगे निश्चित रूप से iterative improvements होंगी
    Anthropic, Okta और Atlassian में जिन लोगों ने इसे deliver किया, वे सब शानदार थे

  • अच्छा होगा अगर web support हो ताकि सीधे long-lived cookies issue की जा सकें
    OAuth server के बिना यह करने के लिए मैंने OAuth handshake के ज़रिए cookies पास कराने हेतु spec को hack किया था
    इस तरह की चीज़ की अनुमति न देना सच में बहुत frustrating है
    अगर cookies न हों, तो webpage खोलो; cookies set हो जाएँ तो बंद करो और store कर लो
    MCP पर मैंने 80-पेज की mini-book तक लिखी है, फिर भी यह लगातार frustrate करता है

    • मैं MCP project के lead maintainers में से एक हूँ, और यह तरीका कई scenarios में scale नहीं करता
      usability और security दोनों के लिहाज़ से इसमें समस्याएँ हैं, और cookies browsers के लिए बनाई गई हैं
      MCP servers और clients अक्सर ऐसे environments में चलते हैं जहाँ browser की गारंटी नहीं होती
    • यह लगभग वैसा ही है जैसे आप credential चोरी होने का निमंत्रण दे रहे हों
      long-lived credentials बहुत बड़ी liability हैं

  • मैंने इसे कई बार पढ़ा है, और यह निश्चित रूप से उपयोगी है
    auditing और access control को एक ही ID provider पर centralize किया जा सकता है, और ज़रूरत पड़ने पर token exchange संभालने वाले proxy API gateway की तरह भी ID provider काम कर सकता है
    इस क्षेत्र के दूसरे players ने भी ऐसा approach अपनाया है
    व्यक्तिगत रूप से मुझे यह थोड़ा असहज करता है कि ID provider मेरी जानकारी के बिना मेरी permissions को client को delegate कर सकता है
    शायद इसलिए कि मैं browser में user-present flows का बहुत आदी हूँ, और यह धीरे-धीरे machines के लिए access centralization की दिशा में बढ़ता हुआ लगता है
    enterprise environment में identity व्यक्ति की बजाय कंपनी की होती है, इसलिए वहाँ यह स्वीकार्य हो सकता है
    लेकिन इसे customer identity में integrate करना बिल्कुल अलग चुनौती है, और ID provider, client और resource authorization server के बीच ऐसा trust बनाना शायद आसान नहीं होगा

    • ऐसा कोई theoretical barrier नहीं है जो इस integration को consumer space में काम करने से रोके
      उदाहरण के लिए, अगर आप GitHub में logged in हैं, तो Sentry में भी अपने-आप login हो जाए — ऐसी trust relationship बनाई जा सकती है
      आगे अभी बहुत काम बाकी है, लेकिन फिलहाल सबसे स्पष्ट use case, जैसा आपने कहा, enterprise ही है
      admins नहीं चाहते कि अलग-अलग employees इधर-उधर क्लिक करते फिरें और मनमाने credentials चुनें

  • C1 में आंतरिक MCP उपयोग और प्रोडक्ट के भीतर MCP Gateway, दोनों जगह MCP authentication बहुत बड़ी सिरदर्द थी, इसलिए इसका आना बहुत स्वागतयोग्य है
    आज C1 ने EMA ID provider के रूप में काम करने वाला support जारी किया, और यह कम समय तक जीवित रहने वाले, scope-restricted token जारी करता है
    अब मैं Linear और हमारे द्वारा इस्तेमाल किए जाने वाले दूसरे MCPs से कनेक्ट होकर बार-बार होने वाले OAuth flow से छुटकारा पाना चाहता/चाहती हूँ
    Claude ने कुछ built-in connector में, कम-से-कम Slack में, यह काम जादू की तरह किया है और अनुभव काफ़ी अच्छा रहा
    खुलासा कर दूँ, मैं C1 का VPE हूँ, और जो लोग गहराई से देखना चाहते हैं उनके लिए मैंने approach को document किया है: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • मुझे ठीक से समझ नहीं आ रहा कि इसका सामान्य OAuth पर क्या फ़ायदा है
    लगता है authorization flow की तुलना का उदाहरण चाहिए

    • सामान्य OAuth में end user हर application के लिए अलग-अलग consent देता है कि उसका data share किया जाए या नहीं
      consumer use case में, यानी जहाँ end user अपने data का मालिक होता है, यह समझ में आता है
      लेकिन कई business use case में data share करने और access control करने वाला end user नहीं बल्कि company होती है
      अगर मैं Acme का कर्मचारी हूँ, तो मुझे यह तय नहीं करना चाहिए कि Acme का Google Drive data Claude या ChatGPT से जोड़ा जाए या नहीं; यह IT department को तय करना चाहिए
      Enterprise-Managed OAuth, या Cross App Access(XAA), IT admin द्वारा centrally controlled sharing model को OAuth framework के भीतर लाता है ताकि यह मौजूदा ecosystem के साथ काम कर सके
      साथ ही, data-sharing consent management को कर्मचारियों से IT admin के पास ले जाने से user experience के लिहाज़ से भी बड़ा फ़ायदा है
      कर्मचारियों को account connect करने के लिए कई OAuth flow से नहीं गुजरना पड़ता, क्योंकि IT admin पहले से sharing control सेट कर चुका होता है
      बस यह सोचिए कि joining के पहले ही दिन Slack पहले से Zoom, Drive, Calendar वगैरह से connected हो
    • फ़ायदा यह है कि user को यह control करने या consent देने की ज़रूरत नहीं होती कि कौन-से apps आपस में उसकी information share कर सकते हैं
      क्योंकि access delegation का फ़ैसला ID provider policy level पर लिया जाता है
      हो सकता है user को कभी पता ही न चले कि किन apps या services को उसकी information share करने की permission है
      एक मिनट, क्या यह सच में फ़ायदा है? ;-)