Phase 13: Tools & Protocols

एमसीपी प्राधिकरणः सीआईएमडी, जारीकर्ता बंधन, पीकेसीई और स्टेप-अप

एक दूरस्थ MCP अनुरोध राज्यहीन है, लेकिन इसकी प्राधिकरण गुमनाम नहीं है. प्रत्येक क्रेडेंशियल को जारी करने वाले को जोड़ा गया है जिसने इसे बनाया और प्रत्येक टोकन को प्राप्त करने वाले संसाधन से।

Type: Build

Languages: Python

Prerequisites: Phase 13 · 09 (transports), Phase 13 · 15 (security)

Time: ~90 minutes

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

  • संरक्षित संसाधन मेटाडेटा के माध्यम से प्राधिकरण सर्वर का पता लगाएं।
  • पुराने डायनामिक क्लाइंट रजिस्ट्रेशन की तुलना में क्लाइंट आईडी मेटाडेटा दस्तावेजों को प्राथमिकता दें।
  • सही घोषित करें application_typeजब डीसीआर संगतता पथ अपरिहार्य हो।
  • अनुमतियों की प्रतिक्रिया को मान्य करें issऔर जारीकर्ता द्वारा क्रेडेंशियल को अलग करना।
  • PKCE, संसाधन संकेतकों, दर्शकों की सत्यापन और वृद्धिशील स्कोप का उपयोग करें।
  • प्रोटोकॉल सत्रों के बिना अधिकृत MCP 2026-07-28 अनुरोध भेजें।

समस्या

एक रिमोट MCP सर्वर निजी रिकॉर्ड पढ़ सकता है, बाहरी सिस्टम लिख सकता है, या महंगे काम को ट्रिगर कर सकता है। प्रमाणीकरण यह बताता है कि कौन एक क्रेडेंशियल प्रस्तुत किया है। प्राधिकरण को भी जवाब देना चाहिएः

  • कौन सा प्राधिकरण सर्वर ने प्रमाण पत्र जारी किया?
  • MCP संसाधन किसके लिए टोकन है?
  • किस क्लाइंट और रीडायरेक्ट यूआरआई ने प्रवाह पूरा किया?
  • उपयोगकर्ता ने किस ऑपरेशन को मंजूरी दी?
  • क्या यह अनुरोध अभी भी उस अनुमोदन के अनुरूप है?

2026-07-28 प्राधिकरण प्रोफ़ाइल ग्राहक पंजीकरण और जारीकर्ता प्रबंधन कठिन बनाता है। यह क्लाइंट आईडी मेटाडेटा दस्तावेजों को पसंद करता है, गतिशील क्लाइंट पंजीकरण को अप्रचलित करता है, अधिकार की आवश्यकता होती है application_typeडीसीआर पर, आरएफसी 9207 जारीकर्ता प्रतिक्रियाओं को मान्य करता है, और जारीकर्ताओं के बीच क्रेडेंशियल के पुनः उपयोग को प्रतिबंधित करता है।

ये नियम देशहीन मूल को पूरक करते हैं। वे एक मूल हाथ पकड़ने याMcp-Session-Id. .

अवधारणा

तीन भूमिकाओं को जानें

  • MCP client:संसाधन मालिक की ओर से अनुरोध भेजता है।
  • MCP resource server:एक्सेस टोकन को स्वीकार करता है और एमसीपी एंडपॉइंट की सेवा करता है।
  • Authorization server:संसाधन मालिक को प्रमाणित करता है, सहमति एकत्र करता है, और टोकन जारी करता है।

संसाधन सर्वर और प्राधिकरण सर्वर को एक साथ संचालित किया जा सकता है, लेकिन उनके पहचानकर्ताओं और सत्यापन जिम्मेदारियों को अलग रखें।

HTTP पर प्राधिकरण लागू होता है

MCP प्राधिकरण विनिर्देश HTTP आधारित परिवहन पर लागू होता है। एक स्थानीय स्टूडियो सर्वर प्रक्रिया और ऑपरेटिंग सिस्टम विश्वास सीमा के तहत चलता है। केवल सममितता के लिए स्टूडियो में एक नकली ब्राउज़र OAuth प्रवाह न जोड़ें।

