हार्नेस के भीतर: MCP में OAuth जारीकर्ता बंधन, और प्रोटोकॉल सुरक्षा आखिर स्ट्रिंग तुलना पर क्यों टिकती है

तीन आँकड़े, फिर उनका मतलब। एक: OAuth मेटाडेटा दस्तावेज़ में जारीकर्ता फ़ील्ड सिर्फ एक स्ट्रिंग है। दो: इस गर्मियों Atlassian, Context7 और Home Assistant तीनों ने MCP प्राधिकरण मेटाडेटा उपलब्ध कराया जिसमें वह स्ट्रिंग उस URL से मेल नहीं करती थी जहाँ से दस्तावेज़ लिया गया, और सख्त क्लाइंट ने कनेक्शन अस्वीकार कर दिया। तीन: MCP विनिर्देश में अब जारी हो रहा सुधार मूलतः इतना है, "स्ट्रिंग तुलना करो, अलग हो तो अस्वीकार करो।" तरीका पूरा इतना ही है, और यह OAuth के सबसे खराब हमलों में से एक मिक्स-अप हमला बंद करता है, जिसे MCP के तैनाती पैटर्न ने संरचनात्मक रूप से और खराब बना दिया।

यह हार्नेस के भीतर लेख है, इसलिए भीतरी तंत्र के भीतर जाएँगे: जारीकर्ता-बंधन समस्या क्या है, कौन-से प्रवाहों पर असर पड़ता है, और 2026-07-28 विनिर्देश पैकेज MCP क्लाइंट या सर्वर बनाने वाले किसी भी कार्यान्वयनकर्ता से क्या मांगता है। उसी रिलीज़ के स्टेटलेस-ट्रांसपोर्ट बदलाव ने सुर्खियाँ लीं; प्रमाणीकरण सुदृढ़ीकरण को छह SEPs मिले और लगभग कोई कवरेज नहीं। प्राथमिकताएँ उलटी हैं, क्योंकि यदि आप वास्तविक क्रेडेंशियल रखने वाले MCP सर्वर चलाते हैं, तो यही हिस्सा तय करता है कि भ्रमित क्लाइंट टोकन गलत पक्ष को दे देता है या नहीं।

मुख्य बातें - MCP OAuth का पारंपरिक रूप उलट देता है: एक क्लाइंट रनटाइम पर खोजे गए कई प्राधिकरण सर्वर से बात करता है। यही उलटाव वह टोपोलॉजी है जिसके लिए मिक्स-अप हमले बने थे। - 2026-07-28 विनिर्देश पैकेज में छह SEPs हैं। सबसे महत्वपूर्ण दो: SEP-2468, जो RFC 9207 के अनुसार प्राधिकरण प्रतिक्रियाओं पर iss पैरामीटर सत्यापित करता है, और SEP-2352, जो हर पंजीकृत क्लाइंट क्रेडेंशियल को उस जारीकर्ता से बाँधता है जिसने उसे जारी किया। - यह सैद्धांतिक नहीं है। Atlassian और Context7 के MCP एंडपॉइंट इस गर्मियों प्रोडक्शन में जारीकर्ता-असंगत मेटाडेटा उपलब्ध करा चुके हैं, सख्त क्लाइंट तोड़ते हुए; विनिर्देश उन विफलताओं के अनुरूप ढल रहा है जो पहले से प्रोडक्शन में हैं। - iss सत्यापन अभी अनुशंसित है और अनिवार्य की ओर जा रही है। आज ही लागू करें, और जिस सर्वर को इसे समर्थन करना चाहिए उससे अनुपस्थित iss मिले तो कंधे न उचकाएँ, बल्कि अस्वीकार करें। - पूरी तरह अपनाया होने के बाद भी पैकेज सिर्फ क्लाइंट-से-सर्वर प्रमाणीकरण मजबूत करता है। एजेंट पहचान, प्रति-अनुरोध प्राधिकरण, प्रत्यायोजन उत्पत्ति और ऑडिट प्रोटोकॉल के बाहर हैं, आपकी जिम्मेदारी।

