मुख्य कंटेंट तक स्किप करें

MCP सर्वर सुरक्षित करना: OAuth, ऑडियंस बाइंडिंग और कन्फ्यूज्ड डेप्युटी

उन्नत
What you'll learn
  • समझें कि एक रिमोट (HTTP) MCP सर्वर एक OAuth 2.1 रिसोर्स सर्वर क्यों है, न कि केवल एक API-की एंडपॉइंट
  • डिस्कवरी हैंडशेक का पता लगाएं: 401 → Protected Resource Metadata → Authorization Server Metadata → टोकन
  • टोकन ऑडियंस बाइंडिंग (RFC 8707) की व्याख्या करें और यह क्यों एक सेवा के टोकन को दूसरी सेवा पर काम करने से रोकती है
  • कन्फ्यूज्ड-डेप्युटी जाल और इसे बंद करने वाले एकमात्र नियम का नाम बताएं: किसी क्लाइंट के टोकन को कभी भी अपस्ट्रीम API तक पास न करें
  • इंटरनेट पर MCP सर्वर एक्सपोज़ करने से पहले एक छोटी हार्डनिंग चेकलिस्ट लागू करें

MCP एक नवीनता से बढ़कर एजेंटों के टूल तक पहुंचने का डिफ़ॉल्ट तरीका बन गया — जिसका अर्थ है कि MCP सर्वर अब वास्तविक डेटा और वास्तविक क्रियाओं के सामने बैठते हैं। एक लोकल सर्वर जिसे आप STDIO पर लॉन्च करते हैं, अपने वातावरण पर भरोसा करता है: यह env वेरिएबल्स से क्रेडेंशियल पढ़ता है और बचाव करने के लिए कोई नेटवर्क सीमा नहीं होती। जिस पल आप उसी सर्वर को रिमोट (HTTP) बनाते हैं, कोई भी जो URL तक पहुंच सकता है, उसे कॉल करने की कोशिश कर सकता है। यह इसे एक ऑथराइज़ेशन समस्या में बदल देता है, और MCP स्पेक इसका उत्तर OAuth 2.1 से देती है — न कि किसी कस्टम API-की योजना से।

यह पेज रिमोट मामले के बारे में है। यदि आपका सर्वर केवल STDIO है, तो स्पेक स्पष्ट रूप से कहती है कि OAuth फ्लो का पालन न करें — वातावरण से क्रेडेंशियल खींचें और आगे बढ़ें।

तीन भूमिकाएं​

OAuth समस्या को तीन पक्षों में बांटती है। MCP उन पर साफ-सुथरे तरीके से मैप होती है:

एक MCP OAuth फ्लो में कौन कौन है
कार्ड पलटने के लिए Enter या Space दबाएँ। कार्ड बदलने के लिए बाएँ और दाएँ तीर कुंजियों का उपयोग करें।शब्द दिखाया गया।
1 / 3

मुख्य मानसिक बदलाव: MCP सर्वर कभी भी लॉगिन को स्वयं नहीं संभालता। यह केवल किसी और द्वारा जारी किए गए टोकन को वैलिडेट करता है। यही अलगाव आपको एक ऐसे सर्वर के सामने एक तैयार आइडेंटिटी प्रोवाइडर रखने देता है जिसे आपने लिखा है।

डिस्कवरी हैंडशेक​

एक क्लाइंट को यह पहले से कॉन्फ़िगर किए जाने की आवश्यकता नहीं होनी चाहिए कि कहां प्रमाणित करना है। MCP डिस्कवरी को स्वचालित बनाती है, जो एक 401 द्वारा संचालित होती है:

Guided walkthrough1 of 6
  1. सबसे पहला अनुरोध खाली जाता है। सर्वर इसे HTTP 401 Unauthorized और अपने रिसोर्स-मेटाडेटा URL की ओर इशारा करते हुए एक WWW-Authenticate हेडर के साथ अस्वीकार कर देता है।

ध्यान दें कि क्लाइंट की ओर कोई हार्डकोडेड ऑथ कॉन्फ़िग नहीं है — 401 सब कुछ बूटस्ट्रैप करता है। यही पूरी बात है: एक एजेंट ऐसे सर्वर से जुड़ सकता है जिसे उसने कभी नहीं देखा और यह पता लगा सकता है कि कैसे प्रमाणित करना है।

ऑडियंस बाइंडिंग: भार-वहन करने वाला नियम​

