बैकएंड इंटरव्यू: डेलिगेटेड सर्विस कॉल्स के लिए आप OAuth टोकन एक्सचेंज कैसे डिज़ाइन करेंगे?

समस्या और संदर्भ

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

एक्सचेंज एंडपॉइंट, वैलिडेशन नियम, क्लेम मैपिंग, कैशिंग, एरर हैंडलिंग, रिवोकेशन और मॉनिटरिंग डिज़ाइन करें। मान लें कि गेटवे एक नियंत्रित सर्वर-साइड क्लाइंट है और ब्राउज़र कभी भी डाउनस्ट्रीम टोकन नहीं रखते हैं। बिलिंग सर्विस को किसी अन्य सर्विस के लिए लक्षित टोकन को अस्वीकार करना होगा।

आपके डिज़ाइन को पाँच इनवेरिएंट्स (स्थिर नियमों) को बनाए रखना चाहिए:

1. एक्सचेंज सर्विस केवल मान्य सब्जेक्ट टोकन स्वीकार करती है जिन्हें एक्सचेंज करने की अनुमति है।
2. नई ऑडियंस, स्कोप, टेनेंट और रिसोर्स की पहुंच अपस्ट्रीम ऑथराइजेशन से अधिक व्यापक नहीं हो सकती।
3. सब्जेक्ट और एक्टर अलग-अलग पहचाने जाने योग्य और ट्रेस करने योग्य रहते हैं; कोई सर्विस यूज़र का रूप धारण नहीं कर सकती।
4. एक डाउनस्ट्रीम सर्विस केवल अपने स्वयं के जारीकर्ता (इश्यूअर), ऑडियंस और साइनिंग कीज़ पर भरोसा करती है।
5. रिवोकेशन, एक्सपायरी, की रोटेशन और ऑडिट सीमाओं की औसत समय सीमाएं मापने योग्य होती हैं।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

शुरुआत टोकन एक्सचेंज, टोकन फ़ॉरवर्डिंग, इंपरसनेशन (रूप बदलना), और डेलिगेशन (प्रत्यायोजन) के बीच अंतर स्पष्ट करके करें। RFC 8693 एक HTTP/JSON Security Token Service को परिभाषित करता है। एक अनुरोध में subject_token और वैकल्पिक रूप से actor_token शामिल हो सकता है; प्रतिक्रिया सामान्य OAuth टोकन-एंडपॉइंट प्रतिक्रिया का विस्तार करती है। प्रोटोकॉल अपने आप में व्यापक अधिकार प्रदान नहीं करता है।

अगला संकेत ऑडियंस अनुशासन (audience discipline) है। गेटवे को अपने लिए निर्दिष्ट बेयरर टोकन को बिलिंग, सर्च और एक्सपोर्ट सेवाओं को फ़ॉरवर्ड नहीं करना चाहिए। प्रत्येक डाउनस्ट्रीम टोकन के लिए केवल एक ऑडियंस और कॉल के लिए आवश्यक स्कोप की आवश्यकता होती है।

तीसरा संकेत प्रॉक्सी संबंध है। एक्सचेंज की अनुमति केवल तभी दी जाती है जब पॉलिसी यह अनुमति देती है कि एक्टर सब्जेक्ट की ओर से कार्य कर सकता है। may_act और act जैसे क्लेम्स के लिए एक विश्वसनीय जारीकर्ता या स्थानीय पॉलिसी स्रोत की आवश्यकता होती है। नए टोकन में क्लाइंट द्वारा प्रदान किए गए मनमाने sub या tenant_id को कॉपी करना एक एस्केलेशन (विशेषाधिकार वृद्धि) है।

अंत में, विफलता मोड पर चर्चा करें: पुराना ऑथराइजेशन कैश, एक डाउनस्ट्रीम जो केवल सिग्नेचर की जाँच करता है ऑडियंस की नहीं, लॉग्स में टोकन का दर्ज होना, गेटवे को सौंपा गया रिफ्रेश टोकन, और अपस्ट्रीम रिवोकेशन जो डाउनस्ट्रीम TTL समाप्त होने तक अप्रभावी रहता है।

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