क्या हुआ

21 मई 2026 को MCP रखरखावकर्ताओं ने 2026-07-28 विनिर्देश का रिलीज़ कैंडिडेट लॉक किया, अंतिम विनिर्देश 28 जुलाई को जारी हुआ, और SDK रखरखावकर्ता तब से दस-सप्ताह की सत्यापन अवधि में हैं। अधिकांश चर्चा स्टेटलेस बदलाव पर गई। उसके नीचे, Tigera के सूक्ष्म अध्ययन के अनुसार, OAuth परत को सुदृढ़ करने वाले छह विनिर्देश सुधार प्रस्ताव हैं:

बाकी तीन SEPs, 2207, 2350, 2351, स्पष्टीकरण हैं, और प्रमाणीकरण विनिर्देश में स्पष्टीकरण मायने रखते हैं: मेटाडेटा दस्तावेज़ कहाँ है इस पर दो SDK असहमत हों तो वह अंतरसंचालनीयता विघटन है, पाद-टिप्पणी नहीं। लेकिन मुख्य जोड़ी 2468 और 2352 हैं, दोनों एक ही सवाल पर: क्लाइंट कैसे जाने कि वह वास्तव में किस सर्वर से बात कर रहा है?

MCP 2026-07-28 विनिर्देश पैकेज में OAuth सुदृढ़ीकरण के छह SEPs हैं: जारीकर्ता सत्यापन 2468, जारीकर्ता-बँधे क्रेडेंशियल 2352, गतिशील क्लाइंट पंजीकरण में क्लाइंट प्रकार घोषणा 837, साथ में दस्तावेजीकृत रिफ़्रेश टोकन 2207, दायरा संचय 2350 और खोज व्यवहार 2351, Tigera के विश्लेषण के अनुसार। रिलीज़ कैंडिडेट 21 मई को तय हुआ और अंतिम विनिर्देश 28 जुलाई 2026 को जारी हुआ।

कमजोरी मॉडल: एक क्लाइंट, कई जारीकर्ता

पारंपरिक OAuth कई क्लाइंट, एक प्राधिकरण सर्वर मानकर चलता है: हजारों ऐप, एक पहचान प्रदाता, एक टोकन जारीकर्ता। मिक्स-अप हमलों, जहाँ क्लाइंट को प्राधिकरण प्रतिक्रिया गलत सर्वर से जोड़ने के लिए छल किया जाता है, सीमित चिंता थे क्योंकि अधिकतर क्लाइंट सिर्फ एक जारीकर्ता से बात करते थे।

MCP पूरी व्यवस्था उलट देता है। एक क्लाइंट, यानी होस्ट एप्लिकेशन, कई MCP सर्वर से बात करता है, हर एक के आगे अलग प्राधिकरण सर्वर हो सकता है, रनटाइम पर खोजा जाता है, और अक्सर गतिशील क्लाइंट पंजीकरण से तुरंत पंजीकृत होता है। विनिर्देश लेखक सीधे कहते हैं: जारीकर्ता-सत्यापन SEP "मिक्स-अप हमले की उस श्रेणी को लक्षित करता है जो MCP के एक-क्लाइंट, कई-सर्वर तैनाती पैटर्न में अधिक सामान्य है", जैसा कि Tigera लेख उद्धृत करता है। जब क्लाइंट एक साथ दर्जनों प्राधिकरण सर्वरों के पंजीकरण रखता है, हमलावर को क्रिप्टोग्राफी तोड़ने की जरूरत नहीं। बस क्लाइंट से प्रतिक्रिया गलत सर्वर को जोड़ देना है।

