प्रॉम्प्ट और दायरा
आप मोबाइल और ब्राउज़र क्लाइंट्स द्वारा उपयोग किए जाने वाले एक OAuth API के ओनर हैं। रिसोर्स सर्वर वर्तमान में केवल Bearer एक्सेस टोकन को वैलिडेट करता है; एक लॉग लीक होने से अटैकर टोकन के वैलिड रहने के दौरान रिक्वेस्ट्स को रीप्ले कर सकता है। ऑथराइजेशन सर्वर, क्लाइंट, रिसोर्स सर्वर और DPoP अनुपलब्ध होने पर व्यवहार सहित एक DPoP (Demonstrating Proof-of-Possession) स्कीम डिज़ाइन करें।
यह बैकएंड सिक्योरिटी आर्किटेक्चर का प्रश्न है, किसी वेंडर-कॉन्फ़िगरेशन का क्विज़ नहीं। RFC 9449 एक एक्सेस टोकन को क्लाइंट की पब्लिक-की से बाइंड करता है और प्रत्येक कॉल में HTTP मेथड और URI से बाउंड एक प्रूफ़ ले जाने की आवश्यकता रखता है। RFC 9700 वर्तमान OAuth सुरक्षा मार्गदर्शन जोड़ता है, जैसे कि कमज़ोर फ़्लो से बचना और PKCE का उपयोग करना।
इंटरव्यूअर क्या टेस्ट कर रहा है
एक मजबूत उत्तर Bearer-टोकन फ़ेलियर मोड से शुरू होता है: जिस किसी के पास वह स्ट्रिंग है, वह इसका उपयोग कर सकता है, इसलिए चोरी हुआ टोकन एक लेजिटिमेट रिक्वेस्ट से अप्रभेद्य होता है। इसके बाद यह एक एंड-टू-एंड फ़्लो देता है: क्लाइंट एक की बनाता है, टोकन एंडपॉइंट DPoP प्रूफ़ को वेरीफ़ाई करता है और पब्लिक-की को बाइंड करता है, और रिसोर्स सर्वर सिग्नेचर, मेथड, URI, टोकन हैश और टाइम विंडो की जाँच करता है।
इंटरव्यूअर jti रीप्ले, सर्वर नॉनसेस, खोई हुई कीज़, प्रॉक्सी द्वारा URI रीराइटिंग, रिफ़्रेश टोकन, पुराने क्लाइंट्स और टेलीमेट्री के लिए भी एक योजना की अपेक्षा करता है। केवल "JWT पर साइन करें" कहना अपर्याप्त है: एक सामान्य JWT सिग्नेचर जारीकर्ता की अखंडता साबित करता है, यह नहीं कि कॉलर के पास अभी भी वह प्राइवेट-की है जो जारी करते समय उपयोग की गई थी।
पहले स्पष्ट करने योग्य प्रश्न
क्लाइंट और थ्रेट मॉडल
पुष्टि करें कि क्या क्लाइंट एक ब्राउज़र SPA, नेटिव मोबाइल ऐप या सर्वर एप्लिकेशन है। क्या प्राइवेट-की हार्डवेयर-समर्थित स्टोरेज में रह सकती है और क्या प्रत्येक इंस्टॉलेशन को अपनी स्वयं की की मिलती है, यह लाइफ़साइकिल को बदल देता है। पूछें कि क्या अटैकर लॉग्स, प्रॉक्सी, ब्राउज़र स्टोरेज या डिवाइस फ़ाइलों को पढ़ सकता है, और क्या वे वास्तविक समय में रिक्वेस्ट्स को इंटरसेप्ट कर सकते हैं।
रिसोर्स-सर्वर बाउंड्री
गेटवे, TLS टर्मिनेशन और इंटरनल फ़ॉरवर्डिंग की पुष्टि करें। DPoP htu को रिसोर्स सर्वर द्वारा वेरीफ़ाई किए गए URI सेमेंटिक्स से मेल खाना चाहिए। यदि कोई गेटवे पाथ्स को रीराइट करता है, तो कैनोनिकलाइजेशन और ट्रस्टेड फ़ॉरवर्डिंग हेडर परिभाषित करें; क्लाइंट को एक एड्रेस पर साइन करने और बैकएंड द्वारा दूसरे को वेरीफ़ाई करने की अनुमति न दें।
उपलब्धता और माइग्रेशन की बाधाएं
पूछें कि क्या लेगेसी Bearer क्लाइंट्स का काम करना जारी रखना आवश्यक है, क्या एक छोटी दोहरी-स्टैक (dual-stack) अवधि स्वीकार्य है, और क्या लॉगिन और रिफ़्रेश एक ही ऑथराइजेशन सर्वर का उपयोग करते हैं। यदि विनियमन या कोई हाई-वैल्यू API सख्त सेंडर-कंस्ट्रेंट की मांग करता है, तो DPoP को अनिवार्य बनाएं। कम जोखिम वाले रिसोर्सेज के लिए, कैपेबिलिटी नेगोशिएशन और नपे-तुले रोलआउट के माध्यम से माइग्रेट करें।
30-सेकंड का उत्तर फ़्रेमवर्क
"मैं DPoP को तीन-पक्षीय प्रोटोकॉल के रूप में डिज़ाइन करूँगा। क्लाइंट प्रति इंस्टॉलेशन एक की-पेयर जनरेट करता है और टोकन रिक्वेस्ट के दौरान एक बार उपयोग होने वाला DPoP प्रूफ़ भेजता है। ऑथराइजेशन सर्वर इसे वेरीफ़ाई करता है और एक्सेस टोकन के cnf.jkt को पब्लिक-की से बाइंड करता है। प्रत्येक API कॉल एक नया DPoP JWT ले जाती है; रिसोर्स सर्वर इसके सिग्नेचर, htm, htu, iat, यूनिक jti, ath और टोकन के cnf.jkt की जाँच करता है, जिसमें रीप्ले को कम करने के लिए एक नॉनस और छोटी टाइम विंडो होती है। प्राइवेट-की खो जाने पर बाउंड टोकन रिवोक हो जाते हैं। लेगेसी क्लाइंट्स को केवल स्पष्ट रूप से कम जोखिम वाले रिसोर्सेज के लिए समय-सीमित Bearer पाथ मिलता है, जबकि हाई-वैल्यू ऑपरेशन्स अनिवार्य DPoP पर चले जाते हैं।"
चरण-दर-चरण समाधान
चरण 1: की बनाएं और ऑथराइजेशन बाइंड करें
पहली बार चलने पर, क्लाइंट एक असममित (asymmetric) की-पेयर बनाता है और प्राइवेट-की को सुरक्षित डिवाइस स्टोरेज में रखता है। टोकन का अनुरोध करते समय यह DPoP प्रूफ़ द्वारा ले जाए जाने वाले JWK में पब्लिक-की भेजता है। ऑथराइजेशन सर्वर प्रूफ़ के सिग्नेचर, टाइप और टाइम को वैलिडेट करता है, फिर टोकन के कन्फ़र्मेशन डेटा को पब्लिक-की के JWK थंबप्रिंट से बाइंड करता है। ऑथराइजेशन-कोड फ़्लो के साथ, अभी भी RFC 9700 के PKCE मार्गदर्शन का उपयोग करें: DPoP टोकन पज़ेशन को साबित करता है और कोड सुरक्षा की जगह नहीं लेता है।
चरण 2: प्रति रिक्वेस्ट एक प्रूफ़ जनरेट करें
प्रत्येक रिक्वेस्ट के लिए, क्लाइंट एक नया JWT बनाता है जिसमें कम से कम jti, htm, htu और iat शामिल होते हैं, फिर बाउंड प्राइवेट-की के साथ इस पर साइन करता है। यह एक्सेस टोकन का एक हैश ath में डालता है, जिससे रिसोर्स सर्वर को यह वेरीफ़ाई करने की अनुमति मिलती है कि प्रूफ़ उसी की द्वारा हस्ताक्षरित किसी अन्य टोकन के बजाय इस टोकन को टारगेट करता है। प्रूफ़ DPoP हेडर में जाता है, और एक्सेस टोकन Bearer के बजाय DPoP ऑथराइजेशन स्कीम का उपयोग करता है।
चरण 3: एक निश्चित क्रम में वेरीफ़ाई करें
रिसोर्स सर्वर पहले एल्गोरिदम और JWK प्रकारों को प्रतिबंधित करता है, फिर JWT सिग्नेचर, की-फ़ॉर्मेट, टाइम विंडो, मेथड और URI को वेरीफ़ाई करता है। यह एक्सेस टोकन को हैश करता है और परिणाम की तुलना ath से करता है; यह टोकन से cnf.jkt को पढ़ता है और प्रूफ़ की-थंबप्रिंट से इसकी तुलना करता है। फिर यह सामान्य स्कोप, ऑडियंस और रिसोर्स ऑथराइजेशन लागू करने से पहले जाँचता है कि क्या वर्तमान विंडो में jti दिखाई दिया है।
चरण 4: नॉनसेस और रीप्ले को संभालें
सर्वर हाई-रिस्क रिसोर्सेज के लिए एक नॉनस जारी कर सकता है, जिसके लिए क्लाइंट को इसे अगले प्रूफ़ में शामिल करने की आवश्यकता होती है। स्वीकृति विंडो के भीतर jti डिडप्लीकेशन की आवश्यकता होती है। एक सिंगल-नोड कैश छोटे डिप्लॉयमेंट के लिए काम करता है; मल्टी-इंसटेंस रिसोर्स सर्वरों को एक एक्सपायरिंग शेयर्ड कैश की आवश्यकता होती है, या उन्हें स्पष्ट रूप से एक छोटी-विंडो डुप्लिकेट जोखिम को स्वीकार करना चाहिए और इसे सुरक्षा घटना के रूप में रिकॉर्ड करना चाहिए। रिजेक्शन टेलीमेट्री को की-मटीरियल को उजागर किए बिना एक्सपायरी, खराब सिग्नेचर, थंबप्रिंट मिसमैच और मिसिंग नॉनस में अंतर करना चाहिए।
चरण 5: रोटेशन, निरसन (Revocation) और फ़ॉलबैक डिज़ाइन करें
यदि कोई डिवाइस खो जाता है, कोई प्राइवेट-की उजागर हो जाती है, या सर्वर दुरुपयोग का पता लगाता है, तो उस थंबप्रिंट से जुड़े एक्सेस और रिफ़्रेश टोकन को रिवोक करें और फिर से ऑथराइजेशन की आवश्यकता रखें। रोटेशन केवल क्लाइंट-ओनली रिप्लेसमेंट नहीं हो सकता: नई पब्लिक-की को एक नए ऑथराइजेशन बाइंडिंग की आवश्यकता होती है। माइग्रेशन के दौरान, एक रिसोर्स सर्वर दोनों स्कीम्स को स्वीकार कर सकता है, लेकिन हाई-वैल्यू राइट्स के पास एक अलग अनिवार्य-DPoP पॉलिसी होनी चाहिए ताकि कम्पैटिबिलिटी कभी भी सुरक्षा डिफ़ॉल्ट न बने।
चरण 6: प्लेन Bearer के साथ mTLS की तुलना करें
mTLS प्रूफ़ को TLS क्लाइंट-सर्टिफ़िकेट लेयर पर रखता है और परिपक्व सर्टिफ़िकेट संचालन वाले सर्वर-टू-सर्वर सिस्टम के लिए उपयुक्त है। DPoP एप्लिकेशन लेयर पर काम करता है और मोबाइल तथा ब्राउज़र क्लाइंट्स के लिए उपयुक्त है, लेकिन यह प्रूफ़, नॉनस, jti और की-स्टोरेज संचालन को जोड़ता है। प्लेन Bearer को डिप्लॉय करना सबसे आसान है लेकिन टोकन स्ट्रिंग कॉपी होने के बाद यह रीप्ले का विरोध नहीं कर सकता। प्रत्येक एंडपॉइंट के लिए आँख बंद करके DPoP सक्षम करने के बजाय क्लाइंट क्षमताओं, प्रॉक्सी टोपोलॉजी, अनुपालन (compliance) और परिचालन लागत के आधार पर चयन करें।
उच्च-गुणवत्ता वाला नमूना उत्तर
मैं थ्रेट मॉडल से शुरुआत करूँगा: एक लॉग, प्रॉक्सी, या क्लाइंट-स्टोरेज लीक एक एक्सेस टोकन को उजागर कर सकता है, जिसके बाद एक हमलावर इसकी वैधता अवधि के दौरान API को कॉल कर सकता है। छोटी एक्सपायरी विंडो को संकीर्ण करती है लेकिन यह साबित नहीं करती कि कॉलर मूल क्लाइंट है।
क्लाइंट प्रति इंस्टॉलेशन एक की-पेयर बनाता है और प्राइवेट-की की सुरक्षा करता है। ऑथराइजेशन-कोड एक्सचेंज के दौरान मुझे PKCE और DPoP प्रूफ़ की आवश्यकता होती है; ऑथराइजेशन सर्वर प्रूफ़ को वेरीफ़ाई करता है और टोकन के cnf.jkt को पब्लिक-की से बाइंड करता है। रिसोर्स सर्वर पर, मैं प्रूफ़ सिग्नेचर, htm, htu, iat, jti, ath और नॉनस को एक निश्चित क्रम में वेरीफ़ाई करता हूँ, फिर प्रूफ़ की-थंबप्रिंट की तुलना टोकन बाइंडिंग से करता हूँ। कोई भी मिसमैच अनऑथराइज्ड होता है और सुरक्षा मेट्रिक्स में वर्गीकृत किया जाता है।
मैं मल्टी-इंसटेंस डिप्लॉयमेंट्स के लिए TTL-समर्थित शेयर्ड डिडप्लीकेशन कैश में jti मानों को स्टोर करता हूँ। हाई-रिस्क राइट्स के लिए नॉनस और DPoP की आवश्यकता होती है। माइग्रेशन के दौरान, कम जोखिम वाले रीड्स डुअल-स्टैक हो सकते हैं, लेकिन समय सीमा क्लाइंट वर्ज़न और रिसोर्स रिस्क से जुड़ी होती है। एक खोई हुई की अपने टोकन को रिवोक करती है और एक नया ऑथराइजेशन शुरू करती है; एक Bearer फ़ॉलबैक कभी भी हाई-वैल्यू राइट पाथ साझा नहीं करता है। अंत में, मैं जाली प्रूफ़, पुराने jti रीप्ले, URI परिवर्तन, गलत टोकन हैश, एक्सपायर्ड नॉनसेस और प्रॉक्सी रीराइट्स के लिए इंटीग्रेशन टेस्ट चलाता हूँ, फिर यह साबित करने के लिए रिजेक्शन रेट, नॉनस रिट्राइज़ और असामान्य थंबप्रिंट्स की निगरानी करता हूँ कि रीप्ले को ब्लॉक किया जा रहा है।
सामान्य गलतियाँ
- गलती: केवल एक्सेस टोकन को JWT के रूप में साइन करना। → यह क्यों विफल होता है: सिग्नेचर जारीकर्ता की अखंडता साबित करता है लेकिन क्लाइंट प्राइवेट-की के पज़ेशन को नहीं। → समाधान:
cnf.jktको बाइंड करें और प्रत्येक रिक्वेस्ट पर एक नए DPoP प्रूफ़ को वेरीफ़ाई करें। - गलती: एक ही DPoP प्रूफ़ का पुन: उपयोग करना। → यह क्यों विफल होता है: एक हमलावर पूरी रिक्वेस्ट को रीप्ले कर सकता है क्योंकि
jtiऔर टाइम चेक इसमें अंतर नहीं कर सकते हैं। → समाधान: प्रति रिक्वेस्ट एक नयाjtiजनरेट करें और स्वीकृति विंडो के भीतर इसे डिडुप्लिकेट करें, आवश्यकता पड़ने पर एक नॉनस जोड़ें। - गलती: केवल गेटवे पर DPoP को वेरीफ़ाई करना जबकि आंतरिक सेवाएँ एक अनबाउंड यूज़र हेडर पर भरोसा करती हैं। → यह क्यों विफल होता है: फ़ॉरवर्डिंग से मेथड, URI या टोकन बाइंडिंग का नुकसान हो सकता है और एक जाली पहचान आगे जा सकती है। → समाधान: एक ट्रस्टेड बाउंड्री के पार एक नॉर्मलाइज़्ड वेरिफिकेशन रिज़ल्ट पास करें और इसे कौन सेट कर सकता है इसे प्रतिबंधित करें।
- गलती: प्रत्येक वैलिडेशन त्रुटि पर Bearer पर फ़ॉलबैक करना। → यह क्यों विफल होता है: एक हमलावर सबसे कमज़ोर पाथ तक पहुँचने के लिए जानबूझकर DPoP त्रुटियों को ट्रिगर कर सकता है। → समाधान: केवल रजिस्टर्ड लेगेसी क्लाइंट्स और कम जोखिम वाले रिसोर्सेज के लिए समय-सीमित फ़ॉलबैक की अनुमति दें।
फ़ॉलो-अप प्रश्न और उत्तर
फ़ॉलो-अप 1: आप क्षेत्रों (regions) में jti को कैसे डिडुप्लिकेट करते हैं?
रिसोर्स जोखिम द्वारा कंसिस्टेंसी का चयन करें। हाई-वैल्यू राइट्स एक क्रॉस-रीजन शेयर्ड स्टोर का उपयोग कर सकते हैं और एक अतिरिक्त राउंड ट्रिप का भुगतान कर सकते हैं; कम जोखिम वाले रीड्स रीजनल कैश और एक छोटी विंडो का उपयोग कर सकते हैं, जिससे उपलब्धता का त्याग किए बिना डुप्लिकेट्स रिकॉर्ड किए जा सकते हैं। किसी भी डिज़ाइन में, विंडो, विफलता व्यवहार और डुप्लिकेट दर को SLO में लिखें।
फ़ॉलो-अप 2: क्या होगा यदि XSS ब्राउज़र की प्राइवेट-की पढ़ ले?
DPoP पूरी तरह से नियंत्रित क्लाइंट एक्ज़ीक्यूशन एनवायरनमेंट की मरम्मत नहीं कर सकता है। नॉन-एक्सपोर्टेबल कीज़, एक सख्त कंटेंट-सिक्योरिटी पॉलिसी, शॉर्ट-लिव्ड टोकन और रिफ़्रेश रोटेशन को प्राथमिकता दें; जब थंबप्रिंट असामान्य व्यवहार करे तो बाइंडिंग को रिवोक करें। सुरक्षा सीमा को स्पष्ट रूप से बताएं: DPoP कॉपी किए गए टोकन को लक्षित करता है जब प्राइवेट-की कॉपी नहीं की गई थी, न कि एंडपॉइंट टेकओवर के हर रूप को।
फ़ॉलो-अप 3: एक प्रॉक्सी URI को बदल देता है। आप htu को कैसे वेरीफ़ाई करते हैं?
एक्सटर्नल कैनोनिकल URI से इंटरनल रूट के लिए एक मैपिंग परिभाषित करें, और केवल एक ट्रस्टेड प्रॉक्सी को ऑथेंटिकेटेड मूल स्कीम, होस्ट और पाथ प्रदान करने की अनुमति दें। रिसोर्स सर्वर तुलना से पहले वही कैनोनिकलाइजेशन लागू करता है और क्लाइंट-नियंत्रित, अनऑथेंटिकेटेड फ़ॉरवर्डिंग हेडर को अस्वीकार करता है। यदि कोई विश्वसनीय मैपिंग मौजूद नहीं है, तो मूल URI का अनुमान लगाने के बजाय बाउंड्री पर DPoP को समाप्त करें और एक शॉर्ट-लिव्ड आंतरिक पहचान जारी करें।
फ़ॉलो-अप 4: लेगेसी क्लाइंट केवल Bearer भेज सकते हैं। क्या आप उनका हमेशा समर्थन कर सकते हैं?
स्थायी कम्पैटिबिलिटी कोई सुरक्षा डिज़ाइन नहीं है। क्लाइंट वर्ज़न, यूज़र रिस्क और रिसोर्स प्रकार द्वारा एक माइग्रेशन डेडलाइन निर्धारित करें; हाई-वैल्यू राइट्स के लिए पहले DPoP की आवश्यकता रखें, एक कार्रवाई योग्य अपग्रेड त्रुटि लौटाएं, और अवशिष्ट ट्रैफ़िक की निगरानी करें। केवल तभी एक प्रतिबंधित Bearer रूट रखें जब एक जोखिम समीक्षा इसे उचित ठहराती है और डिवाइस बाइंडिंग या रेट लिमिट्स जोड़ती है।