यहां वह विफलता मोड है जिसे रोकने के लिए ऑडियंस बाइंडिंग मौजूद है। मान लीजिए किसी उपयोगकर्ता के पास calendar.example.com के लिए जारी किया गया एक टोकन है। evil.example.com पर एक दुर्भावनापूर्ण (या केवल लापरवाह) MCP सर्वर क्लाइंट को उस टोकन को अपने पास भेजने के लिए धोखा देता है। यदि evil इसे स्वीकार करता है, तो अब यह पलटकर उपयोगकर्ता के रूप में कैलेंडर API को कॉल कर सकता है। एक सेवा का टोकन दूसरी पर काम कर गया। OAuth की सुरक्षा सीमा अभी ढह गई।

समाधान है Resource Indicators (RFC 8707):

Guided walkthrough1 of 3
  1. ऑथराइज़ेशन अनुरोध और टोकन अनुरोध दोनों पर, क्लाइंट को उस MCP सर्वर के कैनोनिकल URI पर सेट एक resource पैरामीटर शामिल करना MUST जिसे वह कॉल करना चाहता है — जैसे resource=https://mcp.example.com. यह इसे तब भी भेजता है जब वह अनिश्चित हो कि AS इसका समर्थन करता है।

ऑथराइज़ेशन अनुरोध पर resource पैरामीटर (URL-encoded)

&resource=https%3A%2F%2Fmcp.example.com

कैनोनिकल URI सख्त हैं: https://mcp.example.com और https://mcp.example.com:8443/mcp वैध हैं; mcp.example.com (कोई स्कीम नहीं) और https://mcp.example.com#frag (फ्रैगमेंट) नहीं हैं। इंटरऑपरेबिलिटी के लिए बिना ट्रेलिंग स्लैश वाले रूप को प्राथमिकता दें।

कन्फ्यूज्ड डेप्युटी: टोकन को कभी पास न करें​

यह वह गलती है जो एक नेक इरादे वाले MCP सर्वर को एक हमलावर के प्रॉक्सी में बदल देती है। यह एजेंट सुरक्षा से वही कन्फ्यूज्ड-डेप्युटी समस्या है, जिसे एक ठोस नियम तक तीक्ष्ण किया गया है।

एक MCP सर्वर को अक्सर एक अपस्ट्रीम API (GitHub, एक डेटाबेस सेवा, एक अन्य SaaS) को कॉल करने की आवश्यकता होती है। प्रलोभन यह है कि क्लाइंट द्वारा आपको दिए गए टोकन को लें और उसे अपस्ट्रीम फॉरवर्ड कर दें। ऐसा न करें। स्पेक स्पष्ट है: MCP सर्वर को क्लाइंट से प्राप्त टोकन को पास थ्रू नहीं करना MUST NOT।

यह खतरनाक क्यों है: क्लाइंट का टोकन आपके सर्वर को अपने ऑडियंस के रूप में लेकर जारी किया गया था। यदि आप इसे फॉरवर्ड करते हैं, तो अपस्ट्रीम API इस पर ऐसे भरोसा कर सकता है मानो यह आपसे आया हो, या मान सकता है कि आपने इसे पहले ही वैलिडेट कर दिया है — और अब एक हॉप के लिए स्कोप किया गया टोकन दो हॉप दूर काम कर रहा है, किसी की भी सहमति मॉडल के बाहर।

Watch out
  • यदि आपका MCP सर्वर किसी अपस्ट्रीम API को कॉल करता है, तो यह उस API के लिए एक अलग OAuth क्लाइंट के रूप में कार्य करता है और अपस्ट्रीम ऑथराइज़ेशन सर्वर से अपना खुद का टोकन प्राप्त करता है। दो स्वतंत्र टोकन, दो स्वतंत्र ऑडियंस। क्लाइंट का टोकन आपके दरवाजे पर रुक जाता है।

एक प्री-फ्लाइट हार्डनिंग चेकलिस्ट​

इससे पहले कि एक रिमोट MCP सर्वर सार्वजनिक इंटरनेट को छुए:

Guided walkthrough1 of 7
  1. सभी AS एंडपॉइंट्स HTTPS होने MUST। Redirect URI HTTPS या localhost होने MUST — और कुछ नहीं।

खुद को परखें​

खुद को परखें

0/4
  1. एक रिमोट MCP सर्वर को बिना किसी एक्सेस टोकन के एक अनुरोध मिलता है। स्पेक इसे सबसे पहले क्या करने की आवश्यकता बताती है?
  2. टोकन ऑडियंस बाइंडिंग (RFC 8707) किससे रक्षा कर रही है?
  3. आपके MCP सर्वर को एक अपस्ट्रीम GitHub API को कॉल करने की आवश्यकता है। क्लाइंट द्वारा भेजे गए एक्सेस टोकन के साथ इसे क्या करना चाहिए?
  4. एक STDIO (लोकल) MCP सर्वर के लिए, स्पेक कहती है कि क्रेडेंशियल को कैसे संभाला जाना चाहिए?

स्रोत और आगे पढ़ने के लिए​