रूप यह है। आपके एजेंट का होस्ट ईमानदार सर्वर A के साथ प्रवाह के बीच है, तभी प्रतिक्रिया आती है जो वास्तव में हमलावर-नियंत्रित सर्वर B से आई। जारीकर्ता जाँच न हो तो क्लाइंट विनिमय B के साथ पूरा कर सकता है, प्राधिकरण कोड लीक करते हुए, या B द्वारा जारी किए टोकन स्वीकार करके आगे प्रस्तुत कर सकता है। RFC 9207, पारंपरिक OAuth के लिए 2021 का सुधार, प्राधिकरण प्रतिक्रियाओं में स्पष्ट iss पैरामीटर लाया ताकि क्लाइंट अनपेक्षित जारीकर्ता वाली चीज अस्वीकार कर सके, और SEP-2468 वही आवश्यकता MCP में खींचता है। SEP-2352 कम दिखाई देने वाला हिस्सा, क्रेडेंशियल को संभालता है। पहले क्लाइंट जारीकर्ता A से जारी क्लाइंट ID रख सकता था और संसाधन जारीकर्ता B पर माइग्रेट होने पर A का क्रेडेंशियल B को प्रस्तुत कर सकता था। कभी-कभी काम करता था, और "कभी-कभी काम करता है" प्रमाणीकरण प्रणाली का वह गुण नहीं जो आप चाहते हैं। इसलिए 2352 पंजीकरण को प्रति प्राधिकरण सर्वर रखने, जारीकर्ता मान से बाँधने और माइग्रेशन पर दोबारा पंजीकृत करने की मांग करता है।

यह इस श्रेणी का पहला सुधार भी नहीं है। 2025-06-18 विनिर्देश संशोधन ने संसाधन संकेतक, RFC 8707, अनिवार्य किए ताकि टोकन एक विशिष्ट सर्वर के लिए जारी किए जाएँ, और MCP प्राधिकरण विनिर्देश पहले से दूसरे संसाधनों के लिए बने टोकन स्वीकार करने या उन्हें आगे के संसाधनों तक पहुँचाने से मना करता है। 2026-07-28 पैकेज उसी दिशा को आगे बढ़ाता है: डिफ़ॉल्ट भरोसा कम, स्पष्ट बंधन ज्यादा। यदि आपने मेरा MCP बनाम API लेख पढ़ा है, तो यही उस लचीलेपन की लागत है: रनटाइम खोज MCP को संयोज्य बनाती है, और साथ में ये पहचान संबंधी सवाल भी बनाती है।

MCP की एक-क्लाइंट-कई-सर्वर टोपोलॉजी ठीक वही तैनाती पैटर्न है जिसे मिक्स-अप हमले निशाना बनाते हैं: हमलावर क्रिप्टोग्राफी नहीं तोड़ता, वह क्लाइंट से प्रतिक्रिया या क्रेडेंशियल को गलत प्राधिकरण सर्वर से जोड़वा देता है। SEP-2468 RFC 9207 के iss पैरामीटर से प्रतिक्रियाओं को जारीकर्ता से बाँधता है; SEP-2352 पंजीकृत क्रेडेंशियल को उसे जारी करने वाले सर्वर से बाँधता है, Tigera विश्लेषण और RFC 9207 के अनुसार।

विनिर्देश प्रोडक्शन विफलताओं के अनुरूप ढल रहा है

यदि यह अमूर्त लगता है, तो नहीं है। जारीकर्ता स्ट्रिंग पूरी गर्मियों वास्तविक MCP तैनातियों में विफल हो रही है, और सख्त क्लाइंट पहले से उस पर अटक रहे हैं।

