प्रॉम्प्ट और संदर्भ
एक रिसोर्स सर्वर रीड्स के लिए एक सामान्य एक्सेस टोकन स्वीकार करता है, लेकिन ट्रांसफ़र, पेआउट-अकाउंट में बदलाव और संवेदनशील एक्सपोर्ट्स के लिए एक मजबूत ऑथेंटिकेशन स्तर की आवश्यकता होती है। जब क्लाइंट के पास उस स्तर की कमी होती है, तो उसे अस्पष्ट 403 के बजाय एक कार्रवाई योग्य (actionable) चैलेंज प्राप्त होना चाहिए। RFC 9470 का उपयोग करके रिसोर्स सर्वर, ऑथराइजेशन सर्वर और क्लाइंट के बीच स्टेप-अप फ़्लो डिज़ाइन करें।
RFC 9470 बियरर (Bearer) चैलेंज के लिए insufficient_user_authentication एरर को परिभाषित करता है और आवश्यक स्तर को व्यक्त करने के लिए acr_values या संबंधित ऑथेंटिकेशन संदर्भ का उपयोग करता है। इंटरव्यू में API एरर्स, टोकन क्लेम्स, पुनः ऑथराइजेशन, इडेम्पोटेंट पुनः प्रयासों और डाउनग्रेड सीमाओं के पूरे लूप का परीक्षण किया जाता है।
इंटरव्यूअर क्या टेस्ट कर रहा है
- ऑथराइजेशन विफलता, अपर्याप्त यूज़र ऑथेंटिकेशन और टोकन एक्सपायरी के बीच अंतर करना।
- आंतरिक जोखिम विवरणों को उजागर किए बिना
WWW-Authenticateमें आवश्यक ऑथेंटिकेशन संदर्भ को व्यक्त करना। - लूप्स और डाउनग्रेड्स को रोकते हुए एक क्लाइंट को चैलेंज से पुनः ऑथराइज करने की अनुमति देना।
- रिसोर्स सर्वर पर जारीकर्ता (issuer), ऑडियंस (audience), स्कोप (scope),
acr,amrऔर समय क्लेम्स को सत्यापित करना। - उच्च जोखिम वाले राइट्स (writes) के लिए पुनः प्रयास, समवर्तीता (concurrency), ऑडिट, रोलबैक और यूज़र अनुभव को संभालना।
स्पष्टीकरण हेतु प्रश्न
- किन ऑपरेशन्स के लिए उच्च स्तर की आवश्यकता होती है, और क्या यह आवश्यकता एक
acrहै, एकamrहै, या एक ट्रांजेक्शन पुष्टि है? - क्या एक्सेस टोकन स्थानीय रूप से सत्यापित JWT हैं या इंट्रोस्पेक्टेड हैं? क्या रिसोर्स सर्वर ऑथेंटिकेशन संदर्भ देख सकता है?
- क्या क्लाइंट एक वेब, मोबाइल या सर्वर एप्लिकेशन है? क्या PKCE, prompt और max_age उपलब्ध हैं?
- क्या एक चैलेंज सिंगल-यूज़ होना चाहिए और राशि, प्राप्तकर्ता व एक nonce से बंधा (bound) होना चाहिए?
- यदि ऑथराइजेशन सेवा अनुपलब्ध है, तो कौन से रीड्स जारी रह सकते हैं और किन राइट्स को फेल क्लोज़्ड (fail closed) होना चाहिए?
30-सेकंड का उत्तर
पहले टोकन के जारीकर्ता, ऑडियंस, सिग्नेचर, एक्सपायरी और स्कोप को मान्य करें। यदि स्कोप पर्याप्त है लेकिन ऑथेंटिकेशन संदर्भ नहीं है, तो insufficient_user_authentication और आवश्यक acr_values व रिसोर्स का उपयोग करके WWW-Authenticate बियरर चैलेंज के साथ 401 लौटाएं। क्लाइंट उद्देश्य और स्टेट को संरक्षित रखता है, पुनः ऑथेंटिकेट करता है, उसी ऑडियंस, स्कोप और संदर्भ से बंधा एक टोकन प्राप्त करता है, और एक बार पुनः प्रयास करता है। चैलेंजेस को कम TTL, सीमित पुनः प्रयास और ट्रांजेक्शन बाइंडिंग दें; उच्च जोखिम वाले ऑपरेशन्स को कभी भी चुपचाप डाउनग्रेड न करें।
डीप-डाइव उत्तर
1. ऑथेंटिकेशन और रिसोर्स पॉलिसी को परिभाषित करें
ऑपरेशन्स को न्यूनतम ऑथेंटिकेशन पॉलिसियों में मैप करें: रीड्स के लिए एक बुनियादी स्तर, पेआउट बदलावों के लिए फ़िशिंग-प्रतिरोधी ऑथेंटिकेशन और ट्रांसफ़र के लिए ट्रांजेक्शन पुष्टि। प्रत्येक राइट को एक निश्चित स्तर के बराबर मानने के बजाय एंडपॉइंट, मेथड, टेनेंट, राशि और जोखिम संकेतों का मूल्यांकन करें।
ऑथराइजेशन सर्वर पंजीकृत acr मानों और स्वीकार्य ऑथेंटिकेशन विधियों को परिभाषित करता है। रिसोर्स सर्वर केवल पंजीकृत मानों को स्वीकार करता है; क्लाइंट स्वयं उच्च स्तर का दावा नहीं कर सकता। amr साक्ष्य है और यह acr के पॉलिसी मूल्यांकन को प्रतिस्थापित नहीं करता है।
2. चैलेंज रिस्पांस डिज़ाइन करें
जब एक वैध टोकन में आवश्यक संदर्भ की कमी होती है, तो 401 और error="insufficient_user_authentication" के साथ एक बियरर चैलेंज लौटाएं। इसमें आवश्यक acr_values, एक रिसोर्स पहचानकर्ता और एक एरर URI शामिल हो सकता है, लेकिन खाता संख्या, जोखिम स्कोर या आंतरिक नियमों का खुलासा नहीं होना चाहिए।
लापता या असत्यापनीय संदर्भ को अपर्याप्त मानें। समाप्त हो चुके टोकन, गैर-भरोसेमंद जारीकर्ता, गलत ऑडियंस और लापता स्कोप के लिए अलग-अलग एरर्स का उपयोग करें; हर विफलता को स्टेप-अप के रूप में न छिपाएं।
3. क्लाइंट को पुनः ऑथराइज करने की अनुमति दें
क्लाइंट चैलेंज को पार्स करता है और मूल लक्ष्य, आवश्यक acr_values, रिसोर्स और PKCE को एक नए ऑथराइजेशन अनुरोध से बांधता है। वेब क्लाइंट्स state का उपयोग करते हैं और OIDC क्लाइंट्स nonce का उपयोग करते हैं; मोबाइल क्लाइंट्स को एक असत्यापित चैलेंज को निष्पादन योग्य ऑथराइजेशन URL के रूप में नहीं मानना चाहिए।
पुनः ऑथराइजेशन के लिए अभी भी ऑथराइजेशन-सर्वर ऑथेंटिकेशन और सहमति की आवश्यकता होती है। prompt, max_age या एक ऑथेंटिकेशन पॉलिसी केवल एक अनुरोध है; सर्वर वास्तविक ऑथेंटिकेशन के आधार पर प्राप्त acr को टोकन में लिखता है। क्लाइंट स्थानीय रूप से टोकन को अपग्रेड के रूप में चिह्नित नहीं कर सकता है।
4. नए टोकन और मूल उद्देश्य को सत्यापित करें
नए टोकन पर सिग्नेचर, जारीकर्ता, ऑडियंस, स्कोप, exp, iat, acr और आवश्यक amr को सत्यापित करें। इंट्रोस्पेक्शन के साथ, पर्याप्त संदर्भ वाले एक विश्वसनीय ऑथराइजेशन-सर्वर रिस्पांस की आवश्यकता होती है। केवल स्कोप अपर्याप्त है क्योंकि अनुमति और ऑथेंटिकेशन की मजबूती अलग-अलग आयाम हैं।
उच्च जोखिम वाले कार्यों के लिए सर्वर स्टेट से एक चैलेंज nonce, ट्रांजेक्शन डाइजेस्ट या ऑथराइजेशन-अनुरोध ID को बांधें ताकि एक उच्च-ऑथेंटिकेशन टोकन को दूसरे ट्रांजेक्शन में स्थानांतरित न किया जा सके। लक्षित API के लिए टोकन ऑडियंस को सटीक रखें।
5. लूप्स, रीप्ले और डाउनग्रेड को रोकें
प्रत्येक चैलेंज को एक संक्षिप्त TTL और अद्वितीय ID दें, जिसमें अनुरोध डाइजेस्ट, टेनेंट, रिसोर्स, आवश्यक स्तर और पुनः प्रयास संख्या रिकॉर्ड की जाए। एक या सीमित संख्या में पुनः प्रयासों की अनुमति दें; एक सफल चैलेंज का उपभोग करें और विफल या समाप्त हो चुके चैलेंजेस को समाप्त करें।
कम acr_values, रिसोर्स या ऑडियंस प्रतिस्थापन, और स्टेप-अप टाइमआउट के बाद एक साधारण टोकन पर वापस जाने को अस्वीकार करें। ट्रांसफ़र के लिए इडेम्पोटेंसी कुंजियों का उपयोग करें ताकि ऑथेंटिकेशन के पुनः प्रयास साइड इफेक्ट्स की नकल न कर सकें।
6. उपलब्धता और एरर सीमाओं को संभालें
यदि ऑथराइजेशन सेवा या इंट्रोस्पेक्शन अनुपलब्ध है, तो कम जोखिम वाले रीड्स एक संक्षिप्त कैश का उपयोग कर सकते हैं; राइट्स, पेमेंट्स और अनुमति परिवर्तन डिफ़ॉल्ट रूप से फेल क्लोज़्ड होते हैं। चैलेंज एरर्स को ऑथेंटिकेशन विधियों या खाता स्थिति का खुलासा नहीं करना चाहिए। लॉग्स चैलेंज ID, जारीकर्ता, परिणाम और विलंबता (latency) को बनाए रखते हैं।
अपर्याप्त-संदर्भ दर, चैलेंज पूर्णता, लूप्स, एक्सपायरी, रीप्ले, PKCE विफलताओं, acr द्वारा इनकार और डुप्लिकेट व्यावसायिक प्रभावों को ट्रैक करें। हमलों से पॉलिसी त्रुटियों को अलग करने के लिए रिसोर्स और टेनेंट द्वारा अलर्ट्स को विभाजित करें।
7. सुरक्षित रूप से रोल आउट और रोल बैक करें
पहले एक API और टेनेंट पर स्टेप-अप सक्षम करें, जिसमें 401s, पूर्णता, विलंबता, सपोर्ट फीडबैक और उच्च जोखिम वाले इनकार की तुलना की जाए। जो क्लाइंट चैलेंजेस को नहीं समझते हैं, उन्हें प्रलेखित एरर्स और SDK मार्गदर्शन प्राप्त होता है; साधारण टोकन सभी के लिए चुपचाप स्वीकार नहीं किए जाते हैं।
रोलबैक केवल उन रिसोर्स पॉलिसियों को अक्षम करता है जो अभी तक सक्षम नहीं हुई हैं और सक्रिय ट्रांजेक्शन के लिए चैलेंज स्टेट व ऑडिट को संरक्षित रखता है। यदि संदर्भ लीक होता है, साइड इफेक्ट्स डुप्लिकेट होते हैं, या लूप्स दिखाई देते हैं, तो रोलआउट रोकें, पॉलिसी रद्द करें और टोकन बाइंडिंग की पुनः जांच करें।
आदर्श उत्तर
मैं प्रत्येक ऑपरेशन के लिए एक न्यूनतम ऑथेंटिकेशन स्तर परिभाषित करूँगा। टोकन को सत्यापित करने के बाद, रिसोर्स सर्वर 401 के साथ insufficient_user_authentication और न्यूनतम acr_values, रिसोर्स और एरर URI लौटाता है जब स्कोप पर्याप्त हो लेकिन acr या amr न हो। क्लाइंट उद्देश्य को संरक्षित रखता है और पुनः ऑथराइज करने के लिए state, nonce और PKCE का उपयोग करता है; ऑथराइजेशन सर्वर एक ऐसा टोकन जारी करता है जिसका संदर्भ वास्तविक ऑथेंटिकेशन को दर्शाता है।
रिसोर्स सर्वर जारीकर्ता, ऑडियंस, स्कोप, समय, acr और आवश्यक amr को फिर से सत्यापित करता है, एक चैलेंज ID या ट्रांजेक्शन डाइजेस्ट को सर्वर स्टेट से बांधता है। चैलेंजेस अल्पकालिक, एकल-उपयोग और सीमित पुनः प्रयास वाले होते हैं; निचले स्तर, नई ऑडियंस और बिना शर्त फ़ॉलबैक को अस्वीकार कर दिया जाता है। ऑथेंटिकेशन आउटेज के दौरान उच्च जोखिम वाले राइट्स फेल क्लोज़्ड होते हैं, और ट्रांसफ़र इडेम्पोटेंसी कुंजियों का उपयोग करते हैं।
सामान्य गलतियां
- कार्रवाई योग्य
insufficient_user_authenticationचैलेंज के बजाय एक सामान्य 403 या 401 लौटाना। - स्कोप की जांच करना लेकिन जारीकर्ता, ऑडियंस,
acr,amrऔर समय क्लेम्स की नहीं। - क्लाइंट को उच्च
acrका स्वयं दावा करने देना, या एक चैलेंज के बाद इसे कम करने देना। - एक चैलेंज को असत्यापित ऑथराइजेशन URL के रूप में मानना और state, nonce या PKCE को छोड़ देना।
- हमेशा के लिए पुनः प्रयास करना या ट्रांजेक्शन बाइंडिंग को छोड़ देना, जिससे ऑपरेशन्स के बीच टोकन पुनर्चक्रण की अनुमति मिल जाती है।
- ऑथेंटिकेशन अनुपलब्ध होने पर ट्रांसफ़र या अनुमति परिवर्तनों को चुपचाप डाउनग्रेड करना।
- खातों, जोखिम स्कोर्स या पूर्ण टोकन को लॉग करना।
फॉलो-अप प्रश्न और उत्तर
जब स्कोप पर्याप्त हो लेकिन acr न हो तो 401 क्यों लौटाएं?
स्कोप बताता है कि टोकन क्या एक्सेस कर सकता है; acr बताता है कि यूज़र ने कैसे ऑथेंटिकेट किया। एक रिसोर्स को दोनों की आवश्यकता हो सकती है, इसलिए क्लाइंट को एक नए ऑथराइजेशन चरण की आवश्यकता होती है।
एक चैलेंज में क्या शामिल होता है?
केवल आवश्यक ऑथेंटिकेशन स्तर, रिसोर्स पहचानकर्ता, एरर URI और अल्पकालिक चैलेंज पहचानकर्ता जो क्लाइंट कार्रवाई के लिए आवश्यक हैं। खाता, राशि, आंतरिक जोखिम और विधि विवरण सर्वर-साइड रखें।
क्या क्लाइंट अपग्रेड करने के लिए सीधे टोकन एंडपॉइंट को कॉल कर सकता है?
नहीं। इसे ऑथराइजेशन-सर्वर ऑथेंटिकेशन और सहमति के माध्यम से चैलेंज का पालन करना चाहिए। टोकन में प्राप्त acr का दावा सर्वर करता है, क्लाइंट नहीं।
आप किसी अपग्रेड किए गए टोकन को दूसरे ट्रांसफ़र के लिए उपयोग किए जाने से कैसे रोकते हैं?
ऑडियंस, रिसोर्स, चैलेंज ID या ट्रांजेक्शन डाइजेस्ट को वन-टाइम सर्वर स्टेट से बांधें, और ट्रांसफ़र के लिए एक इडेम्पोटेंसी कुंजी का उपयोग करें।
यदि इंट्रोस्पेक्शन अस्थायी रूप से अनुपलब्ध हो तो क्या होगा?
रिसोर्स जोखिम द्वारा वर्गीकृत करें। संक्षिप्त कैश्ड साक्ष्य साधारण रीड्स की सेवा कर सकते हैं; संदर्भ की पुष्टि न होने पर पेमेंट्स और अनुमति परिवर्तन फेल क्लोज़्ड होते हैं।
आप ऐसे पुराने क्लाइंट्स का समर्थन कैसे करते हैं जो चैलेंजेस को नहीं समझते हैं?
एक प्रलेखित एरर और SDK माइग्रेशन प्रकाशित करें, फिर प्रति टेनेंट सक्षम करें। उच्च जोखिम वाले ऑपरेशन्स अपनी आवश्यकता तब तक बनाए रखते हैं जब तक माइग्रेशन पूरा नहीं हो जाता।