दूरस्थ स्ट्रीम करने योग्य HTTP के लिए, में धारक टोकन भेजेंAuthorizationहर अनुरोध पर हेडर. कभी भी URL में डाल.

संरक्षित संसाधन मेटाडेटा से शुरू करें

संसाधन सर्वर RFC 9728 मेटाडेटा प्रकाशित करता हैः

json{
  "resource": "https:TOK0
  "authorization_servers": ["https://auth.example.com"],
  "scopes_supported": ["notes:delete", "notes:read", "notes:write"]
}

क्लाइंट MCP संसाधन URL से शुरू होता है, इस दस्तावेज़ को प्राप्त करता है, एक विज्ञापनित प्राधिकरण सर्वर का चयन करता है, और फिर उस सर्वर के OAuth या OpenID कनेक्ट मेटाडेटा प्राप्त करता है।

RFC 9728 के लिए प्रसिद्ध URL बनाने के दौरान संसाधन पथ को संरक्षित करें। संसाधन के लिए https://notes.example.com/mcp, इस पाठ का उपयोग करता है https://notes.example.com/.well-known/oauth-protected-resource/mcp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ./mcpप्रत्यय एक ही मूल पर एक अलग संरक्षित संसाधन के लिए मेटाडेटा का चयन कर सकता है।

किसी होस्टनाम से प्राधिकरण सर्वर का अनुमान न लगाएं. एक अप्रमाणित त्रुटि निकाय से खोजे गए जारीकर्ता का पालन न करें. एक नीति बनाए रखें जिसके लिए जारीकर्ता ग्राहक भरोसा करने को तैयार है।

प्राधिकरण सर्वर मेटाडेटा सत्यापित करें

मेटाडेटा में एंडपॉइंट्स और समर्थित नियंत्रणों को उजागर करना चाहिएः

json{
  "issuer": "https:TOK0
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https:TOK2
  "code_challenge_methods_supported": ["S256"],
  "authorization_response_iss_parameter_supported": true,
  "client_id_metadata_document_supported": true
}

PKCE के लिए S256 की आवश्यकता है। सटीक जारीकर्ता स्ट्रिंग रिकॉर्ड करें। यह सटीक मूल्य पंजीकरण और टोकन भंडारण के लिए कुंजी बन जाता है।

पंजीकरण प्राथमिकता का पालन करें

पूर्व-पंजीकृत ग्राहक जानकारी का उपयोग करें जब ग्राहक के पास पहले से ही चयनित जारीकर्ता के साथ स्पष्ट संबंध है। अन्यथा, प्राधिकरण सर्वर समर्थन का विज्ञापन करते समय क्लाइंट आईडी मेटाडेटा दस्तावेज़ों को प्राथमिकता दें। केवल डीसीआर का उपयोग करें अप्रचलित संगतता बैकअप के रूप में, फिर क्लाइंट जानकारी के लिए पूछें यदि इनमें से कोई भी तंत्र उपलब्ध नहीं है।

क्लाइंट आईडी मेटाडेटा दस्तावेजों को प्राथमिकता दें

एक क्लाइंट आईडी मेटाडेटा दस्तावेज़ प्राधिकरण सर्वर को एक HTTPS URL देता है जो क्लाइंट पहचानकर्ता और इसके मेटाडेटा का स्थान दोनों है:

json{
  "client_id": "https:TOK0
  "client_name": "Notes desktop client",
  "application_type": "native",
  "redirect_uris": ["http://127.0.0.1:8765/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"]
}

प्राधिकरण सर्वर दस्तावेज़ को प्राप्त करता है और उसे मान्य करता है।client_idएक पथ के साथ एक HTTPS URL होना चाहिए, और दस्तावेज़ के अंदर मूल्य उस URL के बराबर होना चाहिए। आवश्यक दस्तावेज़ फ़ील्ड client_id,client_nameऔर redirect_uris. .application_typeइस उदाहरण में दिखाई देता है लेकिन CIMD आवश्यकता नहीं है। इसका नया अनिवार्य उपयोग विशेष रूप से DCR पथ है।