जुलाई में opencode क्लाइंट उपयोगकर्ताओं ने पाया कि Atlassian के Rovo MCP सर्वर पर OAuth खोज विफल हो रही थी। संरक्षित-संसाधन मेटाडेटा सही टेनेंट-विशिष्ट प्राधिकरण सर्वर घोषित करता था, लेकिन वहाँ उपलब्ध मेटाडेटा दस्तावेज़ ने जिस टेनेंट पथ से उसे प्राप्त किया गया था उसे जारीकर्ता बताने की जगह सिर्फ साझा जारीकर्ता https://auth.atlassian.com घोषित किया। RFC 8414 अनुभाग 3.3 कहता है कि issuer मान मेटाडेटा प्राप्त करने वाले URL के ठीक समान होना चाहिए, .well-known प्रत्यय हटाकर। इसलिए opencode के सख्त सत्यापन ने उसे सही तरह अस्वीकार किया और लॉगिन पूरी तरह अवरुद्ध हुआ: Atlassian की ओर का विनिर्देश-अनुपालन बग, लाइव एंडपॉइंट पर पुष्ट। Context7 MCP एंडपॉइंट में समान बग जून में सामने आया, जहाँ घोषित प्राधिकरण सर्वर और Clerk सबडोमेन पर मेटाडेटा में जारीकर्ता मेल नहीं खाते थे, और आधिकारिक MCP Go SDK ने प्रवाह को अस्वीकार किया। Home Assistant मेटाडेटा ने जारीकर्ता फ़ील्ड पूरी तरह छोड़ दी, जिससे MCP क्लाइंट अलग तरह से टूटे।

इन तीनों में कोई मिक्स-अप शोषण नहीं था; ये अंतरसंचालनीयता विफलताएँ थीं। लेकिन बिंदु यही है। वही स्ट्रिंग तुलना जो हमलावर के नकली सर्वर को रोकती है, लापरवाह वास्तविक सर्वर को भी रोकती है, इसलिए पारिस्थितिकी उस मेटाडेटा के प्रति कम सहिष्णु होने वाली है जो हमेशा गलत था और पहले पार हो जाता था। WorkOS का मिक्स-अप हमले लेख व्यावहारिक बिंदु अच्छी तरह रखता है: कई OAuth लाइब्रेरी RFC 9207 जाँच अभी भी डिफ़ॉल्ट रूप से बंद छोड़ती हैं, और CVE-2026-59208 को मामले के रूप में देता है जहाँ खाता खोज को पुष्ट जारीकर्ता तक सीमित करने से, sub दावे को वैश्विक रूप से मिलाने की जगह, बग वहीं रुक जाता। मैं उस CVE संदर्भ को स्वतंत्र रूप से सत्यापित तथ्य की जगह WorkOS द्वारा रिपोर्ट किया गया मानूँगा, पर रक्षात्मक सिद्धांत दोनों तरह मानक अभ्यास है।

वास्तविक MCP तैनातियाँ पूरी गर्मियों जारीकर्ता सत्यापन में विफल रही हैं: Atlassian का Rovo MCP सर्वर ऐसा मेटाडेटा उपलब्ध करता है जिसका जारीकर्ता प्राप्त टेनेंट URL से मेल नहीं करता, opencode मुद्दा #39332; Context7 एंडपॉइंट एक प्राधिकरण सर्वर घोषित करता था लेकिन मेटाडेटा में दूसरा घोषित था, Context7 मुद्दा #2723; और Home Assistant ने जारीकर्ता फ़ील्ड पूरी तरह छोड़ दी। RFC 8414 अनुभाग 3.3 जारीकर्ता मान को प्राप्ति URL से ठीक-ठीक मेल खाने की मांग करता है, इसलिए सख्त क्लाइंट ने तीनों को सही तरह अस्वीकार किया।

कार्यान्वयनकर्ता को क्या करना होगा

यदि आप MCP क्लाइंट बनाए रखते हैं:

1. हर प्राधिकरण प्रतिक्रिया पर iss अभी सत्यापित करें। जिस जारीकर्ता के साथ प्रवाह चल रहा है उससे असंगति को अस्वीकार करें, और सर्वर RFC 9207 समर्थन घोषित करता है लेकिन पैरामीटर छोड़ दे तो वह भी अस्वीकार करें। विनिर्देश स्पष्ट है कि अनुपस्थित iss अस्वीकृति भविष्य के संस्करण में आएगी, इसलिए आज ही अनिवार्य की तरह मानें।

2. पंजीकरण स्थिति को प्रति प्राधिकरण सर्वर विभाजित करें। हर क्लाइंट ID, रहस्य और रिफ़्रेश टोकन उस जारीकर्ता मान के साथ संग्रहीत करें जिसने उसे जारी किया। संसाधन का संरक्षित-संसाधन मेटाडेटा नए प्राधिकरण सर्वर की ओर इशारा करने लगे तो फिर पंजीकृत करें; पुराना क्रेडेंशियल दोबारा इस्तेमाल कभी न करें।

3. गतिशील क्लाइंट पंजीकरण में application_type घोषित करें। SEP-837 विफलताओं की वह श्रेणी ठीक करता है जहाँ डेस्कटॉप या CLI क्लाइंट डिफ़ॉल्ट रूप से web बन जाता है और लोकलहोस्ट रीडायरेक्ट URI पर अस्वीकार होता है। एक फ़ील्ड, असली बग श्रेणी खत्म।

4. खाता खोज को जारीकर्ता तक सीमित करें। sub दावा सिर्फ उस जारीकर्ता नेमस्पेस के भीतर खातों का मिलान करे जिसे आपने वास्तव में सत्यापित किया। वैश्विक मिलान कभी न करें।

यदि आप MCP सर्वर या उसके आगे प्राधिकरण सर्वर चलाते हैं: ऐसा मेटाडेटा उपलब्ध करें जिसका issuer ठीक उसी URL के समान हो जहाँ से प्राप्त किया गया, टेनेंट पथ सहित; RFC 9728 के अनुसार संरक्षित-संसाधन मेटाडेटा लागू करें; और सत्यापित करते रहें कि टोकन विशेष रूप से आपके संसाधन के लिए जारी हुए थे। और यदि आप बढ़ती MCP सर्वर सूची के विरुद्ध स्वयं-होस्ट किए एजेंट चला रहे हैं, बेड़े का गणित मायने रखता है: N एजेंट × M सर्वर का अर्थ N × M जारीकर्ता-बँधे पंजीकरण। दस एजेंट पर स्प्रेडशीट; सौ पर रजिस्ट्री, और विनिर्देश रजिस्ट्री पर कोई राय नहीं देता। वह हिस्सा आपकी प्लेटफ़ॉर्म जिम्मेदारी है।

कार्यान्वयनकर्ता को प्राधिकरण प्रतिक्रियाओं पर iss सत्यापित करना चाहिए, असंगतियों और जहाँ समर्थन घोषित है वहाँ चूकों को अस्वीकार करते हुए; क्रेडेंशियल जारीकर्ता के हिसाब से अलग-अलग संग्रहित करने और माइग्रेशन पर दोबारा पंजीकृत करने चाहिए; गतिशील क्लाइंट पंजीकरण में application_type घोषित करना चाहिए; और खाता खोज को सत्यापित जारीकर्ता तक सीमित करना चाहिए, Tigera के SEP विश्लेषण और WorkOS के मिक्स-अप मार्गदर्शन के अनुसार। स्तर 1 SDK से विनिर्देश की दस-सप्ताह की सत्यापन अवधि में समर्थन जारी करने की अपेक्षा है।

विनिर्देश अब भी किसका जवाब नहीं देता

