Phase 13: Tools & Protocols

उत्पादन में एमसीपी लेखकः जारीकर्ता-बाउंड पंजीकरण और टोकन

पाठ 16 ने OAuth 2.1 स्टेट मशीन का निर्माण किया। यह पाठ MCP 2026-07-28 के लिए अपनी उत्पादन सीमाओं को कठोर करता हैः क्लाइंट आईडी मेटाडेटा डॉक्यूमेंट्स पहले, केवल संगतता के लिए अप्रचलित गतिशील पंजीकरण, प्राधिकरण-उत्तर जारीकर्ता सत्यापन, जारीकर्ता-की क्लाइंट क्रेडेंशियल, JWKS अपडेट, और प्रत्येक राज्यहीन अनुरोध पर दर्शकों द्वारा चिपकाए गए टोकन।

Spec note (2026-07-28):डायनामिक क्लाइंट रजिस्ट्रेशन क्लाइंट आईडी मेटाडेटा डॉक्यूमेंट्स के पक्ष में अप्रचलित है। डीसीआर एक संगतता तंत्र बना रहता है। जब इसका उपयोग किया जाता है, तो क्लाइंट सही घोषित करता है application_type. एक ग्राहक वर्तमान आरएफसी 9207 को मान्य करता है issप्राधिकरण सर्वर जारीकर्ताओं के बीच क्रेडेंशियल का मूल्य और कभी पुनः उपयोग नहीं करता है।

Type: Build

Languages: Python (stdlib)

Prerequisites: Phase 13 · 16 (OAuth 2.1 state machine), Phase 13 · 17 (gateways)

Time: ~90 minutes

सीखने के लक्ष्य

आरएफसी 8414 मेटाडेटा के माध्यम से एक प्राधिकरण सर्वर का पता लगाएं और अनुबंध की पुष्टि करें।
क्लाइंट आईडी मेटाडेटा दस्तावेज़ में पंजीकरण करें और अप्राप्य डीसीआर को एक बैकअप के रूप में अलग करें।
आरएफसी 9207 को मान्य करें iss, प्राधिकरण सर्वर जारीकर्ता द्वारा प्रमुख पंजीकरण, और जारीकर्ता प्लस संसाधन द्वारा संसाधन-बाध्य टोकन।
एक कार्यक्रम पर JWKS कुंजी को कैश और ताज़ा करें ताकि हस्ताक्षर सत्यापन कुंजी रोल-ओवर से बच सके।
आरएफसी 8707 संसाधन संकेतकों का उपयोग करके एक एकल एमसीपी संसाधन पर टोकन को चिपकाएं और भ्रमित-उपयुक्त पुनः उपयोग से इनकार करें।
JWT सत्यापन या टोकन अंतर्दृष्टि चुनें, निरसन ताजापन को परिभाषित करें, और सुरक्षित रूप से विफल करें जब पहचान निर्भरता अनुपलब्ध है।
प्राधिकरण सर्वर, संसाधन सर्वर और क्लाइंट को अलग करें ताकि प्रत्येक केवल अपनी जांच लागू करे।
एक तैनाती चेकलिस्ट के खिलाफ एक प्राधिकरण सर्वर का ऑडिट करें और असुरक्षित नामांकन या टोकन पुनः उपयोग से इनकार करें।

समस्या

पाठ 16 सिम्युलेटर मेमोरी में OAuth 2.1 चलाता है। उत्पादन में तीन परिचालन अंतराल हैं जो केवल मेमोरी सिम्युलेटर नहीं देखता है।

पहला अंतर नामांकन और क्रेडेंशियल अलगाव है। एक वास्तविक संगठन सैकड़ों एमसीपी सर्वर और हजारों एमसीपी क्लाइंट चला सकता है। 2026-07-28 संशोधन एक Client ID Metadata Document: क्लाइंट एक HTTPS URL का उपयोग करता है जिसमें एक पथ है जिसे वह पहचानकर्ता के रूप में नियंत्रित करता है, और प्राधिकरण सर्वर मेटाडेटा खींचता है। आरएफसी 7591 गतिशील पंजीकरण केवल एक अप्रचलित संगतता पथ के रूप में रहता है। जब डीसीआर अपरिहार्य है, तो अनुरोध सही घोषित करता है application_type. ग्राहक प्राधिकरण-सेवर जारीकर्ता के तहत रजिस्ट्रेशन और एक्सेस टोकन के तहत (issuer, resource)एक बदल गया जारीकर्ता एक नया नामांकन का मतलब है, और एक अलग संसाधन का मतलब है एक अलग दर्शक-बाध्य टोकन.

दूसरा अंतर कुंजी घूर्णन है। JWT सत्यापन प्राधिकरण सर्वर के हस्ताक्षर कुंजी पर निर्भर करता है, जो एक JSON वेब कुंजी सेट (JWKS) के रूप में प्रकाशित होता है। प्राधिकरण सर्वर इनको एक समयरेखा पर घूमता है (अक्सर प्रति घंटे, कभी-कभी घटना प्रतिक्रिया के तहत तेजी से) । एक MCP सर्वर जो एक बार बूट पर JWKS लाता है फिर से शुरू होने तक हर अनुरोध विफल रहता है। उत्पादन तारों के साथ JWKS एक कैश मान के रूप में एक ताज़ा कार्य है कि पिछले कुंजी समाप्त होने से पहले कैश ओवरराइट, प्लस एक fall-back कैश पर कैश मिस के लिए मामले में जब एक टोकन द्वारा हस्ताक्षरित एक कुंजी से नया कैश से पहुंचता है के लिए.

तीसरा अंतर दर्शकों को बाध्यकारी है। पाठ 16 ने आरएफसी 8707 संसाधन संकेतक पेश किए। उत्पादन में, यह संकेतक प्रत्येक अनुरोध पर एक कठिन दावा जांच बन जाता है। एमसीपी सर्वर तुलना करता है token.audअपने स्वयं के कैनोनिक संसाधन URL के खिलाफ और HTTP 401 के साथ असंगतियों को अस्वीकार करता है। यह एक अपस्ट्रीम MCP सर्वर (या एक सर्वर के लिए एक टोकन रखने वाले दुर्भावनापूर्ण क्लाइंट) के खिलाफ एकमात्र रक्षा है जो उसी विश्वास जाल में दूसरे सर्वर के खिलाफ उस टोकन को फिर से चलाता है।

यह सबक प्रत्येक अंतराल को सतह के एक ठोस टुकड़े पर मैप करता है। मेटाडेटा दस्तावेज़ एक HTTP अंत बिंदु है। JWKS कैश अपडेट एक अनुसूचित काम प्लस एक कुंजी-मूल्य कैश है। JWT सत्यापन किसी भी उपकरण को भेजने से पहले संसाधन सर्वर चलाने की एक दिनचर्या है। तीनों भूमिकाओं को अलग रखें और प्रत्येक केवल अपने स्वामित्व वाले चेक को लागू करता हैः प्राधिकरण सर्वर कुंजी जारी करता है और घुमाता है, संसाधन सर्वर कैश करता है और सत्यापित करता है, क्लाइंट खोजता है और पंजीकृत करता है।