• सब्जेक्ट कौन है और एक्टर कौन है? यहाँ सब्जेक्ट यूज़र है और एक्टर API गेटवे है; सर्विस-अकाउंट इंपरसनेशन के लिए एक स्पष्ट पॉलिसी की आवश्यकता होती है।
• एक्सचेंज किए गए टोकन का उपयोग कौन करता है? क्या बिलिंग ही एकमात्र ऑडियंस है, या कई रिसोर्स की अनुमति है? कई ऑडियंस ब्लास्ट रेडियस को बढ़ा देती हैं।
• स्कोप कैसे कम किया जाता है? अपस्ट्रीम में billing:read billing:write हो सकता है; इस अनुरोध को किस स्कोप की आवश्यकता है?
• टेनेंट सीमा की जाँच कहाँ की जाती है? कौन से आइडेंटिटी, सेशन और रिसोर्स स्टोर आधिकारिक हैं? रिक्वेस्ट-बॉडी के टेनेंट फ़ील्ड पर कभी भरोसा न करें।
• रिवोकेशन लक्ष्य क्या है? उदाहरण के लिए, पाँच सेकंड के भीतर नए एक्सचेंजों को रोकना और मौजूदा डाउनस्ट्रीम टोकन को दो मिनट तक सीमित करना।
• क्या गेटवे को रिफ्रेश टोकन की आवश्यकता है? एक डेलिगेटेड कॉल को सामान्यतः शॉर्ट-लिव्ड एक्सेस टोकन की आवश्यकता होती है; लॉन्ग-लिव्ड रिफ्रेश टोकन के लिए एक अलग थ्रेट रिव्यू की आवश्यकता होती है।

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

“मैं गेटवे से एक यूज़र subject_token, एक गेटवे actor_token, एक निश्चित बिलिंग ऑडियंस और न्यूनतम स्कोप के साथ मानक टोकन एंडपॉइंट को कॉल करवाऊँगा। एक्सचेंज सर्विस जारीकर्ता, सिग्नेचर, exp, nbf, क्लाइंट ऑथेंटिकेशन, सब्जेक्ट की डेलिगेशन पॉलिसी और टेनेंट स्थिति को मान्य करती है। एक पॉलिसी टेबल अपस्ट्रीम स्कोप्स को अनुमत डाउनस्ट्रीम स्कोप पर मैप करती है। नए टोकन में केवल बिलिंग ऑडियंस, छोटी एक्सपायरी, टेनेंट संदर्भ और सब्जेक्ट/एक्टर संबंध शामिल होते हैं; यह असत्यापित क्लेम्स को कभी कॉपी नहीं करता है।

बिलिंग सर्विस केवल अपने जारीकर्ता, साइनिंग कीज़ और ऑडियंस पर भरोसा करती है और रिसोर्स-लेवल ऑथराइजेशन करती है। एक्सचेंज निर्णयों को कुछ समय के लिए कैश किया जा सकता है, लेकिन रिवोकेशन इवेंट्स और छोटे TTL को निर्धारित लक्ष्य को पूरा करना चाहिए। टोकन बॉडीज़, एक्सचेंज अनुरोध और एक्टर सीक्रेट्स को रेडैक्ट किया जाता है। एरर जेनेरिक होते हैं; ऑडिट रिकॉर्ड में रिक्वेस्ट ID, सब्जेक्ट, एक्टर, ऑडियंस, स्कोप और पॉलिसी वर्शन को सुरक्षित रखा जाता है।”

चरण-दर-चरण डिज़ाइन

चरण 1: टोकन और ट्रस्ट सीमा को परिभाषित करें

एक्सचेंज सर्विस एक ऑथराइजेशन सर्वर या विश्वसनीय STS है, न कि कोई मनमाना गेटवे हेल्पर। यह अनुमत अपस्ट्रीम जारीकर्ताओं, JWKS, क्लाइंट-ऑथेंटिकेशन विधियों, डाउनस्ट्रीम ऑडियंस और पॉलिसी वर्शन्स को कॉन्फ़िगर करती है। गेटवे mTLS, प्राइवेट-की JWT या किसी अन्य स्वीकृत विधि के साथ प्रमाणित करता है; केवल एक स्टैटिक स्ट्रिंग डेलिगेशन अधिकार का प्रमाण नहीं है।