पैकेज फिर पढ़ें और देखें छहों SEPs में साझा क्या है: वे एक OAuth क्लाइंट और एक प्राधिकरण सर्वर के बीच विनिमय सुदृढ़ करते हैं। यह जरूरी था। लेकिन जैसा Tigera विश्लेषण सीधे कहता है, टोकन क्लाइंट को प्रमाणित करता है, एजेंट को नहीं। एक होस्ट के पीछे दो सौ एजेंट एक क्लाइंट पहचान साझा करते हैं; जारीकर्ता बंधन यह नहीं बताता कि क्लाइंट के पीछे कौन-सा एजेंट, किसकी ओर से, किस आधार पर निर्णय लेते हुए बैठा है। दायरे प्रवेश-नियंत्रण हैं, प्रति-अनुरोध नीति नहीं। प्रत्यायोजन शृंखलाएँ, एजेंट से एजेंट और फिर सर्वर को कॉल, हर कड़ी पर OAuth-संगत हो सकती हैं और शुरू-से-अंत तक गैर-जवाबदेह रह सकती हैं। और पैकेज किसी से भी यह सब दर्ज करने की आवश्यकता नहीं रखता। यह प्रोटोकॉल के लिए सही दायरा तय करने का निर्णय है और उद्यम के लिए अधूरा जवाब।

यह काम छोटा दिखाने के लिए नहीं कह रहा। जारीकर्ता सत्यापन के बिना MCP, प्रमाणपत्र जाँच के बिना HTTP जैसा था, और खामी अब बंद हो रही है। लेकिन चार अंतराल, एजेंट पहचान, प्रति-अनुरोध प्राधिकरण, प्रत्यायोजन उत्पत्ति और ऑडिट, शासन परत के सवाल हैं, और विनिर्देश का इंतजार करने से नहीं आते। यही अंतराल मैं ग्राहकों के साथ एजेंट शासन में काम करता हूँ, और इन्हें एजेंट के आसपास का परिवेश लागू करता है या कोई नहीं।

अक्सर पूछे जाने वाले सवाल

MCP OAuth जारीकर्ता-बंधन समस्या क्या है?

MCP क्लाइंट रनटाइम पर खोजे गए कई प्राधिकरण सर्वर से बात करते हैं, जिससे वे मिक्स-अप हमले के लिए संवेदनशील होते हैं: प्रतिक्रिया या क्रेडेंशियल को गलत सर्वर से जोड़ा जा सकता है। 2026-07-28 विनिर्देश इसे प्राधिकरण प्रतिक्रियाओं पर iss पैरामीटर सत्यापित करने, SEP-2468 और RFC 9207, तथा हर पंजीकृत क्रेडेंशियल को जारीकर्ता से बाँधने, SEP-2352, से ठीक करती है।

क्या यह MCP में खुद कोई कमजोरी है?

यह भेद्यता की श्रेणी है जिसे प्रोटोकॉल के तैनाती पैटर्न ने अधिक सामान्य बनाया, और अब विनिर्देश स्तर पर बंद किया गया है। इस गर्मियों प्रोडक्शन में दिखीं विफलताएँ, Atlassian, Context7 और Home Assistant द्वारा जारीकर्ता-असंगत मेटाडेटा उपलब्ध कराया जाना, कार्यान्वयन बग थीं, लेकिन वे बताती हैं कि असत्यापित मॉडल कितना नाज़ुक था। सख्त सत्यापन अब आधार रेखा है।

कौन-से प्रवाह प्रभावित हैं?

ऐसे प्राधिकरण-कोड प्रवाह जहाँ क्लाइंट एक से अधिक प्राधिकरण सर्वर पर पंजीकृत है, सर्वर के बीच गतिशील क्लाइंट पंजीकरण, संसाधन माइग्रेशन के बाद क्रेडेंशियल उपयोग, और .well-known दस्तावेज़ के जरिए मेटाडेटा खोज। एकल-सर्वर तैनातियाँ कभी मुख्य जोखिम नहीं थे; एजेंटों की बनाई बहु-सर्वर टोपोलॉजी है।

यह अनिवार्य कब होगा?

