सिस्टम डिज़ाइन इंटरव्यू: आप एक Request-Bound Delegated-Authority Verifier को कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

किसी व्यक्ति या संगठन की ओर से पैसे खर्च करने, मीटर्ड संसाधनों का उपभोग करने, विनियमित डेटा का खुलासा करने या प्रोडक्शन स्टेट में बदलाव करने वाले एजेंट, वर्कलोड या बैच जॉब के लिए एक प्रत्यायोजित-अधिकार सत्यापन लेयर डिज़ाइन करें। सिस्टम को संरक्षित अनुरोध को प्रोसेस करने से पहले सीमित अधिकार साबित करना होगा। यह प्रॉम्प्ट 2026 के एक IETF HTTPAPI Internet-Draft को संदर्भित करता है; यह अभी भी प्रगति पर है (work in progress), कोई अंतिम RFC नहीं है, और यह कोई भुगतान प्रोटोकॉल नहीं है।

साक्षात्कारकर्ता क्या परख रहा है

• पहचान प्रमाणीकरण (identity authentication), प्रत्यायोजित प्राधिकरण (delegated authorization), अनुरोध अखंडता (request integrity), और सेटलमेंट को अलग करना।
• 401 चुनौतियां (challenges), 403 अस्वीकृतियां (denials), nonces, समाप्ति (expiry), और अनुरोध बाइंडिंग को डिज़ाइन करना।
• रीप्ले (replay), क्रॉस-टेनेंट पुन: उपयोग, प्रॉक्सी, कुंजी रोटेशन (key rotation), और ऑडिटेबिलिटी को संभालना।
• उच्च-प्रभाव वाली क्रियाओं से पहले बजट, नीति, और फेल-क्लोज्ड सीमाओं को लागू करना।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

1. क्या संरक्षित क्रिया डेटा निर्यात, प्रोडक्शन राइट, डाउनस्ट्रीम कॉल, या बजटीय उपभोग है?
2. प्रिंसिपल, जारीकर्ता (issuer), प्रत्यायोजित अनुरोधकर्ता (delegated requester), और सत्यापनकर्ता (verifier) का संचालन कौन करता है?
3. क्या अधिकार को HTTP मेथड, टारगेट URI, अनुरोध डाइजेस्ट, या केवल एक संसाधन दायरे (resource scope) से बंधा होना चाहिए?
4. क्या ऑफ़लाइन सत्यापन की अनुमति है, और nonce उपलब्धता और क्लॉक स्क्यू (clock skew) को कैसे संभाला जाता है?
5. क्या विफलता पर अनुरोध अस्वीकार कर दिया जाना चाहिए, मानव स्वीकृति की आवश्यकता होनी चाहिए, या केवल-पढ़ने (read-only) के लिए डाउनग्रेड किया जाना चाहिए?

30-सेकंड का उत्तर ढांचा

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

चरण-दर-चरण गहन विश्लेषण

1. भूमिकाएं और विश्वास सीमाएं परिभाषित करें

प्रिंसिपल कोई व्यक्ति, संगठन या सेवा है। प्रत्यायोजित अनुरोधकर्ता एक एजेंट, डिवाइस, जॉब या वर्कलोड है। जारीकर्ता प्रिंसिपल के लिए एक प्रमाण पर हस्ताक्षर करता है, और सत्यापनकर्ता संरक्षित संसाधन या गेटवे पर स्थित होता है। प्रमाण प्राप्त करने के लिए OAuth Token Exchange या किसी अन्य जारीकर्ता प्रणाली का उपयोग किया जा सकता है; सत्यापनकर्ता चुनौती और प्रस्तुति को संभालता है, सहमति या खाता लिंकिंग को नहीं।

2. चुनौती और प्रतिक्रिया डिज़ाइन करें

बिना किसी स्वीकार्य प्रमाण के, 401, WWW-Authenticate: Delegation, और Cache-Control: no-store लौटाएं। जब प्रमाण सिंटैक्स के रूप में मान्य हो लेकिन स्थानीय नीति से अधिक हो तो 403 लौटाएं। Problem Details विफलता की व्याख्या कर सकते हैं, लेकिन व्याख्यात्मक फ़ील्ड्स को चुनौती को शिथिल नहीं करना चाहिए।

HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: Delegation realm="api.example",
  version=1, profile="budget", nonce="n-123", max-age=300

सत्यापनकर्ता nonce, प्रोफ़ाइल और समाप्ति विंडो को नियंत्रित करता है ताकि किसी प्रमाण को अनुरोधों के बीच कॉपी न किया जा सके।

3. प्रमाण को भविष्य के अनुरोध से बांधें

कम से कम HTTP मेथड, विश्वसनीय ऑरिजिन, टारगेट URI, अनुरोध डाइजेस्ट और समाप्ति को बांधें। यदि कोई प्रॉक्सी Host या पाथ को फिर से लिखता है (rewrites), तो ऑरिजिन को केवल विश्वसनीय गेटवे कॉन्फ़िगरेशन से ही पुनर्निर्मित करें; कभी भी असत्यापित X-Forwarded-* पर भरोसा न करें। मेथड केस, क्वेरी ऑर्डरिंग और प्रतिशत एन्कोडिंग के लिए कैनोनिकलाइज़ेशन को परिभाषित करें।

{
  "principal": "org-42",
  "requester": "job-7",
  "method": "POST",
  "origin": "https://api.example",
  "target_hash": "sha-256:...",
  "nonce": "n-123",
  "expires": "2026-08-04T05:00:00Z",
  "limits": {"USD": 250}
}

4. सत्यापन क्रम और फेल-क्लोज्ड व्यवहार सेट करें

संस्करण और प्रारूप को पार्स करें, फिर हस्ताक्षर, जारीकर्ता विश्वास, nonce ताजगी, समय विंडो, अनुरोध बाइंडिंग और स्थानीय बजट को सत्यापित करें। जब कोई निर्भरता अनुपलब्ध हो, CBOR गैर-नियतात्मक (non-deterministic) हो, कोई हस्ताक्षर विफल हो जाए, या nonce स्थिति खो जाए तो अस्वीकार करें। पहचान क्रेडेंशियल्स और डेलिगेशन प्रमाणों को अलग-अलग परतों के रूप में सत्यापित करें; एक वैध प्रमाण को किसी असंबद्ध API की को अधिकृत नहीं करना चाहिए।

5. रीप्ले और क्रॉस-टेनेंट पुन: उपयोग को रोकें

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

6. बजट और नीति लागू करें

बजट एक प्राधिकरण प्रोफ़ाइल है, भुगतान या निपटान नहीं। नीति राशि, सेवा इकाइयों, डेटा दायरे, पर्यावरण और डाउनस्ट्रीम कॉल को सीमित कर सकती है। क्रिया के समान लेन-देन सीमा में डेबिट करें, या एक क्षतिपूर्ति आरक्षण (compensating reservation) का उपयोग करें, ताकि समवर्ती (concurrent) अनुरोध संयुक्त रूप से सीमा से अधिक न हो सकें।

7. कुंजियों का संचालन और सुरक्षित रूप से ऑडिट करें

जारीकर्ता रोटेट करने योग्य कुंजियां और संस्करण प्रकाशित करते हैं। सत्यापनकर्ता उन्हें कैश कर सकते हैं लेकिन उन्हें निरस्तीकरण (revocation) और आपातकालीन रोटेशन का समर्थन करना चाहिए। प्रिंसिपल, अनुरोधकर्ता, टारगेट, पॉलिसी परिणाम, प्रमाण आईडी और अस्वीकृति के कारण का ऑडिट करें; कभी भी पूरे टोकन, निजी कुंजियां या संवेदनशील डेटा लॉग न करें। 401/403 दरें, nonce रीप्ले, सत्यापन विलंबता, नीति अस्वीकृतियां, बजट अधिकता, कुंजी-रोटेशन विफलताएं और अनुमोदन समय को ट्रैक करें।

उच्च गुणवत्ता वाला नमूना उत्तर