न्यूनतम अनुरोध इस प्रकार दिख सकता है:

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
subject_token=...
subject_token_type=urn:ietf:params:oauth:token-type:access_token
actor_token=...
actor_token_type=urn:ietf:params:oauth:token-type:access_token
audience=https://billing.internal
scope=billing:read

RFC 8693 अनुरोधकर्ता को एक्सचेंज में क्लाइंट के रूप में मानता है। एक रिसोर्स सर्वर किसी बैकएंड सर्विस के लिए उपयुक्त टोकन के साथ इनकमिंग टोकन का व्यापार करने के लिए अस्थायी रूप से उस क्लाइंट के रूप में कार्य कर सकता है। यह भूमिका अपने आप में नई अनुमतियाँ प्रदान नहीं करती है।

चरण 2: स्रोत द्वारा सब्जेक्ट और एक्टर को मान्य करें

टोकन प्रकार के अनुसार एक वैलिडेटर चुनें, फिर एल्गोरिदम अनुमति-सूची, जारीकर्ता, exp, nbf, आवश्यक क्लाइंट, टोकन प्रकार और रिवोकेशन स्थिति की जाँच करें। जारीकर्ता द्वारा JWKS को कैश करें और kid द्वारा रोटेट करें; एक अज्ञात की (key) एक नियंत्रित रिफ्रेश को ट्रिगर कर सकती है, लेकिन एल्गोरिदम डाउनग्रेड कभी नहीं।

सब्जेक्ट वह यूज़र या वर्कलोड है जिसका प्रतिनिधित्व किया जा रहा है। एक्टर वह गेटवे है जिसने वास्तव में एक्सचेंज शुरू किया था। पॉलिसी को यह तय करना होगा कि क्या यह एक्टर इस ऑडियंस पर इस सब्जेक्ट के लिए कार्य कर सकता है, केवल यह नहीं कि क्या एक्टर एक ज्ञात सर्विस है। RFC 8693 का may_act एक अधिकृत एक्टर को व्यक्त कर सकता है; एक्सचेंज किया गया टोकन act के साथ वर्तमान एक्टर को व्यक्त कर सकता है। दोनों क्लेम्स के लिए एक विश्वसनीय जारीकर्ता या स्थानीय पॉलिसी की आवश्यकता होती है।

रिक्वेस्ट-बॉडी के sub, tenant_id, या roles को आइडेंटिटी तथ्यों के रूप में न मानें। मान्य टोकन और आधिकारिक टेनेंट डायरेक्टरी से संदर्भ का पुनर्निर्माण करें और अनुपलब्ध या परस्पर विरोधी सब्जेक्ट डेटा को अस्वीकार करें।

चरण 3: मोनोटोनिक रूप से संकीर्ण ऑथराइजेशन की गणना करें

ऑथराइजेशन को एक संकुचित इंटरसेक्शन (constrained intersection) के रूप में व्यक्त करें:

issued_scope = requested_scope
             ∩ subject_allowed_scope
             ∩ actor_allowed_scope
             ∩ audience_policy_scope
             ∩ tenant_state_scope

खाली या अत्यधिक व्यापक अनुरोधित स्कोप को अस्वीकार करें; चुपचाप व्यापक डिफ़ॉल्ट न बनाएं। ऑडियंस सर्विस रजिस्ट्री से आती है, गेटवे द्वारा आपूर्ति किए गए किसी मनमाने URL से नहीं। प्रत्येक ऑडियंस अनुमत क्लेम्स, स्कोप, TTL और रिसोर्स प्रकारों को बाँधती है।

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

चरण 4: शॉर्ट-लिव्ड, सत्यापन योग्य डाउनस्ट्रीम टोकन जारी करें