2026-07-28 विनिर्देश अंतिम है, मई के रिलीज़ कैंडिडेट निर्धारण से दस-सप्ताह की सत्यापन अवधि के भीतर SDK समर्थन आ रहा है, और विनिर्देश स्पष्ट है कि भविष्य के संस्करण में iss के बिना प्रतिक्रियाएँ अस्वीकार करना अपेक्षित होगा। जो भी नया लागू करें उसमें इसे आज अनिवार्य मानें।

निष्कर्ष

OAuth सुरक्षा अक्सर परिणाम तय करने वाली नीरस स्ट्रिंग तुलना होती है, और MCP को अब इस तथ्य का सामना करना पड़ा। 2026-07-28 पैकेज पाँच साल पुराना OAuth सुधार ऐसे प्रोटोकॉल में लाता है जिसकी एक-क्लाइंट-कई-सर्वर रूप ने इसे तत्काल बना दिया, ठीक उसी समय जब वास्तविक तैनातियाँ वास्तविक दुनिया में जाँच विफल करने लगे। SDK अपडेट करें, iss सत्यापित करें, पंजीकरण बाँधें। फिर वह सवाल पूछें जिसका जवाब विनिर्देश ने सही कारण से नहीं दिया: जब आपके जारी किए टोकन का इस्तेमाल ऐसे टूल कॉल में हो जिसे आपने कभी मंजूर नहीं किया होता, किसी ऐसे एजेंट द्वारा जिसे आप नाम नहीं दे सकते, तो उसे कौन पकड़ता है, और रिकॉर्ड कहाँ है? वह जवाब विनिर्देश से नहीं आता। उस हार्नेस से आता है जो आप उसके चारों ओर बनाते हैं।

यदि आप MCP तैनाती के लिए प्रमाणीकरण और पहचान सुलझा रहे हैं, तो यह बातचीत मैं ग्राहकों के साथ नियमित रूप से करता हूँ। संपर्क करें।

स्रोत

• Tigera, "MCP की प्रमाणीकरण सुदृढ़ीकरण: छह नए OAuth SEPs क्या ठीक करते हैं और अब भी क्या नहीं": https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (प्रकाशित 2026-07-28, देखा गया 2026-08-29)

• WorkOS, "OAuth मिक्स-अप हमले और RFC 9207: जारीकर्ता जाँच जो टोकन विनिमय तक कभी नहीं पहुँची": https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (प्रकाशित 2026-07-20, देखा गया 2026-08-29)

• Model Context Protocol, प्राधिकरण विनिर्देश: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (प्रकाशित 2025-11-25, देखा गया 2026-08-29)

• RFC Editor, RFC 9207, "OAuth 2.0 प्राधिकरण सर्वर जारीकर्ता पहचान": https://www.rfc-editor.org/rfc/rfc9207.html (प्रकाशित 2021-12-16, देखा गया 2026-08-29)

• opencode रिपॉजिटरी, मुद्दा #39332, "MCP OAuth: Atlassian प्रमाणीकरण विफल, RFC 8414 जारीकर्ता असंगति": https://github.com/anomalyco/opencode/issues/39332 (प्रकाशित 2026-07-28, देखा गया 2026-08-29)

• Context7 रिपॉजिटरी, मुद्दा #2723, "MCP OAuth एंडपॉइंट के लिए OAuth मेटाडेटा जारीकर्ता असंगति": https://github.com/upstash/context7/issues/2723 (प्रकाशित 2026-06-05, देखा गया 2026-08-29)

• Home Assistant Core, मुद्दा #147059, OAuth मेटाडेटा में अनुपस्थित जारीकर्ता: https://github.com/home-assistant/core/issues/147059 (प्रकाशित 2025-06-17, देखा गया 2026-08-29)

• modelcontextprotocol/modelcontextprotocol रिपॉजिटरी: https://github.com/modelcontextprotocol/modelcontextprotocol (देखा गया 2026-08-29)