मैं सिस्टम को पहचान, डेलिगेशन, रिक्वेस्ट बाइंडिंग और पॉलिसी लेयर्स में विभाजित करूंगा। OAuth या कोई अन्य जारीकर्ता प्रिंसिपल संबंध को साबित करता है। डेलिगेशन प्रमाण में प्रिंसिपल, अनुरोधकर्ता, प्रोफ़ाइल, समाप्ति और बजट शामिल होता है; सत्यापनकर्ता इसे निष्पादित किए जाने वाले HTTP मेथड, विश्वसनीय ऑरिजिन, टारगेट URI, अनुरोध डाइजेस्ट और nonce से बांधता है।

प्रमाण गायब होने पर WWW-Authenticate: Delegation और no-store के साथ 401 लौटाएं; जब यह मान्य हो लेकिन अपर्याप्त हो तो 403 लौटाएं। प्रारूप, हस्ताक्षर और जारीकर्ता विश्वास, nonce ताजगी, समय विंडो, अनुरोध बाइंडिंग, टेनेंट नीति और बजट को उसी क्रम में सत्यापित करें। कोई भी हस्ताक्षर विफलता, अनुपलब्ध निर्भरता या खोई हुई nonce स्थिति फेल-क्लोज्ड होती है। यह प्रमाण भुगतान को परिभाषित नहीं करता है, HTTP Message Signatures को प्रतिस्थापित नहीं करता है, या OAuth जारी करने या सहमति को लागू नहीं करता है।

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

सामान्य गलतियाँ

• डेलिगेशन प्रमाण को सामान्य पहचान, OAuth जारी करने या भुगतान प्रोटोकॉल के रूप में मानना।
• मेथड, URI, डाइजेस्ट, nonce, या समाप्ति बाइंडिंग के बिना एक लंबे समय तक चलने वाला टोकन जारी करना।
• हस्ताक्षर निर्भरताएं अनुपलब्ध होने पर अनुरोधों की अनुमति देना।
• टारगेट के लिए प्रॉक्सी द्वारा फिर से लिखे गए या अविश्वसनीय X-Forwarded-* मानों पर भरोसा करना।
• पूरे क्रेडेंशियल्स को लॉग करना या कार्रवाई के बाद डेबिट करना, जिससे रीप्ले और ओवरस्पेंड विंडो खुली रह जाती हैं।

फॉलो-अप प्रश्न और उत्तर

401 और 403 दोनों का उपयोग क्यों करें?

401 का अर्थ है कि प्रमाण गायब है, अमान्य है, या अधूरा है, इसलिए एक क्लाइंट चुनौती से एक नया प्रमाण प्राप्त कर सकता है। 403 का अर्थ है कि प्रमाण समझ में आ गया था लेकिन अधिकार, बजट या स्थानीय नीति अपर्याप्त है; इसे पुन: प्रयास करने से कोई मदद नहीं मिलती है।

यदि nonce सेवा अस्थायी रूप से अनुपलब्ध हो तो क्या होगा?

उच्च-जोखिम वाले अनुरोधों के लिए फेल-क्लोज्ड करें और एक नैदानिक no-store त्रुटि लौटाएं। केवल स्पष्ट रूप से मूल्यांकित कम-जोखिम वाली केवल-पढ़ने की क्रियाओं में ही एक सीमित फ़ॉलबैक हो सकता है; कैश किया गया पुराना nonce कोई वन-टाइम स्थिति नहीं है।

यह OAuth के साथ कैसे काम करता है?

OAuth Token Exchange या GNAP डेलिगेशन सामग्री प्राप्त कर सकते हैं। सत्यापनकर्ता अभी भी अनुरोध-बाध्य प्रमाण की स्वतंत्र रूप से जांच करता है। पहचान टोकन और डेलिगेशन प्रमाण को अलग-अलग सत्यापित करें ताकि प्रत्यायोजित दायरे को सभी पहचान-टोकन अनुमतियों के रूप में न समझा जाए।

क्या यह एक भुगतान प्रोटोकॉल है?

नहीं। एक बजट प्रोफ़ाइल राशि या सेवा-इकाई सीमाओं को व्यक्त कर सकती है, जबकि सेटलमेंट, भुगतान रेल और HTTP 402 सिमेंटिक्स बाहरी हैं। सत्यापनकर्ता केवल यह तय करता है कि क्या संरक्षित क्रिया डेलिगेशन नीति को संतुष्ट करती है।