Didit MCP प्रमाणीकरण: Didit से लॉग इन करें (OAuth)

Didit MCP Didit के साथ लॉग इन करें (OAuth 2.1) के ज़रिए प्रमाणीकरण करता है। यह आपकी कंसोल भूमिका की अनुमतियों के साथ Didit का उपयोगकर्ता बनकर काम करता है: इसमें कोई API कुंजी मोड नहीं है।

Didit के साथ लॉग इन करें

होस्टेड सर्वर (https://mcp.didit.me/mcp) एक OAuth 2.1 रिसोर्स सर्वर है। Didit Business Console (business.didit.me) प्राधिकरण सर्वर है, जो सहमति स्क्रीन होस्ट करता है और टोकन जारी करता है। आपका MCP क्लाइंट मानक फ़्लो अपने-आप चलाता है:

खोजें

क्लाइंट बिना टोकन के /mcp पर पोस्ट करता है और 401 पाता है। उसके WWW-Authenticate: Bearer हेडर में resource_metadata सुरक्षित-संसाधन मेटाडेटा (RFC 9728) की ओर इशारा करता है:

https://mcp.didit.me/.well-known/oauth-protected-resource/mcp

इस दस्तावेज़ में संसाधन (https://mcp.didit.me/mcp), प्राधिकरण सर्वर (https://business.didit.me) और समर्थित स्कोप दिए होते हैं। यही दस्तावेज़ ऑरिजिन रूट https://mcp.didit.me/.well-known/oauth-protected-resource पर भी उपलब्ध है, उन क्लाइंट के लिए जो पहले वहीं जाँच करते हैं।

पंजीकरण करें (डायनामिक क्लाइंट पंजीकरण)

क्लाइंट https://business.didit.me/.well-known/oauth-authorization-server पर प्राधिकरण सर्वर का मेटाडेटा पढ़ता है और, अगर उसके पास अभी क्लाइंट id नहीं है, तो registration_endpoint पर खुद को पंजीकृत करता है (RFC 7591)। आपको पहले से कुछ भी प्रोविज़न नहीं करना होता: loopback या native कॉलबैक वाले लोकल क्लाइंट (Claude Code, Cursor, MCP Inspector) और समीक्षित कॉलबैक वाले क्लाउड-होस्टेड क्लाइंट (Claude), दोनों इसी तरीके से पंजीकृत होते हैं। ऐसा रिमोट कॉलबैक URL जिसकी Didit ने समीक्षा नहीं की है, invalid_redirect_uri के साथ अस्वीकार हो जाता है; उस क्लाइंट को पहले किसी ऑपरेटर द्वारा पंजीकृत करना होगा।

प्राधिकरण दें (PKCE)

क्लाइंट S256 PKCE चैलेंज के साथ https://business.didit.me/authorize खोलता है। आप साइन इन करते हैं (या रजिस्टर करते हैं) और देखते हैं कि कौन-सी अनुमतियाँ माँगी गई हैं। क्लाइंट सार्वजनिक होते हैं: टोकन endpoint कोई क्लाइंट सीक्रेट स्वीकार नहीं करता (token_endpoint_auth_methods_supported का मान none है), इसलिए कोड को क्लाइंट से बाँधने का काम PKCE करता है।

सहमति

आप स्वीकृति देते हैं। कंसोल उस ऐप के लिए एक सत्र बनाता है, जो उन्हीं स्कोप से बँधा होता है जिन्हें आपने स्वीकृत किया है, और एक प्राधिकरण कोड लौटाता है। क्लाइंट इस कोड को token_endpoint पर बदलकर एक एक्सेस टोकन और एक रिफ़्रेश टोकन लेता है।

टूल कॉल करें

क्लाइंट हर अनुरोध के साथ एक्सेस टोकन भेजता है। MCP उसे Didit auth सेवा के विरुद्ध RFC 7662 टोकन इंट्रोस्पेक्शन से सत्यापित करता है (टोकन अपारदर्शी होते हैं, JWT नहीं), इंट्रोस्पेक्शन रिस्पॉन्स से आपके संगठन की अनुमतियाँ पढ़ता है, और उस अनुरोध की अवधि के लिए आपकी ओर से काम करता है।

स्कोप

रिसोर्स मेटाडेटा तीन स्कोप विज्ञापित करता है। सहमति स्क्रीन क्लाइंट द्वारा माँगे गए स्कोप को सरल भाषा में दिखाती है:

स्कोप	यह देता है
`didit:management`	अपने वर्कस्पेस का प्रबंधन करें: `organization`, `members`, `subscription`, `users`, `applications`, `workflows`, `customization`, `questionnaires`, `lists`, `webhooks`, `integrations`, `api-keys`, `audit-logs`, `roles`, `saml`, और `analytics`।
`didit:verification`	सत्यापन चलाएँ और उनकी समीक्षा करें: `sessions`, `businesses`, `cases`, `networks`, `transactions`, `blocklist`, और `analytics`।
`didit:staff`	Didit स्टाफ़ खातों के लिए आरक्षित। यह किसी सामान्य खाते के लिए कुछ भी अनलॉक नहीं करता, और ओपन-सोर्स बिल्ड में केवल-स्टाफ़ टूल परिभाषित नहीं हैं।

दोनों स्कोप में analytics शामिल है। lists का प्रबंधन करने के लिए didit:management चाहिए; blocklist तक पहुँचने के लिए didit:verification चाहिए। टूल संदर्भ बताता है कि हर टूल किस स्कोप के अंतर्गत आता है। आपके द्वारा स्वीकृत स्कोप टोकन पर रहते हैं और सर्वर-साइड पर लागू होते हैं, इसलिए केवल didit:verification से जुड़ा ऐप मैनेजमेंट सतह पर अस्वीकार होता है, भले ही आपकी अपनी भूमिका उसकी अनुमति देती हो। ऑथराइज़ेशन सर्वर OpenID स्कोप (openid profile email) भी जानता है; जो कनेक्शन केवल इन्हें माँगता है, वह बस यह बता सकता है कि आप कौन हैं, और इसके अलावा कुछ नहीं। किसी ऐप की प्रभावी अनुमतियाँ स्वीकृत स्कोप और आपकी कंसोल भूमिका का प्रतिच्छेदन होती हैं, दोनों में से कभी भी व्यापक वाली नहीं। didit_session_create से सत्यापन सत्र बनाने के लिए आपको didit:verification स्कोप और create:sessions या write:sessions वाली भूमिका चाहिए। डेवलपर भूमिका में create:sessions शामिल है। अकेले didit:management को स्वीकृत करने से सत्र बनाने की अनुमति नहीं मिलती, भले ही आपकी भूमिका में आवश्यक अनुमति हो।

भूमिकाएँ और अनुमतियाँ

होस्टेड टोकन आपका प्रतिनिधित्व करता है, इसलिए एजेंट एक ही कनेक्शन से आप जिन संगठनों के सदस्य हैं उन सभी में काम कर सकता है। क्रॉस-ऐप टूल (didit_session_search, didit_analytics, didit_context_get और बाकी *_search टूल) इन सभी संगठनों के डेटा को स्वचालित रूप से एकत्रित करते हैं। आपकी भूमिका हमेशा Didit बैकएंड द्वारा, प्रति संगठन, लागू होती है। हर टूल एक बैकएंड अनुमति स्ट्रिंग से मैप होता है (उदाहरण के लिए didit_session_update_status के लिए write:sessions, didit_session_delete के लिए delete:sessions); टूल संदर्भ हर टूल के लिए यह दिखाता है। सर्वर अनुरोध भेजने से पहले भी यह अनुमति जाँचता है, introspection रिस्पॉन्स में आपके संगठन के लिए मौजूद अनुमतियों का उपयोग करते हुए:

enforce मोड में जिस टूल को चलाने की आपकी भूमिका अनुमति नहीं देती, वह tools/list से हटा दिया जाता है, और फिर भी उसे कॉल करने पर missing_scope त्रुटि लौटती है, जिसमें वह अनुमति लिखी होती है ("Your role in this organization does not include the permission 'delete:sessions' that didit_session_delete requires.")।
shadow मोड में (सर्वर का डिफ़ॉल्ट) हर टूल सूचीबद्ध रहता है और कॉल बैकएंड तक जाती है, जो भूमिका में अनुमति न होने पर 403 लौटाता है; यह निर्णय केवल सर्वर के ऑडिट लॉग में दर्ज होता है।

दोनों ही स्थितियों में MCP आपकी कंसोल भूमिका से ज़्यादा अनुमति कभी नहीं देता। READER सूचीबद्ध कर सकता है और पढ़ सकता है; OWNER या ADMIN लिख और हटा सकता है।

टोकन की अवधि

स्वीकृत ऐप को उसी ब्राउज़र सत्र से अलग अपना सत्र मिलता है जिससे आपने उसे स्वीकृत किया था। एक्सेस टोकन अल्पकालिक होते हैं; क्लाइंट रिफ़्रेश टोकन से उन्हें चुपचाप नवीनीकृत करता है (grant_types_supported में refresh_token शामिल है), और रिफ़्रेश ऐप के स्कोप बनाए रखता है और उसी ऐप से बँधा रहता है। अगर रिफ़्रेश विफल हो जाता है (उदाहरण के लिए आपके ऐप को डिस्कनेक्ट करने के बाद), तो क्लाइंट अगले कॉल पर Didit के साथ लॉग इन करें फिर से चलाता है। कंसोल से साइन आउट करने पर जुड़े हुए ऐप साइन आउट नहीं होते, और किसी ऐप को डिस्कनेक्ट करने से आप कहीं भी साइन आउट नहीं होते।

ऐप डिस्कनेक्ट करना

कंसोल से

Settings → Authentication → Connected apps में आपके द्वारा स्वीकृत हर ऐप सूचीबद्ध है, उसके पंजीकृत नाम और उसे दी गई अनुमतियों के साथ। डिस्कनेक्ट करें उस ऐप की पहुँच तुरंत समाप्त कर देता है: उसका एक्सेस token और रिफ़्रेश token, दोनों काम करना बंद कर देते हैं, और कुछ और प्रभावित नहीं होता।

ऐप से (RFC 7009)

कोई क्लाइंट अपना एक्सेस स्वयं वापस कर सकता है, इसके लिए वह token को authorization server के revocation_endpoint पर POST करता है, जिसका पता https://business.didit.me/.well-known/oauth-authorization-server पर मेटाडेटा में दिया गया है। जैसा RFC 7009 में आवश्यक है, सफल कॉल का रिस्पॉन्स 200 होता है, चाहे token अभी भी सक्रिय रहा हो या नहीं, इसलिए रिस्पॉन्स से कभी पता नहीं चलता कि token मान्य था। 503 का मतलब है कि रद्द करना लागू नहीं हो सका: token को अब भी मान्य मानें और पुनः प्रयास करें।

curl -X POST https://business.didit.me/api/auth/oauth-revoke \
  -H "Content-Type: application/json" \
  -d '{"token": "<refresh-or-access-token>", "token_type_hint": "refresh_token", "client_id": "<your-client-id>"}'

API कुंजी क्यों नहीं? हर MCP टूल उपयोगकर्ता-स्कोप्ड कंसोल endpoints (/organization/{org}/application/{app}/…) को कॉल करता है, जो प्रति-भूमिका विशेषाधिकारों के साथ Bearer टोकन को अधिकृत करते हैं और x-api-key को अस्वीकार करते हैं। एक एप्लिकेशन API कुंजी आपके अपने बैकएंड से सीधे REST API को कॉल करने के लिए है (जैसे सत्र बनाना), इस MCP के लिए नहीं। didit_org_list_api_keys कुंजी का मेटाडेटा दिखाता है, मान छिपाए गए होते हैं; जो टूल कच्ची कुंजी दिखाता है, वह होस्टेड कनेक्टर पर छिपा होता है।

प्रत्येक क्लाइंट से कनेक्ट करना

हर क्लाइंट एक ही प्रवाह चलाता है; केवल URL देने का तरीका अलग होता है।

Claude
Claude Code
Cursor
सामान्य क्लाइंट

बिज़नेस कंसोल के integrate पेज पर दिखने वाला डीप लिंक इस्तेमाल करें। यह claude.ai खोलता है, जिसमें Add custom connector डायलॉग पहले से भरा होता है:

https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Didit&connectorUrl=https://mcp.didit.me/mcp

पुष्टि करें, फिर Didit के साथ लॉग इन करें पूरा करें। Claude Desktop वही URL Settings → Connectors → Add custom connector के अंतर्गत इस्तेमाल करता है। विवरण के लिए Connect Claude देखें।

claude mcp add --transport http didit https://mcp.didit.me/mcp

फिर ब्राउज़र साइन-इन शुरू करने के लिए Claude Code के भीतर /mcp चलाएँ।

~/.cursor/mcp.json:

{ "mcpServers": { "didit": { "url": "https://mcp.didit.me/mcp" } } }

Cursor स्वयं को रजिस्टर करता है और पहली बार इस्तेमाल पर ब्राउज़र खोलता है।

OAuth 2.1 समर्थन वाले किसी भी Streamable HTTP क्लाइंट को https://mcp.didit.me/mcp की ओर इंगित करें। उसे यह करना चाहिए:

POST /mcp भेजे, 401 प्राप्त करे और WWW-Authenticate से resource_metadata पढ़े।
https://mcp.didit.me/.well-known/oauth-protected-resource/mcp लाए, फिर https://business.didit.me/.well-known/oauth-authorization-server पर authorization server मेटाडेटा लाए।
यदि client id नहीं है, तो registration_endpoint पर रजिस्टर करे।
authorization_endpoint पर PKCE (S256) के साथ authorization-code प्रवाह चलाए, और token_endpoint पर code का आदान-प्रदान करे।
हर POST /mcp पर Authorization: Bearer <access_token> भेजे।

OAuth समर्थन न रखने वाले क्लाइंट npx -y mcp-remote@latest https://mcp.didit.me/mcp के पीछे चल सकते हैं, जो उनके लिए चरण 1 से 5 पूरे करता है।

प्रमाणीकरण विफलताएँ

HTTP 401
WWW-Authenticate: Bearer error="invalid_token", error_description="Missing Authorization header", resource_metadata="https://mcp.didit.me/.well-known/oauth-protected-resource/mcp"

/mcp से 401 का मतलब है कि token गायब है, उसकी समय-सीमा समाप्त हो चुकी है या उसे रद्द कर दिया गया है; क्लाइंट को रिफ़्रेश करना चाहिए या Didit के साथ लॉग इन करें दोबारा चलाना चाहिए। किसी विशेष टूल पर 403 या missing_scope त्रुटि आमतौर पर इसका अर्थ है कि या तो आपकी भूमिका में वह अनुमति नहीं है (जैसे READER द्वारा लिखने का प्रयास), या कनेक्शन उस टूल के लिए आवश्यक स्कोप के बिना स्वीकृत हुआ था, न कि पूरा कनेक्शन टूटा है। दोबारा कनेक्ट करके दोनों स्कोप स्वीकृत करने से दूसरा मामला ठीक हो जाता है; पहले मामले के लिए भूमिका बदलनी होगी। यदि हर टूल विफल हो, तो कंसोल में Settings → Authentication → Connected apps देखें: वहाँ जो ऐप डिस्कनेक्ट किया गया है, उसे फिर से स्वीकृत करना होगा।

टूल संदर्भ

हर टूल क्या करता है, उसका स्कोप और उसकी भूमिका-आधारित अनुमति।

उन्नत

भूमिकाएँ, क्रॉस-ऐप व्यवहार और सेल्फ-होस्टिंग।

गाइड

प्रमाणीकरण

Model Context Protocol (MCP)

वेब SDK

नेटिव SDK

सर्वर SDK

इंटीग्रेशन

Didit MCP प्रमाणीकरण: Didit से लॉग इन करें (OAuth)

Didit के साथ लॉग इन करें

स्कोप

भूमिकाएँ और अनुमतियाँ

टोकन की अवधि

ऐप डिस्कनेक्ट करना

प्रत्येक क्लाइंट से कनेक्ट करना

प्रमाणीकरण विफलताएँ

टूल संदर्भ

उन्नत

​Didit के साथ लॉग इन करें

​स्कोप

​भूमिकाएँ और अनुमतियाँ

​टोकन की अवधि

​ऐप डिस्कनेक्ट करना

​प्रत्येक क्लाइंट से कनेक्ट करना

​प्रमाणीकरण विफलताएँ

टूल संदर्भ

उन्नत

Didit के साथ लॉग इन करें

स्कोप

भूमिकाएँ और अनुमतियाँ

टोकन की अवधि

ऐप डिस्कनेक्ट करना

प्रत्येक क्लाइंट से कनेक्ट करना

प्रमाणीकरण विफलताएँ