कार्यक्षेत्रः पाठ 16 के बाद उत्पादन प्रवर्तन

Lesson 16: MCP Security with OAuth 2.1यह पाठ एक दूसरे OAuth प्रवाह को परिभाषित नहीं करता है। यह उन अनुबंधों के अस्तित्व के बाद शुरू होता है और पूछता है कि एक तैनात संसाधन सर्वर कुंजी रोटेशन, अपारदर्शी टोकन सत्यापन, निरसन, निर्भरता विफलता, रोलआउट और घटना प्रतिक्रिया के दौरान उन्हें कैसे लागू करता है।

उत्पादन सीमा संकीर्ण और अधिक परिचालन है:

एक JWT पथ प्रत्येक अनुरोध पर एक चिपकाए हुए जारीकर्ता, एल्गोरिथ्म, हस्ताक्षर कुंजी, दर्शकों, समय के दावे और स्कोप की पुष्टि करता है जबकि JWKS को सुरक्षित रूप से ताज़ा करता है।
एक अस्पष्ट-टोकन पथ जारीकर्ता के प्रमाणित अंतनिरीक्षण अंत बिंदु को बुलाता है और लौटाए गए सक्रिय राज्य, दर्शकों या संसाधन, समाप्ति, विषय और दायरे को मान्य करता है।
निरसन नीति यह निर्धारित करती है कि प्रमाण पत्र को कितनी जल्दी काम करना बंद करना चाहिए और कौन सा कैश उस तथ्य को देरी कर सकता है।
विफलता नीति तय करती है कि जब खोज, JWKS, आत्मनिरीक्षण, या निरसन बुनियादी ढांचा अनुपलब्ध हो तो क्या होता है।
सबूत रिकॉर्ड जो जारीकर्ता मेटाडेटा, कुंजी सेट या अंतर्दृष्टि प्रतिक्रिया, टोकन दावों, नीति संस्करण और अस्वीकृति कारण टोकन को संग्रहीत किए बिना परिणाम चलाते हैं।

यह अंतर सबक को संगठित रखता है। पाठ 16 प्रवाह को साबित करता है। पाठ 18 साबित करता है कि एक टोकन विश्वसनीय रहता है, या अस्वीकार कर दिया जाता है, जब यह एक वास्तविक MCP अनुरोध पथ तक पहुंच जाता है।

अवधारणा

आरएफसी 8414 OAuth प्राधिकरण सर्वर मेटाडेटा

/.well-known/oauth-authorization-serverग्राहक की जरूरतों की सभी चीजों का वर्णन करता हैः

json{
  "issuer": "https:TOK0
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https:TOK2
  "jwks_uri": "https://auth.example.com/.well-known/jwks.json",
  "client_id_metadata_document_supported": true,
  "registration_endpoint": "https:TOK4
  "authorization_response_iss_parameter_supported": true,
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"],
  "scopes_supported": ["mcp:tools.read", "mcp:tools.invoke"],
  "token_endpoint_auth_methods_supported": ["none", "private_key_jwt"]
}

एक क्लाइंट को MCP संसाधन URL चेन का पता लगाने के लिए दिया गयाः oauth-protected-resourceआरएफसी 9728 (स्रोत सर्वर का दस्तावेज) से जारीकर्ता का नाम, फिर oauth-authorization-server(इस आरएफसी) प्रत्येक अंत बिंदु का नाम. क्लाइंट कभी भी हार्ड कोड प्राधिकरण URL.

पथ के साथ संसाधन पहचानकर्ता के लिए, उस पथ से पहले ज्ञात खंड डालें। उदाहरण के लिए, https://mcp.example.com/team/server पर संरक्षित संसाधन मेटाडेटा को हल करता हैhttps://mcp.example.com/.well-known/oauth-protected-resource/team/server. जोड़ने ./.well-known/...संसाधन पथ गलत होने के बाद।

एमसीपी के लिए एक आईडीपी को विश्वास करने से पहले आप अनुबंध की पुष्टि करते हैंः

code_challenge_methods_supportedशामिल है S256(RFC 7636 प्रति PKCE) विनिर्देश स्पष्ट हैः यदि यह क्षेत्र absent, प्राधिकरण सर्वर PKCE और क्लाइंट का समर्थन नहीं करता है MUSTआगे बढ़ने से इनकार कर दिया।
grant_types_supportedशामिल है authorization_codeऔर अस्वीकार करता है passwordऔर implicit. .
कम से कम एक नामांकन पथ उपलब्ध हैः client_id_metadata_document_supported: true(CIMD, प्राथमिकता), पूर्व पंजीकृत ग्राहक, या registration_endpoint(RFC 7591 संगतता में कमी आई) ।
यदिauthorization_response_iss_parameter_supportedसही है, ग्राहक को वापस RFC 9207 की आवश्यकता हैissऔर इसे पुनर्निर्देशन से पहले दर्ज किए गए जारीकर्ता के साथ सटीक रूप से तुलना करता है।
response_types_supportedठीक है["code"]OAuth 2.1. के लिए।

यदिS256यदि कोई भी प्रवेश मार्ग विज्ञापन में नहीं है और आपके पास कोई पूर्व पंजीकृत नहीं है तोclient_id, आप भी पंजीकरण नहीं कर सकते; तैनाती घोषणा पत्र गलत है, कोड नहीं है।

आरएफसी 9728 (पुनर्विचार) संरक्षित संसाधन मेटाडेटा

पाठ 16 आरएफसी 9728 को कवर करता है। उत्पादन में डेल्टाः यह दस्तावेज़ एकमात्र स्थान है जहां एक क्लाइंट इस एमसीपी सर्वर द्वारा विश्वसनीय प्राधिकरण सर्वर खोजने के लिए देखता है। एक एकल एमसीपी सर्वर कई आईडीपी (एक कर्मचारी के लिए, एक भागीदारों के लिए) से टोकन स्वीकार कर सकता है। आरएफसी 9728 उस सेट को घोषित करता है; आरएफसी 8414 दस्तावेज करता है कि प्रत्येक आईडीपी क्या समर्थन करता है।

