प्रश्न और परिदृश्य
एक इंटरव्यूअर आपके सामने IETF OAuth वर्किंग ग्रुप का ड्राफ्ट “OAuth 2.0 Attestation-Based Client Authentication” प्रस्तुत करता है और पूछता है कि एक क्लाइंट इंस्टेंस key-bound attestation कैसे ले जाता है, और फिर इसकी तुलना client_secret और mTLS से करता है। यह प्रश्न प्रोटोकॉल परिपक्वता, डिवाइस पहचान और डिप्लॉयमेंट से जुड़े निर्णय का परीक्षण करता है।
इंटरव्यूअर क्या जांच रहा है
- एक OAuth क्लाइंट, क्लाइंट इंस्टेंस, attestation जारीकर्ता (issuer) और Authorization Server को अलग-अलग समझना।
- ड्राफ्ट को अंतिम रूप से स्वीकृत मानक (finalized standard) कहे बिना key binding, audience, lifetime और replay सुरक्षा की व्याख्या करना।
- ट्रस्ट रूट्स, संचालन (operations) और फेलियर मोड्स के आधार पर साझा सीक्रेट्स, mTLS और attestations की तुलना करना।
उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
ड्राफ्ट का संस्करण स्पष्ट करें, क्या क्लाइंट एक मोबाइल ऐप है, हार्डवेयर डिवाइस है या सर्वर है, attestations कौन जारी करता है, और Authorization Server किन सत्यापन रूट्स पर भरोसा करता है। थ्रेट मॉडल को स्पष्ट करें: कॉपीड कीज़, संशोधित क्लाइंट्स, टोकन ट्रांसफर, या सामान्य कॉन्फिडेंशियल-क्लाइंट ऑथेंटिकेशन।
30-सेकंड का उत्तर फ्रेमवर्क
मैं बताऊंगा कि यह एक IETF OAuth Internet-Draft है और इसके फ़ील्ड्स लक्षित संस्करण पर निर्भर करते हैं। मूल विचार यह है कि एक क्लाइंट इंस्टेंस अपनी की (key) से बंधा (bound) एक attestation सबमिट करता है; Authorization Server OAuth ऑथेंटिकेशन स्वीकार करने से पहले चेन, audience, lifetime और की के पोज़ेशन (proof of key possession) के प्रमाण का सत्यापन करता है। यह एक साझा client_secret की तुलना में इंस्टेंस-स्तरीय ट्रस्ट को बेहतर ढंग से व्यक्त करता है, लेकिन इसमें issuer, रोटेशन, रिवोकेशन और गोपनीयता से जुड़े संचालन बढ़ जाते हैं। mTLS का ट्रस्ट पाथ अलग होता है और यह मौजूदा PKI वाले वातावरण के लिए उपयुक्त है।
चरण-दर-चरण विस्तृत उत्तर
- लॉजिकल क्लाइंट रजिस्ट्रेशन को क्लाइंट इंस्टेंस से अलग करें। इंस्टेंस एक की जनरेट करता है या रखता है, और attestation यह बताता है कि वह की इंस्टेंस के गुणों (properties) से कैसे संबंधित है।
- क्लाइंट OAuth ऑथेंटिकेशन अनुरोध के साथ attestation और key-binding सामग्री भेजता है। सर्वर हस्ताक्षरों, चेन, audience, समय सीमा (time window), nonce या अन्य replay सीमाओं, और अनुरोध प्राइवेट की के साथ किए जाने के प्रमाण का सत्यापन करता है।
- सत्यापन के बाद, Authorization Server सामान्य OAuth ऑथराइजेशन या टोकन जारी करने से पहले इंस्टेंस स्थिति, क्लाइंट ID, पॉलिसी और जोखिम संकेतों को जोड़ता है। एक attestation ऑथराइजेशन नहीं होता है।
- समाप्त हो चुके attestations, अविश्वसनीय issuers, की मिसमैच, nonce पुन: उपयोग और रिवोकेशन को ऐसे त्रुटि संदेशों से अलग करें जो कोई संवेदनशील विवरण प्रकट न करें।
- ट्रस्ट रूट्स, issuer रोटेशन, रिवोकेशन सूचियों, डिवाइस रिप्लेसमेंट और ऑफ़लाइन सत्यापन कैश का संचालन करें। संस्करणों और कारणों को रिकॉर्ड करें ताकि इनकार (denials) स्पष्टीकरण योग्य बने रहें।
- केवल पॉलिसी द्वारा आवश्यक इंस्टेंस प्रॉपर्टीज़ एकत्र करें। अनावश्यक रिसोर्स सर्वर्स के सामने स्थिर डिवाइस पहचानकर्ताओं को उजागर करने से बचें, और attestation सत्यापन को रिसोर्स ऑथराइजेशन से अलग रखें।
client_id = mobile-app
client_instance_key = K_instance
attestation = Sign_issuer(K_instance, audience=as.example, exp=t+300)
request_proof = Sign_K_instance(attestation, nonce, oauth_request_hash)उच्च-गुणवत्ता वाला नमूना उत्तर
मैं पहले ड्राफ्ट की स्थिति और संस्करण का उल्लेख करूंगा, फिर लॉजिकल क्लाइंट को इंस्टेंस से अलग करूंगा। इंस्टेंस एक की रखता है और उस की से बंधा हुआ किसी विश्वसनीय issuer का attestation सबमिट करता है। Authorization Server सिग्नेचर चेन, audience, lifetime, nonce और प्राइवेट-की पोज़ेशन का सत्यापन करता है, फिर परिणाम का उपयोग ऑथेंटिकेशन इनपुट के रूप में करता है। Attestation से स्कोप्स (scopes) नहीं मिलते हैं। client_secret की तुलना में, यह शेयर्ड-सीक्रेट कॉपी होने के जोखिम को कम करता है; mTLS की तुलना में, यह एप्लिकेशन इंस्टेंस के लिए फिट हो सकता है लेकिन इसके लिए issuer, रोटेशन, रिवोकेशन और प्राइवेसी ऑपरेशंस की आवश्यकता होती है। रोलआउट से पहले, मैं एक प्रयोगात्मक फ़ील्ड को स्थायी प्रोटोकॉल के रूप में हार्ड-कोड करने के बजाय रूट्स, एरर्स, रीप्ले कैश, रिप्लेसमेंट फ्लोज़ और ड्राफ्ट-वर्जन कम्पैटिबिलिटी का दस्तावेजीकरण करूंगा।
सामान्य गलतियाँ
- एक Internet-Draft को प्रकाशित RFC या इंटरऑपरेबल मानक कहना।
- यह मान लेना कि एक attestation स्वचालित रूप से ऑथराइजेशन या उच्चतर स्कोप प्रदान करता है।
- केवल issuer सिग्नेचर का सत्यापन करना, अनुरोध की पोज़ेशन, audience या nonce का नहीं।
- रिवोकेशन, डिवाइस रिप्लेसमेंट, क्लॉक स्क्यू और ऑफ़लाइन कैश को नज़रअंदाज़ करना।
- मिनिमाइज़ेशन या टेनेंट सीमाओं के बिना स्थिर डिवाइस पहचानकर्ताओं द्वारा उपयोगकर्ताओं को ट्रैक करना।
फॉलो-अप प्रश्न और उत्तर
client_secret से मुख्य अंतर क्या है?
client_secret आमतौर पर एक कॉपी करने योग्य साझा क्रेडेंशियल होता है और यह किसी विशिष्ट इंस्टेंस की पहचान नहीं कर सकता है। एक attestation इंस्टेंस की को एक issuer स्टेटमेंट से बांधता है, जिससे ट्रस्ट-रूट और लाइफसाइकिल प्रबंधन की लागत पर इंस्टेंस-स्तरीय निर्णय में सुधार होता है।
mTLS से मुख्य अंतर क्या है?
mTLS कनेक्शन लेयर पर क्लाइंट को साबित करने के लिए म्यूचुअल TLS और सर्टिफिकेट PKI का उपयोग करता है। Attestation एक OAuth ऑथेंटिकेशन इनपुट है जो विभिन्न issuer, सत्यापन और गोपनीयता मॉडलों के साथ विभिन्न ट्रांसपोर्ट पाथ्स पर काम कर सकता है।
आप attestation replay को कैसे रोकते हैं?
रिक्वेस्ट हैश, audience, कम लाइफ़टाइम और सर्वर nonce को बाइंड करें, उपयोग किए गए nonces या attestation पहचानकर्ताओं को कैश करें, और बाउंड प्राइवेट की के पोज़ेशन का सत्यापन करें।
आप बदलते हुए ड्राफ्ट को कैसे रोल आउट करते हैं?
ड्राफ्ट वर्शन, एल्गोरिदम और वेरिफ़ायर को स्पष्ट कॉन्फ़िगरेशन बनाएं। कम्पैटिबिलिटी वातावरण में कैनरी डिप्लॉयमेंट करें, पारंपरिक ऑथेंटिकेशन फ़ॉलबैक और मेट्रिक्स बनाए रखें, फिर आवश्यकताओं को धीरे-धीरे सख्त करें; कभी भी अधूरे फ़ील्ड्स को स्थायी प्रोटोकॉल के रूप में फ्रीज न करें।