एक्सेस टोकन में iss, sub, aud, exp, iat, स्कोप, टेनेंट पहचान, क्लाइंट ID, पॉलिसी वर्शन और एक्टर संबंध शामिल होने चाहिए। इसकी एक्सपायरी अपस्ट्रीम शेष जीवनकाल या व्यावसायिक जोखिम विंडो से अधिक नहीं होनी चाहिए। सामान्य एक्सचेंज परिणाम के रूप में रिफ्रेश टोकन वापस न करें।

बिलिंग सर्विस जारीकर्ता, ऑडियंस, JWKS और अनुमत एल्गोरिदम को पिन करती है और हर अनुरोध पर रिसोर्स ऑथराइजेशन करती है। aud वैलिडेशन के बिना सिग्नेचर वैलिडेशन एक सर्विस को दूसरी सर्विस के लिए जारी किए गए टोकन को स्वीकार करने की अनुमति दे देता है। एक सेंडर-कंस्ट्रेंड (sender-constrained) टोकन यह सुनिश्चित कर सकता है कि बेयरर वैल्यू को कॉपी करना पर्याप्त नहीं है।

चरण 5: कैश, रिवोकेशन और की रोटेशन का समन्वय करें

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

खोए हुए इनवैलिडेशन संदेशों, नोड रीस्टार्ट और रेप्लिकेशन लैग का परीक्षण करें। JWKS रोटेशन के लिए सीमित ओवरलैप और एक ट्रेस करने योग्य kid की आवश्यकता होती है। साइनिंग की को रद्द करने से उसके द्वारा साइन किए गए प्रत्येक टोकन पर असर पड़ता है; यह सब्जेक्ट-लेवल रिवोकेशन का विकल्प नहीं है।

चरण 6: एरर, रीप्ले और उपलब्धता को संभालें

अज्ञात जारीकर्ता, एक्सपायरी, गलत ऑडियंस, गैर-प्रत्यायोज्य सब्जेक्ट, अपर्याप्त स्कोप और अनुपलब्ध पॉलिसी के लिए एक समान invalid_grant या invalid_target-क्लास एरर लौटाएं। यह प्रकट न करें कि कोई सब्जेक्ट मौजूद है या नहीं; आंतरिक रूप से एक रिक्वेस्ट ID और सुरक्षित रीज़न कोड रखें।

एक्सचेंज अनुरोधों में बेयरर सामग्री होती है और उन्हें URLs, सामान्य लॉग्स, ट्रेस एट्रिब्यूट्स या एरर रिपोर्ट्स में नहीं जाना चाहिए। यदि अपस्ट्रीम टोकन को रीप्ले किया जा सकता है, तो गेटवे ट्रैफ़िक चुराने वाला हमलावर एक्सचेंजों को दोहरा सकता है। TLS, सेंडर कंस्ट्रेंट्स, छोटे TTLs, रेट लिमिट्स और जोखिम संकेत इस विंडो को कम करते हैं। यदि पॉलिसी स्टोरेज अनुपलब्ध है, तो उच्च-जोखिम वाले राइट्स के लिए फ़ेल-क्लोज़्ड (fail closed) रहें। किसी भी कम-जोखिम वाले रीड फ़ॉलबैक के लिए बाउंडेड स्टेल-पॉलिसी आयु की आवश्यकता होती है।

चरण 7: सब्जेक्ट चेन और टेनेंट सीमा का ऑडिट करें

request_id, सब्जेक्ट, एक्टर, क्लाइंट, टेनेंट, ऑडियंस, अनुरोधित और जारी किया गया स्कोप, टोकन ID, पॉलिसी वर्शन, जारीकर्ता की ID और निर्णय रिकॉर्ड करें। टोकन बॉडी को कभी भी रिकॉर्ड न करें। डाउनस्ट्रीम लॉग्स टोकन ID और रिक्वेस्ट ID का संदर्भ देते हैं ताकि गेटवे कॉल को यूज़र कार्रवाई से जोड़ा जा सके।