दस्तावेज़ को प्राप्त करने के लिए SSRF-संवेदनशील ऑपरेशन के रूप में व्यवहार करें। गंतव्य को हल करें और सत्यापित करें, लूपबैक, निजी, लिंक-लोकल और अन्यथा अमान्य पते को अस्वीकार करें, पुनर्निर्देश और DNS परिवर्तनों के बाद फिर से जांचें, पुनर्निर्देश, बाइट और समय को सीमित करें, JSON की आवश्यकता है, और केवल सत्यापित HTTP कैश नियंत्रण के अनुसार।client_nameऔर अन्य प्रदर्शन फ़ील्ड अविश्वसनीय पाठ के रूप में।

सीआईएमडी हर पहले संपर्क के लिए एक नया गतिशील पहचानकर्ता बनाने की आवश्यकता को समाप्त करता है। यह यूआरआई सत्यापन, जारीकर्ता नीति या उपयोगकर्ता सहमति को पुनर्निर्देशित नहीं करता है।

डीसीआर एक संगतता पथ है

पुराने प्राधिकरण सर्वर के लिए डायनामिक क्लाइंट रजिस्ट्रेशन उपलब्ध है, लेकिन यह नए एमसीपी कार्यान्वयन के लिए अप्रचलित है।

DCR का प्रयोग करते समय, घोषित करें application_type:

json{
  "client_name": "Notes desktop client",
  "application_type": "native",
  "redirect_uris": ["http:TOK0
  "grant_types": ["authorization_code"],
  "response_types": ["code"]
}
  • डेस्कटॉप, मोबाइल, कमांड लाइन और लूपबैक क्लाइंट का उपयोग native. .
  • दूरस्थ रूप से होस्ट किए गए ब्राउज़र अनुप्रयोगों का उपयोग webऔर दूरस्थ HTTPS पुनर्निर्देशित.

फ़ील्ड को छोड़ना डिफ़ॉल्ट रूप से webएक OpenID कनेक्ट पंजीकरण कार्यान्वयन में और एक वैध लूपबैक रीडायरेक्ट विफलता है।

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

जारीकर्ता को बाध्यकारी क्रेडेंशियल

जारीकर्ता द्वारा मोंट की गई पंजीकरण सामग्री को सटीक जारीकर्ता के तहत स्टोर करेंः

textissuer_credentials[issuer] = pre_registered_or_dcr_client
tokens[(issuer, resource)] = access_token

यदि संरक्षित संसाधन की खोज में परिवर्तन होता हैhttps://auth-one.examplehttps://auth-two.exampleपहले जारीकर्ता के ग्राहक रहस्य, डीसीआर ग्राहक आईडी, पंजीकरण एक्सेस टोकन, रिफ्रेश टोकन या एक्सेस टोकन को कभी भी दूसरे को न भेजें। पूर्व-रजिस्टर और डीसीआर ग्राहकों को नए जारीकर्ता के लिए जारी किए गए क्रेडेंशियल का उपयोग करना चाहिए।

एक सीआईएमडी क्लाइंट आईडी अलग है क्योंकि यह एक स्व-होस्ट किया गया एचटीटीपीएस यूआरएल है, प्राधिकरण सर्वर द्वारा minted एक क्रेडेंशियल नहीं है। वही सीआईएमडी यूआरएल पोर्टेबल हैः एक नया विश्वसनीय जारीकर्ता डीसीआर पुनः पंजीकरण के बिना दस्तावेज़ को प्राप्त करता है और सत्यापित करता है। प्राधिकरण प्रतिक्रिया और टोकन अभी भी नए जारीकर्ता के तहत सत्यापित और संग्रहीत किए जाते हैं।

PKCE के साथ प्राधिकरण कोड

इंटरैक्टिव प्रवाह हैः

  1. उच्च-एंट्रोपी उत्पन्न करें code_verifier. .
  2. S256 से व्युत्पन्न करें code_challenge. .
  3. अनुमोदन अनुरोध को सटीक रूप से भेजें client_id,redirect_uri,scope,code_challengeऔर resource. .
  4. अनुमतियों के प्रति उत्तर प्राप्त करें जिसमें codeऔर, जब प्रदान किया जाए, iss. .
  5. वैधताissकिसी भी प्रतिक्रिया क्षेत्र का उपयोग करने से पहले सटीक दर्ज किए गए जारीकर्ता के खिलाफ।
  6. कोड का आदान-प्रदान करें code_verifier, वही पुनर्निर्देशन URI, और वही resource. .
  7. प्राप्त टोकन को नीचे रखें (issuer, resource). .

resourceRFC 8707 से पैरामीटर प्राधिकरण और टोकन अनुरोध दोनों में दिखाई देता है। यह कैनोनिकल MCP सर्वर यूआरआई की पहचान करता है।

वैधताissठीक है

आरएफसी 9207 एक जारीकर्ता से अनुमति प्रतिक्रिया को दूसरे से प्रतिक्रिया के साथ भ्रमित करने से रोकता है।

कबissयदि कोई त्रुटि है, तो इसे रिकॉर्ड किए गए जारीकर्ता के साथ तुलना करें, बिना मामले के तह, ट्रेलिंग स्लैश परिवर्तन, डिफ़ॉल्ट पोर्ट हटाने, या प्रतिशत एन्कोडिंग सामान्यीकरण के। असंगतता पर, कोड पर कार्रवाई न करें या उस प्रतिक्रिया से हमलावर-नियंत्रित त्रुटि विवरण भी प्रदर्शित न करें।

एक प्राधिकरण सर्वर जिसमें शामिल है issविज्ञापन authorization_response_iss_parameter_supported: trueवर्तमान ग्राहक अभी भी एक उपहार को मान्य करते हैं issभले ही वह विज्ञापन गायब हो।

MCP सर्वर पर दर्शकों को मान्य करें

संसाधन सर्वर केवल अपने लिए जारी किए गए टोकन स्वीकार करता हैः

texttoken.issuer == configured_authorization_server
token.audience == canonical_mcp_resource

अमान्य, समाप्त, गलत जारीकर्ता या गलत दर्शकों के टोकन प्राप्त करते हैं। एमसीपी सर्वर को किसी अन्य सेवा के लिए एक टोकन को स्वीकार या ट्रांसमिट नहीं करना चाहिए।

न्यूनतम वर्तमान दायरा की मांग करें

अब आवश्यक दायरे से शुरू करें. यदि बाद के उपकरण में अधिक की आवश्यकता होती है, तो सर्वर एक प्रामाणिक दायरा चुनौती के साथ 403 लौटाता हैः

textWWW-Authenticate: Bearer error="insufficient_scope",
  scope="notes:delete",
  resource_metadata="https://notes.example.com/.well-known/oauth-protected-resource/mcp"

क्लाइंट नई अनुमति की व्याख्या करता है, सहमति प्राप्त करता है, संयुक्त दायरा सेट के साथ एक नया प्राधिकरण प्रवाह करता है, और एक नए JSON-RPC आईडी के साथ MCP अनुरोध को पुनः प्रयास करता है।

यह मत मानो कि चुनौती दी गई सीमा का एक उपसमूह है scopes_supported. वर्तमान अभियान के लिए चुनौती प्रामाणिक है.

प्राधिकरण और राज्यहीन एमसीपी तार

एक अधिकृत उपकरण कॉल अभी भी वर्तमान अनुरोध के पूरा लिफाफा है:

textPOST /mcp
Authorization: Bearer <access-token>
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: notes.delete
json{
  "jsonrpc": "2.0",
  "id": 12,
  "method": "tools/call",
  "params": {
    "name": "notes.delete",
    "arguments": {"id": "note-7"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": {
        "name": "oauth-lesson-client",
        "version": "1.0.0"
      }
    }
  }
}