json{
  "resource": "https:TOK0
  "authorization_servers": ["https://auth.example.com", "https://partners.example.com"],
  "scopes_supported": ["mcp:tools.invoke"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://notes.example.com/docs"
}

क्लाइंट आईडी मेटाडेटा दस्तावेज (अनुशंसित डिफ़ॉल्ट)

CIMD पंजीकरण को पुश से प्लग में परिवर्तित करता है। प्राधिकरण सर्वर से एक को mint करने के बजाय client_id, क्लाइंट एक HTTPS URL का उपयोग करता है कि यह नियंत्रित करता है asclient_id. URL एक JSON मेटाडेटा दस्तावेज़ में हल हो जाता है; प्राधिकरण सर्वर इसे OAuth प्रवाह के दौरान मांग पर प्राप्त करता है. विश्वास DNS में जड़ है: यदि सर्वर ऑपरेटर भरोसा करता है app.example.com, यह ग्राहक से सेवा की है से भरोसा करता हैhttps://app.example.com/client.json. कोई पंजीकरण नहीं, नहीं.client_idनाम स्थान को निकास, प्रति सर्वर स्थिति के लिए सिंक्रनाइज़ करने के लिए नहीं.

ग्राहक मेटाडेटा दस्तावेज़ होस्ट करता हैः

json{
  "client_id": "https:TOK0
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "application_type": "native",
  "redirect_uris": ["http:TOK2
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

client_idदस्तावेज़ में मूल्य MUSTयह URL से सेवा की जाती है (अनुमति सर्वर यह सत्यापित करता है; असंगतियां अस्वीकार कर दिया जाता है) । अनुमति सर्वर समर्थन के साथ विज्ञापन करता है client_id_metadata_document_supported: trueइसके RFC 8414 मेटाडेटा में।

वर्तमान सीआईएमडी अनुबंध के लिए, client_id,client_name, और एक गैर-खाली redirect_urisसरणी आवश्यक है. क्लाइंट पहचानकर्ता एक पथ के साथ एक पूर्ण HTTPS URL है. application_typeDCR आवश्यकता को कॉपी न करें application_typeCIMD मार्ग में जाना।

सुरक्षा के दो तथ्यों के बारे में विनिर्देश स्पष्ट हैः

SSRF.प्राधिकरण सर्वर हमलावर द्वारा प्रदान किए गए URL को प्राप्त करता है। यह सर्वर-साइड अनुरोध जालसाजी (आंतरिक / व्यवस्थापक अंत बिंदुओं पर कोई प्राप्त नहीं) के खिलाफ रक्षा करना चाहिए।
localhost impersonation.सीआईएमडी अकेले स्थानीय हमलावरों को वैध ग्राहक के मेटाडेटा यूआरएल का दावा करने और किसी भी को बाध्य करने से नहीं रोक सकता localhostअनुमतियों सर्वर MUSTसहमति के दौरान स्पष्ट रूप से पुनर्निर्देशित यूआरआई होस्टनाम प्रदर्शित करें और SHOULDचेतावनी पर localhost- केवल पुनर्निर्देशित.

क्योंकि सीआईएमडी को सर्वर-साइड स्टेट की आवश्यकता नहीं है, इसलिए डीसीआर की आवश्यकता के रूप में खड़े होने के लिए कोई रजिस्ट्रार नहीं है। क्लाइंट पक्ष केवल-पढ़ने के लिए हैः अपने मेटाडेटा दस्तावेज़ को एक स्थिर एचटीटीपीएस एंडपॉइंट से सर्व करें और प्राधिकरण सर्वर को इसे खींचने दें।

यदि प्राधिकरण सर्वर ऑपरेटर ने पहले से ही क्लाइंट पहचानकर्ता प्रदान किया है, तो स्वचालित नामांकन की कोशिश करने से पहले जारीकर्ता-स्कोप पंजीकरण का उपयोग करें। अन्यथा CIMD को प्राथमिकता दें। केवल तब अप्रचलित DCR का उपयोग करें जब जारीकर्ता पूर्व-रजिस्टर या CIMD का उपयोग नहीं कर सकता है।

आरएफसी 7591: अप्रचलित संगतता नामांकन

DCR 2026-07-28 संशोधन में अप्रचलित है। इसे केवल उन प्राधिकरण सर्वर के लिए रखें जो CIMD का उपभोग नहीं कर सकते हैं और जहां पूर्व-पंजीकरण अप्रैक्टिकल है। एक संगतता क्लाइंट पोस्ट करता हैः

jsonPOST /register
Content-Type: application/json

{
  "application_type": "native",
  "redirect_uris": ["http:TOK0
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none",
  "scope": "mcp:tools.invoke",
  "client_name": "Cursor",
  "software_id": "com.cursor.cursor",
  "software_version": "0.42.0"
}

सर्वर प्रतिक्रिया करता है client_idऔर एक registration_access_tokenबाद के अपडेट के लिएः

json{
  "client_id": "c_3e7f1a",
  "client_id_issued_at": 1769472000,
  "redirect_uris": ["http:TOK0
  "grant_types": ["authorization_code", "refresh_token"],
  "registration_access_token": "regt_b2...",
  "registration_client_uri": "https://auth.example.com/register/c_3e7f1a"
}

application_typeएक लूपबैक डेस्कटॉप क्लाइंट घोषणा करता हैnative; सर्वर होस्ट क्लाइंट घोषित करता है webऔर HTTPS रीडायरेक्ट यूआरआई का उपयोग करता है। token_endpoint_auth_method: noneयह एक सार्वजनिक मूल ग्राहक के लिए सही डिफ़ॉल्ट है।client_idकेवल, PKCE द्वारा स्वामित्व का प्रमाण प्रदान किया जाए।

तीन उत्पादन जालः

पंजीकरण के अंत बिंदु स्रोत आईपी द्वारा रेट-सीमा होनी चाहिए। इसके बिना, एक शत्रुतापूर्ण अभिनेता लाखों नकली पंजीकरणों को स्क्रिप्ट करता है और client_idरजिस्ट्रार अनुरोध को संभालने से पहले दर सीमा की जांच करें।
software_statement(ग्राहक के लिए हस्ताक्षरित JWT वारंटी) कुछ उद्यम आईडीपी द्वारा आवश्यक है। पाठ का नकली इसे छोड़ देता है; उत्पादन तारों एक सत्यापन चरण जो स्थानीय होस्ट रीडायरेक्ट यूआरआई के अलावा किसी भी अन्य से हस्ताक्षरित पंजीकरण को अस्वीकार करता है।
registration_access_tokenइस टोकन की चोरी का मतलब है कि हमलावर क्लाइंट के पुनर्निर्देशित यूआरआई को फिर से लिख सकता है।

आरएफसी 8707 (पुनर्विचार) संसाधन संकेतकों

पाठ 16 आकार निर्धारित किया। उत्पादन नियमः प्रत्येक टोकन अनुरोध शामिल है resource=<canonical-mcp-url>, और MCP सर्वर सत्यापित करता है token.audप्रत्येक कॉल पर अपना स्वयं का संसाधन URL मेल खाता है। कैनोनिक यूआरआई सर्वर के लिए सबसे विशिष्ट पहचानकर्ता हैः यह छोटे अक्षरों की योजना और होस्ट का उपयोग करता है, कोई टुकड़ा नहीं है, और पारंपरिक रूप से कोई पिछली स्लैश नहीं है। पथ घटक हैnotनियम द्वारा हटा दिया गया विशिष्टता इसे जब किसी व्यक्तिगत MCP सर्वर की पहचान करने के लिए आवश्यक हो तब रखती है। https://mcp.example.com,https://mcp.example.com/mcp,https://mcp.example.com:8443और https://mcp.example.com/server/mcpसभी मान्य कैनोनिक यूआरआई हैं. प्रत्येक सर्वर और पिन पर एक चुनेंaud(इस पाठ का नकली नग्न मेजबान दर्शकों का उपयोग करता है जैसेhttps://notes.example.comसंक्षिप्तता के लिए; एक तैनाती जो एक मूल के तहत कई MCP सर्वर को सह-होस्ट करती है, उन्हें पथ द्वारा अलग करती है।

आरएफसी 7636 (पुनर्विचार) PKCE

पीकेसीई अनिवार्य है OAuth 2.1. पाठ के अनुमोदन-कोड प्रवाह हमेशा ले जाता है code_challengeऔर code_verifier. सर्वर सत्यापनकर्ता के बिना या सत्यापनकर्ता के साथ किसी भी टोकन अनुरोध को अस्वीकार करता है जो संग्रहीत चुनौती के लिए हैश नहीं करता है।

एमसीपी 2026-07-28 प्राधिकरण प्रोफ़ाइल

वर्तमान एमसीपी संशोधन एमसीपी परिवहन को निष्क्रिय करते हुए ओएथ संसाधन-सर्वर सीमा को बनाए रखता है। कोई प्रोटोकॉल सत्र नहीं है जिसमें पहचान निर्णय को कैश किया जा सके। इसलिए प्राधिकरण परत प्रत्येक अनुरोध को स्वतंत्र रूप से मान्य करती हैः

आरएफसी 9728 संरक्षित संसाधन मेटाडेटा को लागू करें, और या तो WWW-Authenticate: Bearer resource_metadata="..."एक 401 पर हेडरorप्रसिद्ध यूआरआई /.well-known/oauth-protected-resource(SEP-985 ने हेडर को वैकल्पिक बनाया है जिसमें एक प्रसिद्ध fallback है) मेटाडेटा authorization_serversक्षेत्र MUSTकम से कम एक सर्वर का नाम दें।
केवल के माध्यम से टोकन स्वीकार करेंAuthorization: Bearer ...परeveryअनुरोध कभी भी क्वेरी स्ट्रिंग में नहीं, कभी भी केवल सत्र की शुरुआत में मान्य नहीं किया गया।
वैधताaud,iss,exp, और अनुरोध प्रति आवश्यक दायरा. सर्वर MUSTपुष्टि करें कि टोकन को विशेष रूप से इसके लिए जारी किया गया था (दर्शक); एक गायब या असमान audअस्वीकार कर दिया जाता है, कभी भी वाइल्डकार्ड के रूप में नहीं माना जाता है।
401/403 पर, वापसी WWW-Authenticate: Bearerले जाने वालाerror=..., resource_metadata="<PRM-URL>"पैरामीटर (मेटाडेटा दस्तावेज़ का URL, नहीं खाली संसाधन) और scope="..."परinsufficient_scopeनोटः पैरामीटर resource_metadata, एक खोज सूचक वहाँ नहीं है resourceचुनौती में पैरामीटर।
प्राधिकरण-सेवर खोज स्वीकार करता है eitherआरएफसी 8414 ओएथ मेटाडेटा orOpenID Connect Discovery 1.0; ग्राहकों को प्राथमिकता क्रम में दोनों ज्ञात प्रत्ययों का प्रयास करना होगा।
ग्राहक (सेवर नहीं) mix-up attacks: यह अपेक्षित रिकॉर्ड करता है issuerपुनर्निर्देशित करने और सत्यापित करने से पहले issकोड को रिडिम करने से पहले वास्तविक प्राधिकरण प्रतिक्रिया (RFC 9207) में लौटाया गया मूल्य। PKCE अकेले भ्रमित करने से नहीं रोकता, क्योंकि ग्राहक अपने code_verifierजिस भी निशान की ओर वह चलाया गया था।
एक ग्राहक क्रेडेंशियल एक प्राधिकरण-सेवर जारीकर्ता से संबंधित है। यदि खोज एक अन्य जारीकर्ता को हल करती है, तो ग्राहक पुराने को प्रस्तुत करने के बजाय पुनः नामांकित करता है client_id, पंजीकरण टोकन, या एक्सेस टोकन।
CIMD नामांकन के लिए पसंदीदा तंत्र है। DCR अप्रचलित है; एक संगतता DCR अनुरोध अभी भी सही घोषित करता है application_type. .

OAuth 2.1 ड्राफ्ट सब्सट्रेट है; RFC 8414/7591/8707/9728/9207 + RFC 7636 + CIMD सतह है; MCP विनिर्देश प्रोफ़ाइल है।

तैनाती क्षमता की जाँच सूची

विक्रेता सुविधा तालिकाओं जल्दी से पुराना हो जाता है. प्राधिकरण सर्वर द्वारा लौटाया गया मेटाडेटा की जांच करें आप वास्तव में तैनात करने के बजाय. गेट यांत्रिक हैः

Check	Required decision
Discovered issuer	Exact HTTPS issuer expected by policy
PKCE	`S256` advertised; otherwise stop
Enrollment	CIMD preferred, pre-registration accepted, DCR only as deprecated compatibility
Authorization response	Validate RFC 9207 `iss` when present or advertised
Resource binding	Token request carries `resource`; resource server requires the matching `aud`
Credential storage	Key client IDs and registration credentials by issuer; key access tokens by issuer plus resource
DCR compatibility	Declare `native` or `web`; reject redirect URIs that do not fit the declared application type

किसी उत्पाद नाम या मूल्य निर्धारण स्तर से समर्थन का अनुमान न लगाएं। डिप्लोयमेंट सबूत में खोजे गए दस्तावेज़ को कैप्चर करें और जब कोई अनिवार्य फ़ील्ड अनुपस्थित हो तो बंद न करें।

JWKS रिफ्रेश पैटर्न (एएस पर घूमना, संसाधन सर्वर पर रिफ्रेश करना)

दो क्रियाओं को अलग रखें, क्योंकि उन्हें मिलाकर बनाना एक वास्तविक उत्पादन बग है:

Rotateयह वही है जो प्राधिकरण सर्वर करता हैः एक नई हस्ताक्षर कुंजी को मचाएं, इसे JWKS में प्रकाशित करें, बाद में पुराने को हटा दें। संसाधन सर्वर का इसमें कोई हिस्सा नहीं है और यह नहीं कर सकता है यह आईडीपी की निजी कुंजी नहीं रखता है।
Refreshयह है कि स्रोत सर्वर क्या करता हैःGETयह केवल एक JWKS कार्रवाई है जो संसाधन सर्वर कभी करता है।

उत्पादन विफलता मोड एक पुराने कैश है. इसे एक निर्धारित ताज़ा कार्य के साथ हल करें प्लस एक कुंजी-मूल्य कैश। संसाधन सर्वर एक कार्य (क्रॉन, टाइमर, जो भी आपके रनटाइम की पेशकश करता है) चलाता है जो, एक निश्चित अंतराल पर, लाता है <issuer>/.well-known/jwks.jsonऔर ओवरराइट्स cache[issuer] = {keys, fetched_at}. वैलिडेटर उस कैश से पढ़ता है. एक टोकन जिसका .kidकैश ट्रिगर से गायब है oneएक समवर्ती ताज़ा करने के रूप में एक गिरावट वापस, फिर फिर से जांच. यह एक ही समय में दो मामलों को संभालनेः नियोजित ताज़ा करने के लिए, और कुंजी ओवरलैप खिड़कियों जहां एक टोकन एक नई कुंजी द्वारा हस्ताक्षरित अगले नियोजित ताज़ा करने से पहले आता है.

पतन वापस must be a re-fetch, never a rotate. यदि आप कैश-मिस पथ को एक घुमावदार-और-मिंट के लिए तार करते हैं, तो दो चीजें टूट जाती हैंः (1) एक नई कुंजी कामिट करने से एक kidकि अभी भी टोकन से मेल नहीं खाता है, इसलिए खोज वैसे भी विफल होती है; और (2) एक हमलावर जो यादृच्छिक टोकन के साथ स्प्रे करता है kidमूल्य महत्वपूर्ण रचनाओं की एक असीमित श्रृंखला को मजबूर करता है एक स्वयं-उपयोग किया DoS. एक पुनः प्राप्ति अक्षम है, इसलिए एक नकली kidअधिकतम एक व्यर्थ आहरण की लागत है।

कैश आकारः

json{
  "https:TOK0
    "keys": [
      {"kid": "k_2026_03", "kty": "RSA", "n": "...", "e": "AQAB", "alg": "RS256", "use": "sig"},
      {"kid": "k_2026_04", "kty": "RSA", "n": "...", "e": "AQAB", "alg": "RS256", "use": "sig"}
    ],
    "fetched_at": 1772668800
  }
}

दो कुंजी एक ही समय में स्थिर स्थिति है. प्राधिकरण सर्वर अगले कुंजी (k_2026_04) से पहले सेवानिवृत्त होने से पहले (k_2026_03), इसलिए पुराने कुंजी के तहत जारी किए गए टोकन समाप्त होने तक वैध रहते हैं। कैश में संघ रहता है; सत्यापितकर्ता द्वारा चुनता है kid. .

सत्यापन की प्रक्रिया

MCP सर्वर किसी भी उपकरण भेजने से पहले सत्यापन चलाता है.code/main.pyउपयोगः

pythonresult = server.validate(bearer_token, required_scope="mcp:tools.invoke")
if not result["valid"]:
    return {"status": result["status"], "WWW-Authenticate": result["www_authenticate"]}

validateJWT को डिक्रिप्ट करता है, JWKS कैश से हस्ताक्षर कुंजी को हल करता है (एक बार चूक पर ताज़ा करना), हस्ताक्षर की पुष्टि करता है, फिर जांच करता है issअनुमति सूची के खिलाफ, audइस सर्वर के कैनोनिक संसाधन के खिलाफ,exp, और आवश्यक दायरा एक WWW-Authenticateपहली विफलता पर चुनौती। संसाधन सर्वर पर इसे एक ही दिनचर्या बनाए रखने का मतलब है कि प्रत्येक प्रवेश बिंदु (प्रत्येक उपकरण कॉल, प्रत्येक परिवहन) एक ही जांच से गुजरता है; पहले सत्यापित किए बिना कोई रास्ता नहीं है जो एक उपकरण तक पहुंचता है।

अस्पष्ट टोकन में अंतर्दृष्टि का प्रयोग किया जाता है, अनुमान नहीं

प्रत्येक एक्सेस टोकन JWT नहीं है। यदि जारीकर्ता एक अस्पष्ट टोकन का दस्तावेजीकरण करता है, तो संसाधन सर्वर इसे विश्वसनीय दावे में डिकोड नहीं कर सकता है। यह एक प्रमाणित बैकचैनल पर जारीकर्ता के RFC 7662 अंतर्निहित अंत बिंदु पर टोकन भेजता है और आवश्यकता होती हैactive: true, अपेक्षित जारीकर्ता संदर्भ, सटीक MCP दर्शक या संसाधन, अप्रचलित समय का दावा, और ठोस उपकरण द्वारा आवश्यक दायरे।

जारीकर्ता द्वारा कैश अंतर्दृष्टि, एकतरफा टोकन डाइजेस्ट, और एमसीपी संसाधन। लॉग या कैश लेबल के रूप में स्पष्ट टोकन का कभी भी उपयोग न करें। टोकन की समाप्ति की सबसे जल्दी, जारीकर्ता के कैश मार्गदर्शन और तैनाती की निरसन ताजापन उद्देश्य द्वारा एक सकारात्मक कैश प्रविष्टि को बाध्य करें। नकारात्मक कैशिंग को इतना छोटा रखें कि एक नया जारी किया गया टोकन गलत तरीके से निष्क्रिय न रहे। एक संसाधन के लिए एक परिणाम दूसरे संसाधन को अधिकृत नहीं कर सकता है, भले ही अस्पष्ट टोकन स्ट्रिंग समान हो।

हमलावर द्वारा नियंत्रित टोकन सामग्री से सत्यापन मोड का चयन न करें। सत्यापित जारीकर्ता मेटाडेटा और तैनाती विन्यास के लिए JWT बनाम आत्मनिरीक्षण व्यवहार को पिन करें। JWT पथ पर, पिन स्वीकार किए गए एल्गोरिदम और विश्वसनीय हैं।jwks_uri; कभी भी किसी कुंजी URL या एल्गोरिथ्म का अनुसरण न करें जो केवल टोकन हेडर द्वारा चुना गया हो।

निरस्त एक ताजापन अनुबंध है

आरएफसी 7009 एक क्लाइंट को एक टोकन को वापस लेने के लिए एक प्राधिकरण सर्वर से पूछने देता है। यह अनुरोध प्रत्येक संसाधन सर्वर द्वारा पहले से ही कैश की गई प्रतियों को नहीं हटाता है। अधिकतम स्वीकार्य निरसन देरी को परिभाषित करें और प्रत्येक कैश को इसे सम्मान दें।

अपारदर्शी टोकन तैनाती प्रत्येक उच्च जोखिम वाले कॉल पर आत्मनिरीक्षण करके या एक छोटा सकारात्मक कैश का उपयोग करके अधिक सख्त निरसन प्राप्त कर सकती है। स्व-निहित JWT तैनाती आमतौर पर रिफ्रेश-टोकन निरसन, जारीकर्ता-व्यापी घटनाओं के लिए कुंजी सेवानिवृत्ति और आपातकालीन स्थानीय अस्वीकरण के लिए एक वैकल्पिक विषय, सत्र या टोकन-आईडी डेनिल सूची के साथ उपयोग के अल्पकालिक जीवन को जोड़ती है। हस्ताक्षरित JWT समाप्ति तक क्रिप्टोग्राफिक रूप से मान्य रहता है, जब तक संसाधन सर्वर के पास वर्तमान बाहरी निरस्तता प्रमाण नहीं है।

लॉग आउट, खाता निष्क्रिय करना, सहमति वापस लेना और घटना प्रतिक्रिया अलग-अलग ट्रिगर हैं लेकिन एक मापने योग्य कथन पर एकजुट होना चाहिएः अधिकतम घोषित निरसन विंडो के बाद, प्रत्येक प्रतिकृति क्रेडेंशियल से इनकार करती है। लोड बैलेंसर के माध्यम से उस कथन का परीक्षण करें, न कि केवल एक गर्म प्रक्रिया के खिलाफ।

निर्भरता विफलता के लिए घोषित निर्णय की आवश्यकता है

कभी भी अपवाद संभालने वाले के अंदर उपलब्धता नीति में सुधार न करें।

Failure	Safe production behavior
Scheduled JWKS refresh fails, known `kid` remains in a still-valid bounded cache	Continue only within the declared stale-on-error window and emit degraded health evidence
Token has an unknown `kid` and the one allowed refresh fails	Reject; never accept an unverifiable signature
Introspection is unavailable	Fail closed for protected calls; do not convert network failure into `active: true`
Protected-resource or issuer metadata changes unexpectedly	Stop new enrollment and token acquisition; keep only explicitly pinned, unexpired configuration under a bounded incident policy
Revocation endpoint is unavailable	Report logout or revocation as incomplete, retain the credential locally as unusable when possible, and do not claim global revocation succeeded
Clock source or claim type is invalid	Reject rather than widening skew until the token passes

अवैध क्रेडेंशियल से अलग-अलग विफलताओं को वर्गीकृत करें। एक निर्भरता आउटेज स्वास्थ्य और पुनः प्रयास नीति के साथ एक परिचालन त्रुटि है। एक खराब हस्ताक्षर, जारीकर्ता, दर्शक, समाप्ति, या दायरा प्राधिकरण अस्वीकरण है। कोई भी उपकरण हैंडलर तक नहीं पहुंचता है, और किसी को भी ऑडिट सबूत में टोकन सामग्री लीक नहीं करनी चाहिए।

दर्शकों के पुनरावृत्ति के माध्यम से (प्रवेश टोकन विशेषाधिकार प्रतिबंध)

सर्वर ए (notes.example.com) और सर्वर बी (tasks.example.com) दोनों एक ही प्राधिकरण सर्वर के खिलाफ पंजीकरण करते हैं। सर्वर ए को बाधित किया गया है। हमलावर उपयोगकर्ता के नोट्स टोकन को लेता है और इसे सर्वर बी के खिलाफ पुनः चलाता है।

सर्वर बी का सत्यापनकर्ताः

JWT को डिकोड करें, JWKS को ले आओ kid, हस्ताक्षर की पुष्टि करें।
चेक करेंissइसके संरक्षित संसाधन मेटाडेटा के विरुद्ध authorization_servers. (पास वही आईडीपी)
चेक करेंaud == "https://tasks.example.com"(फेल टोकन audहै https://notes.example.com.)
401 को वापस करें WWW-Authenticate: Bearer error="invalid_token", error_description="audience mismatch", resource_metadata="https://tasks.example.com/.well-known/oauth-protected-resource". .

प्रोटोकॉल परत पर इस हमले के खिलाफ दर्शकों का दावा एकमात्र रक्षा है। प्रदर्शन के लिए इसे छोड़ना सबसे आम उत्पादन त्रुटि है; सत्यापनकर्ता को केवल सत्र की शुरुआत में नहीं, बल्कि हर अनुरोध पर चलाना चाहिए। विनिर्देश इसे कहता हैaccess-token privilege restriction: एक MCP सर्वर MUSTकिसी भी टोकन को अस्वीकार करें जो दर्शकों में उसका नाम नहीं रखे।

Naming note.विनिर्देश एक संबंधित लेकिन विशिष्ट समस्या के लिए भ्रमित सहायक शब्द को आरक्षित करता हैः एक MCP सर्वर जो OAuth के रूप में कार्य करता है proxyएक तृतीय-पक्ष एपीआई, एक स्थैतिक क्लाइंट आईडी का उपयोग करके, जो प्रति क्लाइंट उपयोगकर्ता सहमति प्राप्त किए बिना टोकन को अग्रेषित करता है। दर्शकों के बंधन ऊपर दोहराव को ठीक करता है; भ्रमित-उपयुक्त फिक्स प्रति क्लाइंट सहमति है plusइनबाउंड टोकन को अपस्ट्रीम एपीआई (एमसीपी सर्वर) पर कभी भी पारित नहीं करनाMUSTअपने स्वयं के अलग अपस्ट्रीम टोकन प्राप्त करें) ।

मिश्रित हमले (क्लाइंट-साइड रक्षा सर्वर प्रदान नहीं कर सकता है)

एक क्लाइंट अपने जीवन भर कई प्राधिकरण सर्वर से बात करता है। एक दुर्भावनापूर्ण एएस क्लाइंट को हमलावर के टोकन एंडपॉइंट पर एक ईमानदार एएस के प्राधिकरण कोड को फिर से खरीदने की कोशिश कर सकता है। दर्शकों को बाध्य करना यहां मदद नहीं करता है किसी भी टोकन के अस्तित्व से पहले हमला होता है। रक्षा क्लाइंट में रहती है (RFC 9207):

पुनर्निर्देशन से पहले, ग्राहक अपेक्षित रिकॉर्ड करता है issuerसत्यापित एसई मेटाडेटा से।
प्राधिकरण प्रतिक्रिया पर, ग्राहक लौटाया तुलना करता है issउस रिकॉर्ड किए गए जारीकर्ता के प्रति पैरामीटर (सरल स्ट्रिंग तुलना, कोई सामान्यीकरण नहीं) कोड को कहीं भी भेजने से पहले।
असंगत (या issजब एएस विज्ञापन में अनुपस्थित authorization_response_iss_parameter_supported) → अस्वीकार, और न ही प्रदर्शित करते हैं errorक्षेत्र।

PKCE अकेले भ्रम को रोक नहीं सकता है, क्योंकि ग्राहक अपने code_verifierइस कारण से विनिर्देशों को निष्पादक को अनुरोध के अनुसार PKCE सत्यापितकर्ता के साथ रिकॉर्ड करता है औरstate. .

विफलता मोड

Stale JWKS.सत्यापनकर्ता एक कुंजी को घुमाए जाने के बाद मान्य टोकन को अस्वीकार करता है। फिक्स ऊपर cron-refresh + cache-miss-refetch पैटर्न है। कभी भी एक refresh कार्य के बिना JWKS को कैश न करें।
Rotate-as-fall-back.एक पुनर्प्राप्त करने के बजाय एक घुमावदार-और-मिंट के लिए कैश-मिस पथ को वायर करना एक असली बग हैः यह कभी भी गायब नहीं होता kid, और यह हमलावर नियंत्रित हो जाता है kidएक कुंजी-निर्माण DoS में मानों। गिरावट वापस करने के लिए idempotent होना चाहिए refresh-jwks. .
Missing aud claim.कुछ आईडीपी डिफ़ॉल्ट रूप से छोड़ने के लिए audजब तक कि resourceप्रमाणिकरणकर्ता को गायब टोकन को अस्वीकार करना होगा aud, अनुपस्थिति को वाइल्डकार्ड के रूप में नहीं मानें।
Mix-up via missing iss check.एक ग्राहक जो RFC 9207 को मान्य नहीं करता है issरिडायरेक्ट करने से पहले जारीकर्ता के खिलाफ प्राधिकरण-प्रतिसाद पैरामीटर को एक हमलावर के टोकन एंडपॉइंट पर एक ईमानदार एएस कोड को रिडिम करने के लिए निर्देशित किया जा सकता है। यह एक क्लाइंट-साइड विफलता है; संसाधन सर्वर इसके लिए मुआवजा नहीं दे सकता है।
Scope upgrade race.एक ही उपयोगकर्ता के लिए दो समवर्ती stepup flow दोनों सफल हो सकते हैं और अलग-अलग स्कोप वाले दो एक्सेस टोकन उत्पन्न कर सकते हैं। सत्यापनकर्ता को अनुरोध पर प्रस्तुत टोकन का उपयोग करना चाहिए, न कि "उपयोगकर्ता की वर्तमान स्कोप" को देखना चाहिए जो एक TOCTOU विंडो बनाता है।
Registration token theft.एक लीक registration_access_tokenहमलावर को पुनर्निर्देशित यूआरआई को फिर से लिखने देता है। उन्हें आराम में हैश करें; क्लाइंट को हर अपडेट पर स्पष्ट पाठ प्रस्तुत करने की आवश्यकता है; संदेह पर घूमना।
iss not pinned.किसी भी स्वीकार करने वाले सत्यापनकर्ताissहमलावर अपने स्वयं के प्राधिकरण सर्वर स्थापित करने, लक्षित दर्शकों के लिए एक क्लाइंट पंजीकृत करने और टोकन जारी करने देता है।authorization_serversसूची अनुमति सूची है; इसे लागू करें।
Credential or token cache collision.एक क्लाइंट जो केवल संसाधन द्वारा पंजीकरण कुंजी प्रस्तुत करता है एक प्राधिकरण सर्वर की पहचान दूसरे को प्रस्तुत कर सकता है। एक क्लाइंट जो केवल जारीकर्ता द्वारा एक्सेस टोकन कुंजी देता है, गलत दर्शकों पर एक टोकन को पुनः चला सकता है। सत्यापित जारीकर्ता द्वारा कुंजी पंजीकरण, द्वारा कुंजी एक्सेस टोकन।(issuer, resource), और जब भी जारीकर्ता बदलता है फिर से पंजीकृत करें।

इसका प्रयोग करें

code/main.pystdlib पायथन और तीन भूमिकाओं के साथ पूरी उत्पादन प्रवाह चलता हैः AuthorizationServer,ResourceServerऔर Client. प्रवाह:

भंडारण मूल से, चलाएंः

bashcd phases/13-tools-and-protocols/18-mcp-auth-production
python3 code/main.py
python3 -m unittest discover -s code/tests -v

पहला आदेश जारीकर्ता-बाध्य नामांकन और टोकन-मान्यीकरण प्रिंट करता है

दूसरे में 18 पास चेक की रिपोर्ट है. किसी भी कमांड में एक खोलने नहीं है

नेटवर्क श्रोता या क्रेडेंशियल लिखता है।

प्राधिकरण सर्वर RFC 8414 मेटाडेटा प्रकाशित करता है /.well-known/oauth-authorization-server. .
MCP क्लाइंट मेटाडेटा एंडपॉइंट को कॉल करता है और उसके नामांकन विकल्पों की जांच करता है (client_id_metadata_document_supportedसीआईएमडी के लिए, registration_endpointडीसीआर के लिए) और S256पीकेसीई समर्थन।
ग्राहक जारीकर्ता द्वारा स्कोप किए गए पूर्व-पंजीकरण की जांच करता है, अन्यथा अपने HTTPS क्लाइंट आईडी मेटाडेटा दस्तावेज़ के साथ पंजीकरण करता है। डिप्रेटेड डीसीआर एक अलग से परीक्षण योग्य संगतता विधि बनी हुई है।
ग्राहक सत्यापित जारीकर्ता को रिकॉर्ड करता है, एक S256 चुनौती बनाता है, एक बार के प्राधिकरण कोड और प्राप्त करता है iss, उस रिटर्न जारीकर्ता को मान्य करता है, और मूल सत्यापितकर्ता और आरएफसी 8707 के साथ कोड को रिडीम करता है resourceसंकेतक।
MCP क्लाइंट MCP सर्वर पर एक उपकरण को कॉल करता है Authorization: Bearer .... .
MCP सर्वर चलाता है validate, JWKS कैश से हस्ताक्षर कुंजी को हल करने.
आईडीपी एक कुंजी को घुमाता है; नियोजित ताज़ाकरण जेडब्ल्यूकेएस को कैश में वापस खींचता है।
अगला कॉल रिफ्रेश कुंजी के खिलाफ पुनः आरंभ किए बिना मान्य होता है, और पिछले टोकन अभी भी ओवरलैप विंडो के दौरान मान्य होता है।
एक अलग MCP संसाधन के खिलाफ दर्शकों को पुनः खेलने का प्रयास 401 के साथ मिलता हैaudience mismatchऔर एक resource_metadataसूचक।

JWT यहाँ साझा गुप्त के साथ HS256 का उपयोग करता है (इसलिए पाठ केवल stdlib पर चलता है) । उत्पादन ऊपर JWKS पैटर्न के साथ RS256 या EdDSA का उपयोग करता है; वैधता तर्क अन्यथा समान है। क्योंकि आईडीपी और संसाधन सर्वर एक प्रक्रिया में रहते हैं, refresh_jwksप्राधिकरण सर्वर की कुंजी सूची सीधे पढ़ता है; तार के माध्यम से यह एक HTTP है GETjwks_uri. .

इसे भेजें

यह सबक हमें फल देता हैoutputs/skill-mcp-auth.md. एक एमसीपी सर्वर कॉन्फ़िग और एक आईडीपी क्षमता सेट को देखते हुए, कौशल को खड़ा करने के लिए एथ सतह जारी करता है संरक्षित संसाधन मेटाडेटा, उपयोग करने के लिए नामांकन पथ (सीआईएमडी, पूर्व-पंजीकरण, या डीसीआर बैकअप), JWKS ताज़ा कार्यक्रम, दायरा मानचित्रण, और जब आईडीपी पूरी आरएफसी प्रोफ़ाइल का समर्थन नहीं करता है तो लागू करने के लिए अस्वीकार नियम।

व्यायाम

दौड़ेंcode/main.py. प्रवाह का पता लगाएं. ध्यान दें कि आईडीपी चरण 6 में एक कुंजी को कैसे घूमता है, अनुसूचित refresh_jwksप्रकाशित सेट को पुनः खींचता है, और पुराने टोकन (ओवरलैप विंडो) और एक नए टोकन दोनों को पुनः आरंभ किए बिना मान्य करता है।

संरक्षित संसाधन मेटाडेटा में एक नया आईडीपी जोड़ें authorization_serversसूची. नए आईडीपी द्वारा हस्ताक्षरित टोकन जारी करें और सत्यापनकर्ता द्वारा इसे स्वीकार की पुष्टि करें. एक अनलिस्टेड आईडीपी द्वारा हस्ताक्षरित टोकन जारी करें और सत्यापनकर्ता द्वारा अस्वीकार की पुष्टि करें।WWW-Authenticate: Bearer error="invalid_token", error_description="iss not allowed". .

में दर सीमा जाँच जोड़ेंregister_clientएक टोकन-बकेट प्रति स्रोत आईपी का उपयोग आईपी द्वारा कुंजीबद्ध एक छोटे से dict में रखा।

आरएफसी 7591 पढ़ें और दो क्षेत्रों की पहचान करें जो पाठ के लिए हैं /registerसंचालक सत्यापित नहीं करता है. सत्यापन जोड़ें. (संकेतः software_statementऔर redirect_urisयूआरआई योजना)

एक दूसरा प्राधिकरण सर्वर जोड़ें। पुष्टि करें कि ग्राहक अलग जारीकर्ता-की पंजीकरण संग्रहीत करता है और पहले जारीकर्ता के टोकन या फिर से उपयोग करने से इनकार करता है client_id. .

DoS फिक्स साबित करें. सत्यापनकर्ता एक टोकन के साथ भेजें एक यादृच्छिकkidऔर पुष्टि refresh_jwksएक बार पर चला जाता है और प्राधिकरण सर्वर की कुंजी संख्या नहीं बढ़ता है. फिर जानबूझकर एक घूर्णन-और-मिंट के लिए वापस तार और कुंजी संख्या के लिए झूठे टोकन के लिए चढ़ते हुए देखें बाद में पुनः प्राप्ति को बहाल.

दोनों के साथ डीसीआर का अभ्यास करनाnativeऔर webHTTP रीडायरेक्ट यूआरआई के साथ एक वेब क्लाइंट की पुष्टि करें और सटीक लूपबैक रीडायरेक्ट के बिना एक मूल क्लाइंट को अस्वीकार कर दिया जाता है।

प्रमुख शर्तें

Term	What people say	What it actually means
ASM	"OAuth metadata document"	RFC 8414 `/.well-known/oauth-authorization-server` JSON
CIMD	"Client metadata URL"	Client ID Metadata Document: an HTTPS URL used as the `client_id`; the AS pulls the JSON. Preferred enrollment in MCP 2026-07-28
DCR	"Self-service client registration"	RFC 7591 `POST /register`; deprecated for current MCP and retained only for compatibility
JWKS	"Public keys for JWT validation"	JSON Web Key Set, fetched from `jwks_uri`, indexed by `kid`
Rotate vs refresh	"Updating the keys"	Rotate = AS mints/retires signing keys; refresh = resource server re-fetches the published set. Resource servers only ever refresh
Resource indicator	"Audience parameter"	RFC 8707 `resource` parameter pinning the token to one server
`aud` claim	"Audience"	JWT claim the validator compares against the canonical resource URL
Audience replay	"Token replay"	Token issued for Server A presented to Server B; defended by audience validation (spec: access-token privilege restriction)
Confused deputy	"Proxy token misuse"	An MCP proxy with a static client ID forwarding a token without per-client consent; distinct from audience replay
Mix-up attack	"Wrong token endpoint"	Client steered to redeem an honest AS's code at an attacker's endpoint; defended client-side via RFC 9207 `iss`
`iss` allow-list	"Trusted authorization servers"	The set named in protected-resource metadata's `authorization_servers`
`resource_metadata`	"Where to find the PRM doc"	`WWW-Authenticate` parameter naming the RFC 9728 metadata URL on a 401/403
Public client	"Native or browser client"	OAuth client with no `client_secret`; PKCE compensates
`WWW-Authenticate`	"401/403 response header"	Carries `Bearer error=...` directives that drive client recovery

आगे पढ़ना

MCP authorization specification (2026-07-28)- वर्तमान एमसीपी प्राधिकरण प्रोफ़ाइल
MCP 2026-07-28 changelog- सीआईएमडी, जारीकर्ता सत्यापन, डीसीआर कटौती और जारीकर्ता कुंजी क्रेडिट परिवर्तन
OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document-00) सीआईएमडी
RFC 8414 — OAuth 2.0 Authorization Server Metadata खोज अनुबंध
RFC 7591 — OAuth 2.0 Dynamic Client Registration Protocol डीसीआर (फॉल बैक पथ)
RFC 7636 — Proof Key for Code Exchange (PKCE) सार्वजनिक-ग्राहक स्वामित्व प्रमाण
RFC 8707 — Resource Indicators for OAuth 2.0 दर्शकों की पिनिंग
RFC 9728 — OAuth 2.0 Protected Resource Metadata संसाधन सर्वर खोज
RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification issमिश्रण हमलों के खिलाफ रक्षा करने वाला पैरामीटर
RFC 7662: OAuth 2.0 Token Introspection
RFC 7009: OAuth 2.0 Token Revocation

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.