रिसोर्स सर्विस को केवल गेटवे से आने वाले X-Tenant-ID हेडर पर भरोसा नहीं करना चाहिए। यह हस्ताक्षरित टोकन से टेनेंट संदर्भ पढ़ती है, फिर रिसोर्स स्वामित्व, बिलिंग-खाता स्थिति और अनुमोदन नियमों की जाँच करती है। क्रॉस-टेनेंट एक्सेस, कन्फ्यूज्ड डिप्टी बिहेवियर, स्कोप विस्तार, गलत ऑडियंस और पुराने टोकन के रीप्ले के लिए प्रतिकूल परीक्षण (adversarial tests) जोड़ें।

चरण 8: चरणबद्ध साक्ष्यों के साथ रोल आउट करें

एक परीक्षण टेनेंट के लिए एक निश्चित ऑडियंस और स्कोप पंजीकृत करें और साबित करें कि कोई पुराना टोकन बिलिंग तक नहीं पहुंच सकता है। एक्सचेंज रिजेक्शन रेट, पॉलिसी लेटेंसी, टोकन TTL, ऑडियंस एरर्स, कैश हिट्स और रिवोकेशन प्रोपेगेशन का निरीक्षण करते हुए नए जारीकर्ता और की को कैनरी रोलआउट करें। इन मापों के स्थिर रहने के बाद ही प्रोडक्शन टेनेंट्स पर विस्तार करें।

एक रोलबैक स्विच रखें जो नए टोकन जारी करने को रोकता है और ज्ञात-अच्छे क्लाइंट कॉन्फ़िगरेशन को पुनर्स्थापित करता है। डाउनस्ट्रीम ऑडियंस चेक्स को अक्षम करके या ऑडिट रिकॉर्ड्स को हटाकर कभी भी रोलबैक न करें।

आदर्श उच्च-गुणवत्ता वाला उत्तर

“मैं एक्सचेंज सर्विस को एक विश्वसनीय STS मानता हूँ। गेटवे एक क्लाइंट-ऑथेंटिकेटेड यूज़र subject_token, अपना स्वयं का actor_token, एक निश्चित बिलिंग ऑडियंस और न्यूनतम स्कोप प्रस्तुत करता है। सर्विस प्रत्येक जारीकर्ता, सिग्नेचर, टाइम क्लेम, टोकन प्रकार, क्लाइंट और डेलिगेशन नियम को मान्य करती है, फिर अनुरोधित स्कोप को सब्जेक्ट, एक्टर, ऑडियंस और टेनेंट-स्टेट पॉलिसी के साथ इंटरसेक्ट करती है। यह मनमानी ऑडियंस और अधिकार का विस्तार करने वाले किसी भी अनुरोध को अस्वीकार करती है।

डाउनस्ट्रीम टोकन केवल बिलिंग के लिए होता है, यह अपस्ट्रीम टोकन से पहले समाप्त होता है, और सब्जेक्ट, एक्टर, टेनेंट, स्कोप, पॉलिसी वर्शन और टोकन ID रिकॉर्ड करता है। बिलिंग अपने जारीकर्ता, JWKS और ऑडियंस को पिन करती है और रिसोर्स-लेवल टेनेंट ऑथराइजेशन निष्पादित करती है। टोकन और एक्सचेंज अनुरोध कभी भी लॉग्स में नहीं जाते; ऑडिट रिकॉर्ड में केवल चेन और निर्णय मेटाडेटा होते हैं।

रिवोकेशन अथॉरिटी को अपडेट करता है और इनवैलिडेशन प्रसारित करता है, जिससे पाँच सेकंड के भीतर नए एक्सचेंज रुक जाते हैं। डाउनस्ट्रीम टोकन अधिकतम दो मिनट तक चलते हैं, जिसमें जोखिम के आधार पर इंट्रोस्पेक्शन या शॉर्ट-TTL वैलिडेशन चुना जाता है। कैश कीज़ में सभी पहचान और पॉलिसी आयाम शामिल होते हैं, और JWKS रोटेशन में सीमित ओवरलैप होता है। टोकन एक्सचेंज अधिकार को संकुचित करता है और जवाबदेही को सुरक्षित रखता है; यह हर सर्विस में यूज़र पहचान को कॉपी नहीं करता है।”

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

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

फॉलो-अप प्रश्न और संदर्भ उत्तर