टोकन मुख्य को अधिकृत करता है। अनुरोध मेटाडेटा प्रोटोकॉल व्यवहार पर बातचीत करता है। कोई भी दूसरे के लिए प्रतिस्थापन नहीं करता है।

एक निश्चित क्रम में तार को मान्य करेंः JSON-RPC और मेटाडेटा प्रकार, हेडर और बॉडी समानता, फिर प्रोटोकॉल समर्थन। एक रूटिंग या संस्करण-हेडर असंगतता HTTP 400 को के साथ लौटा देती है-32020. यदि हेडर और बॉडी असमर्थित संस्करण पर सहमत हैं, तो HTTP 400 को के साथ लौटाएं-32022और dataठीक है{"supported":["2026-07-28"],"requested":"<actual>"}. एक अज्ञात विधि HTTP 404 को वापस करती है -32601. .

401 अमान्य टोकन और 403 अपर्याप्त दायरा सहित प्रत्येक अनुरोध त्रुटि, मूल अनुरोध के साथ एक JSON-RPC त्रुटि कूपन है id. संरचित पुनर्प्राप्ति सूचना वैकल्पिक त्रुटि में शामिल है dataWWW-Authenticateएक सूचना में कोई idएक स्वीकृत HTTP अधिसूचना रिक्त शरीर के साथ 202 लौटता है।

सर्वर द्वारा लागू किया जाता है server/discoverऔर उपकरण विज्ञापन, तो यह भी अनिवार्य लागू करता है tools/listविधि. इसके उपकरण वर्णकों में स्थिर नाम, विवरण और वस्तु जड़ है inputSchemaमानों की सूची निर्धारक है और रिटर्न resultType, सर्वर पहचान मेटाडेटा, एक सीमित ttlMsऔर cacheScope. डिस्कवरी और उपयोगकर्ता से स्वतंत्र उपकरण सूची प्राधिकरण से पहले उपलब्ध हो सकती है. सामान्य नीति और निजी कैशिंग लागू करें यदि इनमें से कोई भी मूल के अनुसार भिन्न होता है।

कोई प्रतीकात्मक पास नहीं

एक MCP सर्वर को क्लाइंट के MCP एक्सेस टोकन को डाउनस्ट्रीम एपीआई को अग्रेषित नहीं करना चाहिए। सही दर्शकों के साथ एक अलग डाउनस्ट्रीम टोकन प्राप्त करें या स्पष्ट टोकन-बिक्री डिजाइन का उपयोग करें। दर्शकों की सत्यापन केवल तभी काम करती है जब सेवाएं किसी और के लिए minted टोकन को अस्वीकार करती हैं।

ताज़ा टोकन

रिफ्रेश टोकन वैकल्पिक हैं। जारी किए जाने पर, उन्हें गोपनीय रूप से स्टोर करें और जारीकर्ता और संसाधन द्वारा उन्हें कुंजीबद्ध करें। यह मत मानो कि वे मौजूद हैं। उन्हें रोटेट करें जब प्राधिकरण सर्वर रोटेशन का समर्थन करता है और अमान्य मानों के पुनः उपयोग का पता लगाएं।

इसे बनाओ

code/main.pyयह एक प्रोसेस प्रोटोकॉल और प्राधिकरण सिम्युलेटर है। यह संरक्षित संसाधन खोज, प्राधिकरण सर्वर मेटाडेटा, सीआईएमडी नामांकन, संस्करण-गेटेड डीसीआर बैकअप, एप्लिकेशन प्रकार की जांच, पीकेसीई, जारीकर्ता सत्यापन, संसाधन-बाउंड टोकन, दायरे में वृद्धि,server/discover,tools/list, और एक देशहीन उपकरण अनुरोध.

