प्रॉम्प्ट और लागू संदर्भ
आप एक OAuth 2.0 ऑथराइजेशन सर्वर के मालिक हैं। मोबाइल और एंटरप्राइज वेब क्लाइंट बारीक स्कोप, रिसोर्स इंडिकेटर्स और भुगतान संदर्भ ले जाते हैं, लेकिन टीम ब्राउज़र URL में पूरा अनुरोध नहीं रखना चाहती है। एक Pushed Authorization Request (PAR) एंडपॉइंट डिज़ाइन करें। क्लाइंट प्रमाणीकरण, request_uri जेनरेशन और बाइंडिंग, समाप्ति, एकल-उपयोग (one-time use), रीप्ले, रीडायरेक्ट-URI सत्यापन, PKCE, त्रुटियां, दर सीमाएं (rate limits), और रोलबैक को कवर करें।
यह बैकएंड, आइडेंटिटी-प्लेटफ़ॉर्म और पेमेंट्स इंटरव्यू के लिए उपयुक्त है। RFC 9126 PAR को क्लाइंट से ऑथराइजेशन सर्वर पर सीधे पुश के रूप में परिभाषित करता है जो बाद के ब्राउज़र ऑथराइजेशन अनुरोध के लिए request_uri लौटाता है। एक मजबूत उत्तर यह भी बताता है कि PAR ऑथराइजेशन सर्वर द्वारा बाद के अनुरोध को सत्यापित करने की आवश्यकता को समाप्त नहीं करता है।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्लाइंट, PAR एंडपॉइंट, ब्राउज़र ऑथराइजेशन एंडपॉइंट और टोकन एंडपॉइंट के बीच सीमा तय करना।
- क्लाइंट प्रमाणीकरण, उपयोगकर्ता प्रमाणीकरण, अनुरोध अखंडता और टोकन बाइंडिंग को अलग करना।
request_uriअनुमान लगाने, बदलने (swapping), रीप्ले, समाप्ति और रीडायरेक्ट-URI हमलों को संभालना।- PKCE, state, nonce, JAR और PAR को सही परतों पर रखना।
- TTL, इडेम्पोटेंसी, दर सीमाएं, ऑडिट और कैनरी रोलआउट को चालू और परिचालन योग्य बनाना।
RFC 9700 वर्तमान OAuth 2.0 सुरक्षा सर्वोत्तम प्रथाओं का सारांश प्रस्तुत करता है। Amazon की SDE II तैयारी सामग्री सिस्टम डिज़ाइन में विश्वसनीयता, सटीकता, दक्षता, स्केलेबिलिटी और सुरक्षा पर जोर देती है। इंटरव्यू का मुख्य संकेत उन मानकों को चालू सर्विस सीमाओं में बदलना है।
स्पष्टीकरण के लिए प्रश्न
- क्या क्लाइंट कॉन्फिडेंशियल है या पब्लिक? क्या कोई मोबाइल क्लाइंट क्लाइंट सीक्रेट की सुरक्षा कर सकता है, या उसे PKCE और प्लेटफ़ॉर्म बाइंडिंग का उपयोग करना चाहिए?
- अनुरोध में क्या संवेदनशील डेटा है? क्या हस्ताक्षरित (signed) या एन्क्रिप्टेड JAR की आवश्यकता है, और PAR के समय किन फ़ील्ड्स की जाँच की जानी चाहिए?
request_uriलाइफटाइम, रीफ्रेश अनुमति, प्रति-क्लाइंट समवर्तीता (concurrency) और वैश्विक दर-सीमा लक्ष्य क्या हैं?- क्या रीडायरेक्ट URIs निश्चित और पूर्व-पंजीकृत हैं, या किसी एंटरप्राइज टेनेंट को डायनामिक पंजीकरण की आवश्यकता है?
- क्या प्रत्येक क्लाइंट को PAR के माध्यम से ऑथराइजेशन पैरामीटर भेजने होंगे? लेगेसी क्लाइंट कैसे माइग्रेट करेंगे?
- क्या ब्राउज़र रीफ्रेश, बैक नेविगेशन, रद्दीकरण और नेटवर्क पुनः प्रयास को उसी अनुरोध को दोबारा पढ़ने की अनुमति होनी चाहिए?
30-सेकंड उत्तर ढांचा
क्लाइंट PAR को एक HTTPS POST भेजता है, प्रमाणित करता है, और रीडायरेक्ट URI, स्कोप, रिसोर्स और PKCE पैरामीटर को सत्यापित करता है। सर्वर एक उच्च-एन्ट्रापी, अल्पकालिक, क्लाइंट-बाउंड request_uri बनाता है और JSON लौटाता है। ब्राउज़र फिर ऑथराइजेशन एंडपॉइंट पर केवल client_id और request_uri भेजता है। वह एंडपॉइंट संदर्भ का उपभोग करने से पहले अनुरोध, state/nonce, उपयोगकर्ता सहमति और PKCE को फिर से सत्यापित करता है। दर सीमाएं, ऑडिट, एकल-उपयोग नीति, अनुकूलता फ़्लैग और कैनरी मेट्रिक्स रोलआउट को नियंत्रित करते हैं।
चरण-दर-चरण विस्तृत उत्तर
1. टू-हॉप प्रोटोकॉल को परिभाषित करें
पहला हॉप क्लाइंट से PAR तक एक application/x-www-form-urlencoded बॉडी के साथ एक सीधा HTTPS POST है। यह क्लाइंट को प्रमाणित करने और client_id, प्रतिक्रिया प्रकार (response type), रीडायरेक्ट URI, स्कोप, रिसोर्स इंडिकेटर्स, state, nonce और PKCE को मान्य करने का स्थान है। RFC 9126 PAR के लिए HTTPS की आवश्यकता रखता है और ऑथराइजेशन-एंडपॉइंट एक्सटेंशन की अनुमति देता है।
दूसरा हॉप ऑथराइजेशन एंडपॉइंट के लिए उपयोगकर्ता एजेंट का अनुरोध है, जिसमें आम तौर पर केवल client_id और request_uri होते हैं। ऑथराइजेशन सर्वर ब्राउज़र द्वारा फिर से सबमिट किए गए संवेदनशील पैरामीटर पर भरोसा करने के बजाय पहले हॉप में सहेजे गए अनुरोध को पुनः प्राप्त करता है। यह क्वेरी-स्ट्रिंग लीकेज, URL-आकार सीमाएं और उपयोगकर्ता-एजेंट छेड़छाड़ को कम करता है।
2. request_uri स्टोरेज डिज़ाइन करें
request_uri को क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक मान के साथ जनरेट करें, कभी भी बढ़ते हुए ID या अनुमान लगाने योग्य व्यावसायिक कुंजी का उपयोग न करें। पूरा अनुरोध, क्लाइंट ID, निर्माण समय, समाप्ति, उपभोग स्थिति और हैश किए गए ऑडिट फ़ील्ड संग्रहीत करें; संदर्भ को उस क्लाइंट से बांधें जिसने इसे बनाया है।
TTL को छोटा रखें और इसे expires_in के रूप में लौटाएं। एक समाप्त संदर्भ invalid_request लौटाता है; किसी अज्ञात संदर्भ से यह प्रकट नहीं होना चाहिए कि क्या वह कभी अस्तित्व में था। एकल-उपयोग उपभोग सबसे सुरक्षित है। यदि उत्पाद को रीफ्रेश का समर्थन करना चाहिए, तो रीड काउंट, state/nonce बाइंडिंग और एक सख्त सीमा के साथ एक छोटी विंडो की अनुमति दें।
3. क्लाइंट और अनुरोध को सत्यापित करें
टोकन-एंडपॉइंट नियमों का उपयोग करके PAR पर क्लाइंट को प्रमाणित करें, जैसे कि mTLS या private_key_jwt। प्रमाणीकरण यह साबित करता है कि किस क्लाइंट ने अनुरोध सबमिट किया है; यह यह साबित नहीं करता है कि किसी उपयोगकर्ता ने साइन इन किया है या किसी स्कोप के लिए सहमति दी है। PAR पर पंजीकृत रीडायरेक्ट URIs, अनुमत स्कोप, संसाधनों और प्रतिक्रिया प्रकार को मान्य करें, फिर उन जांचों को दोहराएं जिनके लिए ऑथराइजेशन के समय उपयोगकर्ता संदर्भ की आवश्यकता होती है।
यदि क्लाइंट हस्ताक्षरित Request Object का उपयोग करता है, तो JAR नियमों के तहत इसके हस्ताक्षर, जारीकर्ता (issuer), ऑडियंस, समाप्ति और महत्वपूर्ण फ़ील्ड्स को मान्य करें। PAR सीधा पुश और संदर्भ जीवनचक्र है; JAR Request Object हस्ताक्षर या एन्क्रिप्शन है। वे एक साथ काम कर सकते हैं, लेकिन कोई भी एक दूसरे की जगह नहीं लेता है।
4. PKCE, state और nonce को सही परत पर रखें
PAR अभी भी code_challenge और उसकी विधि ले जाता है; कोड को भुनाते समय टोकन एंडपॉइंट को code_verifier को सत्यापित करना होगा। state क्लाइंट सत्र को बांधता है और CSRF को कम करता है। OIDC nonce प्रमाणीकरण अनुरोध को ID टोकन से बांधता है। request_uri की उपस्थिति इन नियंत्रणों को हटाने या उन्हें विनिमेय (interchangeable) मानने का कोई कारण नहीं है।
5. स्वैपिंग, रीप्ले और ओपन रीडायरेक्ट को रोकें
यदि कोई हमलावर किसी अनुरोध को अपने द्वारा प्राप्त किए गए अनुरोध से बदल देता है, तो स्कोप या आश्वासन स्तर बदल सकता है। संदर्भ को क्लाइंट से बांधें और ऑथराइजेशन अनुरोध के क्लाइंट संदर्भ के मिलान की आवश्यकता रखें। क्लाइंट एक अद्वितीय state और PKCE का उपयोग करता है; OIDC nonce का उपयोग करता है। रीडायरेक्ट URIs का सख्ती से मिलान करें ताकि PAR एक ओपन-रीडायरेक्ट प्रवेश बिंदु न बन सके।
उपभोग किए जा चुके संदर्भ का पुन: उपयोग होने पर एक स्पष्ट लेकिन गैर-गणना योग्य (non-enumerating) त्रुटि लौटाएं। अनुमान लगाने और रीप्ले का पता लगाने के लिए क्लाइंट, संदर्भ हैश, समय, जोखिम संकेत और परिणाम लॉग करें। सामान्य एक्सेस लॉग से संपूर्ण ऑथराइजेशन अनुरोधों, क्लाइंट दावों और संवेदनशील रिसोर्स पैरामीटर को बाहर रखें।
6. त्रुटियां, सीमाएं और उपलब्धता डिज़ाइन करें
अमान्य पैरामीटर, बेमेल रीडायरेक्ट URI, या खराब हस्ताक्षर invalid_request जैसी OAuth त्रुटियों का उपयोग करते हैं। एक गलत विधि 405 हो सकती है, एक बड़ा अनुरोध 413, और कोटा उल्लंघन 429 हो सकता है। क्लाइंट, टेनेंट, IP और वैश्विक स्टोरेज द्वारा सीमाएं लागू करें ताकि कोई हमलावर PAR स्टोरेज को समाप्त न कर सके।
जब PAR अनुपलब्ध हो, तो क्या माइग्रेट किए गए क्लाइंट नियमित ऑथराइजेशन अनुरोध पर वापस आ सकते हैं (fall back), यह एक सुरक्षा नीति निर्णय है। भुगतान या उच्च जोखिम वाले स्कोप के लिए, फ़्लो को चुपचाप कमजोर करने के बजाय स्पष्ट रूप से विफल करें। मेटाडेटा के माध्यम से लेगेसी क्लाइंट्स को माइग्रेट करें, फिर धीरे-धीरे require_pushed_authorization_requests लागू करें।
7. डेटा लाइफटाइम और ऑब्जर्वेबिलिटी का संचालन करें
संदर्भ डेटा केवल उसके TTL, उपभोग और आवश्यक ऑडिट अवधि के लिए बनाए रखें। एन्क्रिप्टेड स्टोरेज, एक्सेस कंट्रोल और मिनिमाइज़ेशन का उपयोग करें; संवेदनशील ऑथराइजेशन संदर्भ को कई कैश में कॉपी न करें। PAR सफलता, सत्यापन विफलता, समाप्ति, डुप्लिकेट उपभोग, 429 दर, ऑथराइजेशन पर गायब-संदर्भ दर और टोकन एक्सचेंज पर PKCE विफलताओं को ट्रैक करें।
नियमित और PAR फ़्लो को एक साथ कैनरी करें। पूर्णता दर, पहले पृष्ठ की लेटेंसी, मोबाइल फ़ॉलबैक और सुरक्षा अलर्ट की तुलना करें। स्वचालित परीक्षणों में समवर्ती उपभोग, संदर्भ स्वैपिंग, रीडायरेक्ट-URI वेरिएंट, ब्राउज़र रीफ्रेश, बड़े आकार के अनुरोध और लेगेसी-क्लाइंट अनुकूलता शामिल होनी चाहिए।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं फ़्लो को दो हॉप्स में विभाजित करूँगा। क्लाइंट HTTPS पर PAR को कॉल करता है, प्रमाणित करता है, और रीडायरेक्ट URI, स्कोप, रिसोर्स, प्रतिक्रिया प्रकार, PKCE, state और nonce को मान्य करता है। सर्वर एक उच्च-एन्ट्रापी, अल्पकालिक, क्लाइंट-बाउंड request_uri बनाता है और केवल संदर्भ और expires_in लौटाता है। ब्राउज़र फिर क्लाइंट ID और संदर्भ के साथ ऑथराइजेशन एंडपॉइंट को कॉल करता है; सर्वर मूल अनुरोध प्राप्त करता है और ऑथराइजेशन, उपयोगकर्ता-सत्र, state/nonce और PKCE जांच फिर से करता है।
संदर्भ डिफ़ॉल्ट रूप से एकल-उपयोग के साथ अनुरोध, क्लाइंट बाइंडिंग, समाप्ति और उपभोग स्थिति को संग्रहीत करता है। एक रीफ्रेश सुविधा एक छोटी विंडो, रीड सीमा और ऑडिट का उपयोग करती है। JAR Request Object हस्ताक्षर या एन्क्रिप्शन को संभालता है; PAR सीधे पुश और संदर्भ जीवनकाल को संभालता है। सख्त रीडायरेक्ट-URI मिलान स्वैपिंग और ओपन रीडायरेक्ट को रोकता है, जबकि OAuth त्रुटियां और प्रति-क्लाइंट, IP और टेनेंट सीमाएं दुरुपयोग को दृश्यमान बनाती हैं।
मैं पुराने फ़्लो को बनाए रखते हुए क्लाइंट मेटाडेटा द्वारा कैनरी करूँगा, पूर्णता, लेटेंसी, समाप्ति, डुप्लिकेट उपयोग, 429s और PKCE विफलताओं को मापूँगा। उच्च जोखिम वाले क्लाइंट चुपचाप फ़ॉलबैक नहीं करते हैं। स्टोरेज आउटेज या रीप्ले स्पाइक रोलआउट को रोक देता है और प्रवर्तन फ़्लैग को उलट देता है। यह OAuth के उपयोगकर्ता-सहमति और कोड-एक्सचेंज सीमाओं को बदले बिना URL लीकेज और पैरामीटर छेड़छाड़ को कम करता है।
सामान्य गलतियाँ
- क्लाइंट प्रमाणीकरण, संदर्भ बाइंडिंग या समाप्ति के बिना केवल "पैरामीटर को POST में रखें" कहना।
request_uriको एक एक्सेस टोकन के रूप में मानना या इसे एक अनुमान लगाने योग्य डेटाबेस ID बनाना।- यह मान लेना कि PAR स्वचालित रूप से रीप्ले को रोकता है और एकल-उपयोग, TTL, state, nonce या PKCE को छोड़ देना।
- प्रत्येक सुरक्षा सीमा की व्याख्या किए बिना PAR, JAR और PKCE को मिला देना।
- केवल PAR पर रीडायरेक्ट URI को मान्य करना और ऑथराइजेशन के समय ब्राउज़र पैरामीटर पर भरोसा करना।
- 413, 429, समवर्ती उपभोग, कैश लीकेज और संवेदनशील लॉग को अनदेखा करना।
- PAR विफल होने पर बिना शर्त नियमित ऑथराइजेशन पर वापस आ जाना, जिससे उच्च जोखिम वाले स्कोप का जोखिम बढ़ जाता है।
फॉलो-अप प्रश्न और उत्तर
request_uri को कितने समय तक जीवित रहना चाहिए?
जोखिम के आधार पर एक छोटे TTL का उपयोग करें और expires_in लौटाएं। समाप्ति या उपभोग के बाद इसे हटाएं या अमान्य करें; ऑडिट के लिए केवल न्यूनतम हैश, क्लाइंट और परिणाम फ़ील्ड बनाए रखें।
क्या कोई ब्राउज़र रीफ्रेश संदर्भ का पुन: उपयोग कर सकता है?
डिफ़ॉल्ट रूप से एकल-उपयोग रखें। यदि रीफ्रेश की आवश्यकता है, तो डुप्लिकेट रीड्स की निगरानी करते हुए एक छोटी विंडो, एक रीड सीमा और state, nonce और क्लाइंट-सत्र बाइंडिंग का उपयोग करें। असीमित पुन: उपयोग की अनुमति न दें।
क्लाइंट प्रमाणीकरण के बाद भी PKCE की आवश्यकता क्यों है?
क्लाइंट प्रमाणीकरण उस क्लाइंट की पहचान करता है जिसने अनुरोध सबमिट किया था। PKCE कोड रिडेम्पशन को उस अनुरोधकर्ता से बांधता है जिसके पास सत्यापनकर्ता (verifier) होता है। यदि कोई ऑथराइजेशन कोड इंटरसेप्ट किया जाता है तो यह सार्वजनिक और मोबाइल क्लाइंट्स के लिए महत्वपूर्ण बना रहता है।
क्या PAR JAR की जगह ले सकता है?
नहीं। PAR सीधे पुश, ब्राउज़र-पैरामीटर छिपाने और संदर्भ जीवनकाल को संबोधित करता है। JAR Request Object हस्ताक्षर या एन्क्रिप्शन को संबोधित करता है। जब मजबूत अखंडता या गैर-अस्वीकृति (non-repudiation) की आवश्यकता हो तो उन्हें संयोजित करें।
लेगेसी क्लाइंट्स को कैसे माइग्रेट करना चाहिए?
ऑथराइजेशन-सर्वर मेटाडेटा और क्लाइंट नीति द्वारा PAR को सक्षम करें, समर्थन का निरीक्षण करें, फिर चयनित क्लाइंट्स के लिए require_pushed_authorization_requests लागू करें। पूरे पारिस्थितिकी तंत्र को आंख मूंदकर स्विच करने के बजाय एक सीमित, ऑडिट किए गए लेगेसी पथ को बनाए रखें।
यदि PAR एंडपॉइंट पर भारी ट्रैफ़िक (flood) आ जाए तो क्या होगा?
क्लाइंट, टेनेंट, IP और वैश्विक संसाधनों द्वारा सीमित करें; बॉडी साइज़ और स्टोरेज TTL को सीमित करें; 429 लौटाएं; और विफलता दर तथा स्टोरेज वॉटरमार्क की निगरानी करें। ट्रैफ़िक दबाव के कारण उच्च जोखिम वाले क्लाइंट्स को चुपचाप डाउनग्रेड नहीं होना चाहिए।