may_act और act क्या हल करते हैं?

may_act बताता है कि सब्जेक्ट टोकन किस एक्टर को कार्य करने के लिए अधिकृत करता है; act बताता है कि नए टोकन में वर्तमान में कौन किसकी ओर से कार्य कर रहा है। इनमें से कोई भी सिग्नेचर, जारीकर्ता, ऑडियंस या स्थानीय ऑथराइजेशन चेक्स की जगह नहीं लेता है, और दोनों के लिए एक विश्वसनीय स्रोत की आवश्यकता होती है।

यूज़र टोकन को बिलिंग सर्विस को फ़ॉरवर्ड क्यों नहीं करते?

अपस्ट्रीम टोकन आमतौर पर गेटवे को लक्षित करता है और कई रिसोर्सेज को कवर कर सकता है। फ़ॉरवर्ड करने से ऑडियंस और अनुमति का जोखिम बढ़ जाता है। एक्सचेंज केवल बिलिंग के लिए एक शॉर्ट-लिव्ड, ऑडिट योग्य टोकन जारी करता है।

क्या बिलिंग को ऑनलाइन इंट्रोस्पेक्शन का उपयोग करना चाहिए?

यह रिवोकेशन लक्ष्यों, ट्रैफ़िक और उपलब्धता पर निर्भर करता है। उच्च-जोखिम वाले राइट्स इंट्रोस्पेक्शन का उपयोग कर सकते हैं; साधारण रीड्स शॉर्ट-TTL JWT का उपयोग कर सकते हैं। सबसे खराब देरी को मापें; एक सीमित तंत्र के बिना ऑफ़लाइन कैशिंग और तत्काल रिवोकेशन दोनों का दावा नहीं किया जा सकता है।

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

उच्च-जोखिम वाले एक्सचेंजों के लिए फ़ेल-क्लोज़्ड रहें। कम-जोखिम वाला रीड स्पष्ट रूप से सीमित पुराने पॉलिसी कैश का उपयोग कर सकता है, जिसका फ़ॉलबैक मॉनिटरिंग और ऑडिट में दिखाई दे। डिफ़ॉल्ट रूप से अनुमति देना उपलब्धता की घटना को प्रिविलेज एस्केलेशन में बदल देता है।

आप मल्टी-टेनेंट कैश मिक्स-अप को कैसे रोकते हैं?

कैश की (key) में जारीकर्ता, सब्जेक्ट, एक्टर, टेनेंट, ऑडियंस, स्कोप और पॉलिसी वर्शन शामिल करें, और रिसोर्स स्वामित्व की जाँच भी जारी रखें। केवल यूज़र ID या ऑडियंस पर आधारित की एक टेनेंट के निर्णय को दूसरे के लिए पुन: उपयोग कर सकती है।

अपस्ट्रीम टोकन रद्द कर दिया गया है लेकिन डाउनस्ट्रीम टोकन अभी भी मान्य है। तब क्या होगा?

नए एक्सचेंजों को तुरंत रोकें और डाउनस्ट्रीम को जोखिम के अनुसार इंट्रोस्पेक्ट करने दें या इनवैलिडेशन इवेंट्स का उपभोग करने दें। यदि यह केवल ऑफ़लाइन सत्यापित करता है, तो TTL को स्वीकृत अधिकतम विंडो तक सीमित करें और उस अंतराल में ऑपरेशनों का ऑडिट करें; कमिट किए गए ऑपरेशनों को वापस नहीं लिया जा सकता है।

आप सुरक्षित रूप से रोलबैक कैसे करते हैं?

नए एक्सचेंज को रोकें, समस्याग्रस्त ऑडियंस या पॉलिसी वर्शन को वापस लें, पुरानी साइनिंग की के लिए सीमित वैलिडेशन बनाए रखें, और ज्ञात-अच्छे क्लाइंट कॉन्फ़िगरेशन को पुनर्स्थापित करें। शॉर्टकट के रूप में कभी भी ऑडियंस चेक्स को अक्षम न करें और न ही ऑडिट साक्ष्य को हटाएं।