मॉडल को विश्लेषण अनुरोध निकायों और रूटिंग हेडर प्राप्त होता है। यह एक पूर्ण HTTP एडाप्टर नहीं है और विश्लेषण नहीं करता है Content-Typeया Accept. इसे पाठ 09 के स्ट्रीम करने योग्य HTTP एडाप्टर से कनेक्ट करें, जिसके लिए आवश्यकता होती है Content-Type: application/jsonऔर एक Acceptदोनों को युक्त मूल्य application/jsonऔर text/event-stream. .

इसे चलाओः

bashcd phases/13-tools-and-protocols/16-mcp-security-oauth-2-1
python3 code/main.py
python3 -m unittest discover code/tests -v

आउटपुट में पहले डिस्कवरी, सीआईएमडी नामांकन, एक साधारण रीडिंग, दो अलग-अलग स्कोप स्टेप-अप और जारीकर्ता कुंजी क्रेडिट कार्ड भंडारण दिखाया गया है।

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

सिमुलेटर वस्तुओं को उत्पादन घटकों के लिए नक्शाः

  • ResourceServer.protected_resource_metadataRFC 9728 के अंत बिंदु बन जाता है।
  • AuthorizationServer.metadataRFC 8414 या OpenID Connect खोज बन जाता है।
  • Client.enrollCIMD संकल्प प्लस एक स्पष्ट DCR संगतता शाखा बन जाता है।
  • जारीकर्ता द्वारा बनाए गए ग्राहक क्रेडेंशियल और tokens_by_issuer_resourceएक CIMD URL पोर्टेबल रह सकता है जबकि इसके प्राधिकरण परिणाम जारीकर्ता के लिए बाध्य रहते हैं।
  • ResourceServer.handleयह मध्यवेयर बन जाता है जो वर्तमान MCP हेडर, टोकन और टूल स्कोप को डिस्पैच करने से पहले मान्य करता है जबकि प्रत्येक अनुरोध त्रुटि को एक मेल खाने वाले JSON-RPC लिफाफे में रखता है।

इसे भेजें

यह सबक जहाजों outputs/skill-oauth-scope-planner.md. अब इसमें नामांकन प्राथमिकता, जारीकर्ता-बाध्य प्रमाणपत्र भंडारण, आवेदन प्रकार, PKCE, संसाधन संकेतकों, दायरा चुनौतियों और वर्तमान राज्यहीन अनुरोध सीमा को डिजाइन किया गया है।

व्यायाम

  1. रिफ्रेश टोकन रोटेशन जोड़ें और पिछले रिफ्रेश टोकन के पुनः उपयोग को अस्वीकार करें।
  2. जारीकर्ता अनुमतियों की सूची जोड़ें. जारीकर्ता परिवर्तन पर, केवल एक पोर्टेबल CIMD URL का पुनः उपयोग करें; सभी पूर्व जारीकर्ता द्वारा minted क्रेडेंशियल और टोकन अस्वीकार करें।
  3. प्राधिकरण कोडों में एक समाप्ति जोड़ें और देरी से विनिमय विफलता की पुष्टि करें।
  4. एक दूरस्थ HTTPS रीडायरेक्ट के साथ एक वेब क्लाइंट संस्करण बनाएं और मूल क्लाइंट के साथ इसके डीसीआर मेटाडेटा की तुलना करें।
  5. उसी जारीकर्ता के तहत एक दूसरा संसाधन जोड़ें. इसकी पहुंच टोकन का उपयोग पहले संसाधन पर नहीं किया जा सकता है की पुष्टि करें.

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

TermMeaning
Protected-resource metadataRFC 9728 document that identifies the resource and authorization servers
CIMDHTTPS metadata document whose URL is the OAuth client identifier
DCRDeprecated dynamic client enrollment retained for compatibility
application_typenative or web, used to validate redirect URI rules
PKCEVerifier and S256 challenge that protect an intercepted authorization code
issRFC 9207 authorization response issuer identifier
Resource indicatorRFC 8707 parameter that binds a token request to an MCP resource
AudienceResource for which a token is valid
Step-upNew consent and token issuance for an additional current-operation scope
Issuer-bound credentialsRegistration and token records isolated by exact authorization server issuer

आगे पढ़ना

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.