> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Didit MCP प्रमाणीकरण: PKCE के साथ OAuth 2.1, डायनामिक क्लाइंट रजिस्ट्रेशन, स्कोप, भूमिकाएँ और हर क्लाइंट से कनेक्ट करने के चरण।

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

***

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

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

**1. खोजें**

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

```text theme={null}
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` पर भी उपलब्ध है, उन क्लाइंट के लिए जो पहले वहीं जाँच करते हैं।

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

क्लाइंट `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` के साथ अस्वीकार हो जाता है; उस क्लाइंट को पहले किसी ऑपरेटर द्वारा पंजीकृत करना होगा।

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

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

**4. सहमति**

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

**5. टूल कॉल करें**

क्लाइंट हर अनुरोध के साथ एक्सेस टोकन भेजता है। 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` चाहिए।

[टूल संदर्भ](https://docs.didit.me/hi/integration/mcp/tools.md) बताता है कि हर टूल किस स्कोप के अंतर्गत आता है। आपके द्वारा स्वीकृत स्कोप टोकन पर रहते हैं और सर्वर-साइड पर लागू होते हैं, इसलिए केवल `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`); [टूल संदर्भ](https://docs.didit.me/hi/integration/mcp/tools.md) हर टूल के लिए यह दिखाता है। सर्वर अनुरोध भेजने से पहले भी यह अनुमति जाँचता है, 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 के साथ लॉग इन करें** फिर से चलाता है।

कंसोल से साइन आउट करने पर जुड़े हुए ऐप साइन आउट नहीं होते, और किसी ऐप को डिस्कनेक्ट करने से आप कहीं भी साइन आउट नहीं होते।

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

**1. कंसोल से**

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

**2. ऐप से (RFC 7009)**

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

```bash theme={null}
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>"}'
```

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

***

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

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

> [tab] Claude
>
> बिज़नेस कंसोल के integrate पेज पर दिखने वाला डीप लिंक इस्तेमाल करें। यह claude.ai खोलता है, जिसमें **Add custom connector** डायलॉग पहले से भरा होता है:
>
> ```text theme={null}
> 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](https://docs.didit.me/hi/integration/mcp/claude.md) देखें।

> [tab] Claude Code
>
> ```bash theme={null}
> claude mcp add --transport http didit https://mcp.didit.me/mcp
> ```
>
> फिर ब्राउज़र साइन-इन शुरू करने के लिए Claude Code के भीतर `/mcp` चलाएँ।

> [tab] Cursor
>
> `~/.cursor/mcp.json`:
>
> ```json theme={null}
> { "mcpServers": { "didit": { "url": "https://mcp.didit.me/mcp" } } }
> ```
>
> Cursor स्वयं को रजिस्टर करता है और पहली बार इस्तेमाल पर ब्राउज़र खोलता है।

> [tab] सामान्य क्लाइंट
>
> OAuth 2.1 समर्थन वाले किसी भी Streamable HTTP क्लाइंट को `https://mcp.didit.me/mcp` की ओर इंगित करें। उसे यह करना चाहिए:
>
> 1. `POST /mcp` भेजे, `401` प्राप्त करे और `WWW-Authenticate` से `resource_metadata` पढ़े।
> 2. `https://mcp.didit.me/.well-known/oauth-protected-resource/mcp` लाए, फिर `https://business.didit.me/.well-known/oauth-authorization-server` पर authorization server मेटाडेटा लाए।
> 3. यदि client id नहीं है, तो `registration_endpoint` पर रजिस्टर करे।
> 4. `authorization_endpoint` पर PKCE (S256) के साथ authorization-code प्रवाह चलाए, और `token_endpoint` पर code का आदान-प्रदान करे।
> 5. हर `POST /mcp` पर `Authorization: Bearer <access_token>` भेजे।
>
> OAuth समर्थन न रखने वाले क्लाइंट `npx -y mcp-remote@latest https://mcp.didit.me/mcp` के पीछे चल सकते हैं, जो उनके लिए चरण 1 से 5 पूरे करता है।

***

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

```text theme={null}
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** देखें: वहाँ जो ऐप डिस्कनेक्ट किया गया है, उसे फिर से स्वीकृत करना होगा।

***

> [card] [टूल संदर्भ](https://docs.didit.me/hi/integration/mcp/tools.md)
>
> हर टूल क्या करता है, उसका स्कोप और उसकी भूमिका-आधारित अनुमति।

> [card] [उन्नत](https://docs.didit.me/hi/integration/mcp/advanced.md)
>
> भूमिकाएँ, क्रॉस-ऐप व्यवहार और सेल्फ-होस्टिंग।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.