1. प्रश्न और संदर्भ
कई API रिसोर्स सर्वर एक ऑथराइजेशन सर्वर द्वारा जारी किए गए एक्सेस टोकन स्वीकार करते हैं। उन्हें यह जानने की आवश्यकता है कि क्या कोई टोकन सक्रिय (active) है, कौन सा क्लाइंट इसका मालिक है, इसके पास कौन से स्कोप हैं और यह कब समाप्त (expire) होता है। सुरक्षा टीम को चोरी हुए टोकन के त्वरित रिवोकेशन की भी आवश्यकता होती है। डिज़ाइन में रियल-टाइम रिवोकेशन, कम लेटेंसी और ऑथराइजेशन-सर्विस की उपलब्धता के बीच संतुलन होना चाहिए।
2. इंटरव्यूअर क्या मूल्यांकन कर रहा है
- क्या आप RFC 7662 इंट्रोस्पेक्शन और RFC 7009 रिवोकेशन सिमेंटिक्स को समझते हैं।
- क्या कैश, रिवोकेशन इवेंट और वर्ज़न पुराने सक्रिय परिणामों को रिवोकेशन छिपाने से रोकते हैं।
- क्या आप अपारदर्शी (opaque) टोकन, स्थानीय JWT वैलिडेशन और DPoP जैसे प्रूफ-ऑफ-पोज़ेशन में अंतर समझते हैं।
- क्या आउटेज, पुनः प्रयास (retry), टेनेंट-आइसोलेशन और ऑडिट नीतियां स्पष्ट हैं।
3. उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न
- क्या टोकन कम समय तक चलने वाले (short-lived) एक्सेस टोकन हैं, रिफ्रेश टोकन हैं, या दोनों हैं?
- क्या आप एक टोकन, एक ग्रांट, एक यूज़र सेशन या पूरे क्लाइंट को रिवोक करते हैं?
- रिसोर्स सर्वर रिवोकेशन प्रोपेगेशन में कितनी देरी स्वीकार कर सकते हैं?
- क्या कॉपी किए गए बियरर-टोकन के रीप्ले को रोकने के लिए आपको क्लाइंट की (key) या DPoP पब्लिक की को बाइंड करने की आवश्यकता है?
4. 30-सेकंड का उत्तर ढांचा
एंडपॉइंट, सोर्स ऑफ़ ट्रुथ, कैश, रिवोकेशन प्रोपेगेशन और विफलता नीति का उपयोग करें।
ऑथराइजेशन सर्वर सुरक्षित इंट्रोस्पेक्शन और रिवोकेशन एंडपॉइंट्स को एक्सपोज़ करता है। स्टेट स्टोर टोकन हैश, क्लाइंट, स्कोप, समाप्ति समय और रिवोकेशन वर्ज़न रखता है। रिसोर्स सर्वर एक छोटे TTL के लिए सक्रिय परिणामों को कैश करते हैं और एंट्रीज़ को तुरंत हटाने के लिए रिवोकेशन इवेंट्स की सदस्यता लेते हैं। ऑथराइजेशन आउटेज के दौरान उच्च-जोखिम वाले स्कोप्स फेल क्लोज़ (fail closed) होते हैं; कम-जोखिम वाले अनुरोध थोड़े समय के लिए अनएक्स्पायर्ड पॉजिटिव कैश का उपयोग कर सकते हैं। प्रश्नों, रिवोकेशन और विफलताओं का ऑडिट किया जाता है।
5. चरण-दर-चरण गहन विश्लेषण
चरण 1: टोकन स्टेट और एंडपॉइंट ऑथराइजेशन को परिभाषित करें
केवल विश्वसनीय रिसोर्स सर्वर ही इंट्रोस्पेक्शन को कॉल कर सकते हैं। अनावश्यक पहचान डेटा को उजागर किए बिना आवश्यक फ़ील्ड जैसे active, client_id, username, scope, exp, iat और sub लौटाएं। रिवोकेशन एंडपॉइंट अपने कॉलर और टोकन प्रकार को प्रमाणित करता है, बार-बार होने वाले रिवोकेशन के लिए RFC 7009 का पालन करता है, और यह प्रकट नहीं करता है कि क्या पहले से अमान्य टोकन मौजूद था।
चरण 2: स्टेट स्टोरेज और इंडेक्स डिज़ाइन करें
कुंजी (key) के रूप में टोकन फिंगरप्रिंट या हैश का उपयोग करें। जारी करने का समय, समाप्ति, ग्रांट ID, क्लाइंट, स्कोप, स्टेट वर्ज़न और रिवोकेशन का कारण स्टोर करें। बल्क रिवोकेशन के लिए ग्रांट ID को इंडेक्स करें; संवेदनशील प्लेनटेक्स्ट को लॉग्स से बाहर रखें। टेनेंट या हैश के आधार पर शार्ड करें ताकि एक क्लाइंट हॉट पार्टीशन न बन सके।
चरण 3: कैश और रिवोकेशन प्रोपेगेशन को संभालें
पॉजिटिव परिणामों को एक छोटे TTL के लिए कैश करें; लंबे नेगेटिव कैश से बचें। रिवोकेशन के बाद, टोकन फिंगरप्रिंट और स्टेट वर्ज़न पब्लिश करें। रिसोर्स सर्वर स्थानीय प्रविष्टियों को तुरंत हटा देते हैं; आवधिक पुल्स (periodic pulls) या वर्ज़न चेक छूटे हुए इवेंट्स को ठीक करते हैं। जब रियल-टाइम रिवोकेशन लेटेंसी के लायक हो, तो उच्च-जोखिम वाली कार्रवाइयों के लिए ऑनलाइन इंट्रोस्पेक्शन बाध्य करें।
चरण 4: विफलता, पुनः प्रयास और प्रूफ ऑफ पोज़ेशन को संभालें
इंट्रोस्पेक्शन टाइमआउट पर एक्सपोनेंशियल बैकऑफ़ और सर्किट ब्रेकिंग का उपयोग करें ताकि रिसोर्स सर्वर ऑथराइजेशन सर्विस पर अत्यधिक लोड न डालें। आउटेज के दौरान, स्कोप जोखिम के आधार पर फेल-क्लोज़्ड या अनएक्स्पायर्ड पॉजिटिव कैश के संक्षिप्त उपयोग का चयन करें। DPoP के साथ, टोकन से बंधी पब्लिक की के विरुद्ध अनुरोध प्रमाण (request proof) को भी सत्यापित करें, जिससे कॉपी किए गए बियरर टोकन के रीप्ले जोखिम को कम किया जा सके।
6. उच्च-गुणवत्ता वाला नमूना उत्तर
मैं सिस्टम को ऑथराइजेशन एंडपॉइंट्स, इंट्रोस्पेक्शन, रिवोकेशन, एक स्टेट स्टोर, एक रिवोकेशन इवेंट बस और एक रिसोर्स-सर्वर SDK में विभाजित करूँगा। स्टेट स्टोर एक टोकन हैश द्वारा कीड (keyed) होता है और क्लाइंट, स्कोप्स, जारी करने और समाप्ति का समय, ग्रांट ID, रिवोकेशन स्थिति और वर्ज़न रखता है। इंट्रोस्पेक्शन केवल वही फ़ील्ड लौटाता है जिनकी रिसोर्स सर्वर को आवश्यकता होती है और इसके लिए कॉलर प्रमाणीकरण की आवश्यकता होती है।
>
SDK सामान्य स्कोप्स को तीस सेकंड के लिए कैश करता है और उच्च-जोखिम वाले स्कोप्स का ऑनलाइन इंट्रोस्पेक्शन करता है। रिवोकेशन एक टोकन और पूरे ग्रांट-स्तरीय रिवोकेशन का समर्थन करता है, फिर एक वर्ज़न्ड इवेंट पब्लिश करता है। SDK प्राप्त होने पर अपने कैश को हटा देता है, जबकि एक आवधिक रिपेयर जॉब छूटे हुए इवेंट्स को संभालती है। एक पॉजिटिव कैश एंट्री जिसका वर्ज़न अब मेल नहीं खाता है, उपयोग से पहले फिर से इंट्रोस्पेक्ट की जानी चाहिए।
>
ऑथराइजेशन टाइमआउट पर, कम-जोखिम वाले अनुरोध एक अनएक्स्पायर्ड पॉजिटिव कैश का उपयोग कर सकते हैं जबकि उच्च-जोखिम वाले अनुरोध अस्वीकार कर दिए जाते हैं। सर्किट ब्रेकिंग और जिटर वाले पुनः प्रयास कैस्केडिंग विफलता को रोकते हैं। DPoP के साथ, SDK अनुरोध प्रमाण और बाउंड की (bound key) की पुष्टि करता है। क्वेरीज़, रिवोकेशन, कैश हिट्स और विफलताएं रिडैक्टेड ऑडिट स्टोरेज में जाती हैं ताकि चोरी हुए टोकन के प्रसार का पता लगाया जा सके।
7. सामान्य विफलता मोड
- स्थानीय JWT सिग्नेचर वैलिडेशन को रियल-टाइम रिवोकेशन मानना।
- रिवोकेशन इवेंट्स या वर्ज़न चेक के बिना सक्रिय परिणामों को लंबे समय तक कैश करना।
- इंट्रोस्पेक्शन को सार्वजनिक रूप से एक्सपोज़ करना या अनावश्यक यूज़र फ़ील्ड लौटाना।
- ऑथराइजेशन आउटेज के दौरान प्रत्येक अनुरोध के लिए फेल-ओपन होना।
- बिना टाइमआउट, सर्किट ब्रेकिंग या जिटर के पुनः प्रयास करना और प्रमाणीकरण स्टैम्पीड (stampede) का कारण बनना।
8. फॉलो-अप प्रश्न और प्रतिक्रियाएं
फॉलो-अप 1: नेगेटिव कैश आमतौर पर छोटे क्यों होने चाहिए?
हो सकता है कि कोई टोकन अभी-अभी जारी किया गया हो, कोई रेप्लिकेट पुराना हो, या रिवोकेशन अभी भी प्रोपेगेट हो रहा हो। एक छोटा नेगेटिव कैश अस्थायी अनुपस्थिति को एक लंबी अमान्यता अवधि में बदलने से रोकता है।
फॉलो-अप 2: क्या रिफ्रेश टोकन को रिवोक करने से एक्सेस टोकन भी रिवोक होने चाहिए?
ग्रांट और सुरक्षा नीति का उपयोग करें। यदि कोई रिफ्रेश टोकन चोरी हो जाता है, तो आमतौर पर उस ग्रांट के तहत शेष टोकन को रिवोक कर दिया जाता है और रिसोर्स सर्वरों को वर्ज़न या इवेंट्स के माध्यम से कैश को अमान्य करने दिया जाता है।
फॉलो-अप 3: आप डुप्लिकेट या आउट-ऑफ-ऑर्डर रिवोकेशन इवेंट्स को कैसे रोकते हैं?
एक मोनोटोनिक वर्ज़न या रिवोकेशन समय शामिल करें। उपभोक्ता केवल स्थानीय स्थिति जितनी नई या उससे नई वर्ज़न को स्वीकार करते हैं; डुप्लिकेट इवेंट्स इडेम्पोटेंट रहते हैं, और कोई पुराना इवेंट सक्रिय स्थिति को पुनर्स्थापित नहीं कर सकता है।