किसी क्लाइंट को सर्वर URL से जोड़ देने भर से उसे सुरक्षित खाता डेटा की एक्सेस नहीं मिलती। OAuth की मदद से क्लाइंट एक ऑथराइज़ेशन सर्वर के माध्यम से सौंपी गई एक्सेस का अनुरोध कर सकता है। ऑथराइज़ेशन सर्वर वह सेवा है जो टोकन जारी करती है।
MCP ऑथराइज़ेशन स्पेसिफ़िकेशन HTTP ट्रांसपोर्ट के लिए यह फ़्लो परिभाषित करता है। MCP इम्प्लीमेंटेशन के लिए ऑथराइज़ेशन वैकल्पिक है। लोकल stdio सर्वर क्रेडेंशियल के लिए एक अलग व्यवस्था का उपयोग करते हैं।
क्लाइंट को कैसे पता चलता है कि साइन इन कहाँ करना है?
क्लाइंट अपना ऑथराइज़ेशन सर्वर खोजने के लिए MCP सर्वर का protected-resource मेटाडेटा पढ़ता है।
डिस्कवरी नियमों के अनुसार, सर्वर 401 प्रतिक्रिया के WWW-Authenticate हेडर में वह मेटाडेटा URL दे सकता है। क्लाइंट well-known मेटाडेटा पाथ के ज़रिए भी डिस्कवरी करते हैं।
मेटाडेटा का authorization_servers फ़ील्ड बताता है कि कौन-से ऑथराइज़ेशन सर्वर उपलब्ध हैं। क्लाइंट चुने गए सर्वर का मेटाडेटा प्राप्त करता है, ताकि उसके एंडपॉइंट और समर्थित क्षमताओं का पता चल सके।
क्लाइंट अपनी पहचान कैसे बताता है?
क्लाइंट ऑथराइज़ेशन सर्वर द्वारा समर्थित किसी रजिस्ट्रेशन तरीके से क्लाइंट ID प्राप्त करता है।
MCP रजिस्ट्रेशन नियम पहले से रजिस्टर की गई क्लाइंट जानकारी उपलब्ध होने पर उसी को प्राथमिकता देते हैं। ऐसी जानकारी न होने पर, यदि सर्वर समर्थन की घोषणा करता है, तो क्लाइंट Client ID Metadata Documents का उपयोग कर सकते हैं।
Client ID Metadata Document एक JSON दस्तावेज़ है, जो किसी HTTPS URL पर रहता है और क्लाइंट का विवरण देता है। यही URL उसकी क्लाइंट ID का काम करता है।
ये नियम डायनेमिक क्लाइंट रजिस्ट्रेशन को अप्रचलित घोषित करते हैं। इस तरीके में क्लाइंट किसी रजिस्ट्रेशन एंडपॉइंट से ID का अनुरोध करता है। स्पेसिफिकेशन इस तरीके को उन ऑथराइज़ेशन सर्वरों के साथ संगतता के लिए बनाए रखता है जो मेटाडेटा दस्तावेज़ों का समर्थन नहीं करते।
क्लाइंट टोकन कैसे प्राप्त करता है?
ऑथराइज़ेशन सर्वर द्वारा अनुमति स्वीकृत होने के बाद क्लाइंट एक ऑथराइज़ेशन कोड के बदले एक्सेस टोकन प्राप्त करता है।
ऑथराइज़ेशन कोड सुरक्षा नियम PKCE को अनिवार्य करते हैं, जो इस आदान-प्रदान को उसी क्लाइंट से बांधता है जिसने इसे शुरू किया था। क्लाइंट एक गुप्त वेरिफ़ायर बनाता है और उससे निकाला गया चैलेंज अपने ऑथराइज़ेशन अनुरोध के साथ भेजता है। कोड भुनाते समय वह वेरिफ़ायर देता है। इससे बीच में पकड़ा गया कोड कोई दूसरा कॉलर इस्तेमाल नहीं कर पाता।
स्कोप और लक्षित संसाधन क्या नियंत्रित करते हैं?
स्कोप माँगी गई अनुमतियों का वर्णन करते हैं। लक्षित संसाधन उस सर्वर की पहचान करता है जिसके लिए क्लाइंट टोकन का अनुरोध करता है।
स्कोप चयन नियम के अनुसार, चैलेंज में scope मान दिया गया हो तो क्लाइंट को उसी का उपयोग करना चाहिए। क्लाइंट को उतनी ही एक्सेस माँगनी चाहिए जितनी उसके ऑपरेशन को चाहिए।
क्लाइंट ऑथराइज़ेशन और टोकन अनुरोधों में resource पैरामीटर शामिल करता है। मिला हुआ टोकन वह सुरक्षित HTTP अनुरोधों पर Authorization हेडर में भेजता है। अनुरोध पाने वाला सर्वर जाँचता है कि टोकन उसी के लिए जारी किया गया था।
किसी टूल को चलाने की अनुमति होने से यह साबित नहीं होता कि कोई खास कॉल उपयोगकर्ता के काम से मेल खाती है। प्रस्तावित कार्रवाई आगे बढ़ाई जाए या नहीं, यह फिर भी होस्ट तय करता है।
मैं किसी क्लाइंट को Bird इस्तेमाल करने के लिए अधिकृत कैसे करूँ?
आप Bird का होस्ट किया गया MCP URL किसी संगत क्लाइंट में जोड़ें और उसका ब्राउज़र साइन-इन पूरा करें।
Bird का प्रलेखित हैंडशेक डायनामिक क्लाइंट पंजीकरण का उपयोग करता है। यह Bird के कनेक्शन फ़्लो का वर्णन करता है, जो विनिर्देश के पसंदीदा मेटाडेटा-दस्तावेज़ तंत्र से अलग है।
सहमति स्क्रीन पर चुनें कि आप वर्कस्पेस या संगठन की कौन-सी अनुमतियाँ सौंपना चाहते हैं। अनुदान तीन बातों से सीमित होता है: क्लाइंट क्या अनुरोध करता है, आप क्या स्वीकृत करते हैं और आपके पास कौन-सी अनुमतियाँ हैं।
क्लाइंट का दिखाया गया नाम क्लाइंट स्वयं बताता है, इसलिए पुष्टि करें कि यह उसी क्लाइंट से मेल खाता है जिसे आपने शुरू किया था। आप अपनी प्रोफ़ाइल में Connected apps से इसका अनुदान रद्द कर सकते हैं।
अगर आपके अनुदान में किसी टूल को चलाने की अनुमति नहीं है, तब भी वह टूल सूची में दिख सकता है। सफल whoami कॉल साइन-इन की गई पहचान की पुष्टि करती है। अनुरोधित ऑपरेशन के लिए फिर भी उसकी अपनी अनुमतियाँ चाहिए।
स्थानीय bird mcp प्रोसेस के लिए सर्वर CLI के सहेजे गए लॉगिन का दोबारा उपयोग करता है। MCP सेटअप गाइड उस अलग तरीके का वर्णन करती है।