बैकएंड इंटरव्यू: ऑथेंटिकेशन आउटेज पैदा किए बिना आप JWT साइनिंग कीज़ को कैसे रोटेट करते हैं?

प्रॉम्प्ट और लागू संदर्भ

एक ऑथेंटिकेशन सेवा RS256 के साथ एक्सेस टोकन साइन करती है। 1 मिनट के क्लॉक स्क्यू के साथ, एक टोकन अधिकतम 15 मिनट के लिए स्वीकार किया जा सकता है। दो सौ बैकएंड सेवाएं जारीकर्ता के OpenID डिस्कवरी दस्तावेज़ से एक निश्चित jwks_uri पढ़ती हैं, 10 मिनट के लिए JWKS कैश करती हैं, और टोकन को स्थानीय रूप से वेरिफ़ाई करती हैं।

साइनिंग-की रोटेशन डिज़ाइन करें जो वैध अनुरोधों के लिए 401 प्रतिक्रियाओं की लहर उत्पन्न न करे। इन मामलों को कवर करें:

• एक सामान्य रोटेशन के दौरान पुराने और नए टोकन आते हैं;
• टोकन हेडर में एक ऐसा kid शामिल है जो स्थानीय कैश से अनुपस्थित है;
• कई यादृच्छिक (random) kid मान एक JWKS रिफ्रेश स्टॉर्म बनाने का प्रयास करते हैं;
• रोटेशन के दौरान JWKS एंडपॉइंट टाइम आउट हो जाता है या विफल हो जाता है;
• वर्तमान प्राइवेट की से समझौता (compromise) हो सकता है और आपातकालीन कार्रवाई की आवश्यकता होती है;
• पुरानी की (key) को रिटायर करने से पहले ऑपरेटर को यह साबित करना होगा कि प्रत्येक वेरिफ़ायर नई की को स्वीकार करता है।

15 मिनट का लाइफटाइम, 10 मिनट का कैश, 1 मिनट का स्क्यू, और 200 सेवाएं परिदृश्य की बाधाएं (constraints) हैं, सार्वभौमिक सिफारिशें नहीं। मुख्य कौशल बैकएंड ऑथेंटिकेशन प्रोटोकॉल डिज़ाइन, कैश निरंतरता, विफलता सिमेंटिक्स और सुरक्षा संचालन है, इसलिए श्रेणी backend है।

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

पहला, क्या उम्मीदवार सुरक्षित क्रम बता सकता है: नई पब्लिक की प्रकाशित करें, वेरिफ़ायर्स को इसे देखने दें, नई प्राइवेट की से साइन करना शुरू करें, पुराने टोकन समाप्त होने की प्रतीक्षा करें, और उसके बाद ही पुरानी पब्लिक की को हटाएं? पहले साइनर को स्विच करने से यह गारंटी मिलती है कि पुराने JWKS कैश वाली सेवाएं नए टोकन को अस्वीकार कर देंगी।

दूसरा, क्या वे समझते हैं कि JWKS एक पब्लिक-की सेट है? RFC 7517 एक keys ऐरे को परिभाषित करता है, और kid केवल एक विश्वसनीय सेट से एक की का चयन करता है। JWKS में कभी भी प्राइवेट की प्रकाशित नहीं की जानी चाहिए। एक kid भी विश्वास का प्रमाण नहीं है; इसे विश्वसनीय जारीकर्ता, एक पिन किए गए एल्गोरिदम और सफल सिग्नेचर वेरिफिकेशन से बंधा होना चाहिए।

तीसरा, क्या वे कैशिंग और सुरक्षा को संतुलित कर सकते हैं? प्रत्येक अनुरोध पर JWKS फ़ेच करने से जारीकर्ता ओवरलोड हो जाता है, जबकि हमेशा के लिए कैश करने से नई की की स्वीकृति और पुरानी की के रिटायरमेंट में देरी होती है। एक अज्ञात kid एक नियंत्रित रिफ्रेश को ट्रिगर कर सकता है, लेकिन समवर्ती (concurrent) रिफ्रेश को संयोजित (coalesce) किया जाना चाहिए, दर-सीमित (rate-limited) किया जाना चाहिए, और पहचानकर्ता के अनुपस्थित होने की पुष्टि होने पर एक छोटे नेगेटिव कैश द्वारा फॉलो किया जाना चाहिए।

चौथा, क्या वे नियोजित रोटेशन को प्राइवेट-की कॉम्प्रोमाइज़ से अलग करते हैं? नियोजित रोटेशन उपलब्धता के लिए पुरानी और नई पब्लिक कीज़ को ओवरलैप करता है। कॉम्प्रोमाइज़ के दौरान, पुरानी की को विश्वसनीय बनाए रखने से हमलावर को टोकन बनाने की अनुमति मिलती है। आपातकालीन मार्ग के लिए स्पष्ट कैश अमान्यकरण (invalidation), निरसन (revocation) नियंत्रण और एक मजबूत सुरक्षा प्राथमिकता की आवश्यकता होती है।

पांचवां, क्या वे सिग्नेचर चेकिंग को पूर्ण सत्यापन तक विस्तारित करते हैं? एक वेरिफ़ायर अनुमत एल्गोरिदम को पिन करता है, फिर सिग्नेचर, iss, aud, exp, और nbf को मान्य करता है। यह टोकन से किसी अविश्वसनीय jku या मनमाने की URL का पालन नहीं करता है, जो एल्गोरिदम भ्रम या SSRF को सक्षम कर सकता है।

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

• टोकन स्वीकृति का अधिकतम समय क्या है? प्रत्येक पुराने टोकन के लाइफटाइम का उपयोग करें जिसे अभी भी स्वीकार किया जा सकता है, न कि केवल एक नाममात्र कॉन्फ़िगर किए गए TTL का, और क्लॉक स्क्यू को शामिल करें।
• अधिकतम JWKS बासीपन (staleness) क्या है? ब्राउज़र, CDN, प्रॉक्सी और इन-प्रोसेस कैश प्रत्येक एक लेयर जोड़ सकते हैं; रोटेशन को वास्तविक ऊपरी सीमा (upper bound) की आवश्यकता होती है।
• क्या सभी वेरिफ़ायर्स को सक्रिय रूप से (proactively) रिफ्रेश किया जा सकता है? कॉन्फ़िगरेशन पुश, वर्शन पावती (acknowledgements), या कैनरी प्रोब केवल प्राकृतिक समाप्ति की प्रतीक्षा करने का स्थान ले सकते हैं।
• JWKS अनुपलब्ध होने पर क्या होता है? परिभाषित करें कि क्या कोई ज्ञात की एक सीमित बासी (stale) कैश का उपयोग कर सकती है और क्या कोई अज्ञात की फ़ेल-क्लोज़्ड (fail closed) होती है।
• क्या पहले से जारी किए गए टोकन को तुरंत निरस्त किया जाना चाहिए? एक सेल्फ-कंटेन्ड JWT अकेले रोटेशन के माध्यम से सटीक प्रति-टोकन निरसन का समर्थन नहीं कर सकता है; एक डिनाइलिस्ट, टोकन वर्शन या आत्मनिरीक्षण (introspection) की आवश्यकता हो सकती है।
• जारीकर्ता और वेरिफ़ायर्स को कौन नियंत्रित करता है? एक संगठन रिफ्रेश पावती एकत्र कर सकता है; तृतीय-पक्ष वेरिफ़ायर आमतौर पर एक प्रलेखित संगतता विंडो पर निर्भर करते हैं।
• प्राइवेट कीज़ कहाँ रखी जाती हैं? उन्हें KMS, HSM, या प्रतिबंधित साइनिंग सेवा में जनरेट और उपयोग करें; केवल सार्वजनिक सामग्री ही प्रकाशन तल (publication plane) से संबंधित है।
• सफलता का क्या अर्थ है? नियोजित रोटेशन वैध पुराने और नए टोकन को चालू रखता है। किसी कॉम्प्रोमाइज़्ड की पर तुरंत भरोसा करना बंद करने के लिए आपातकालीन रोटेशन नियंत्रित पुनः प्रमाणीकरण (reauthentication) को स्वीकार कर सकता है।

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

"मैं रोटेशन को पब्लिश, वार्म, स्विच, ओवरलैप और रिटायर में विभाजित करता हूँ। मैं एक नए kid के साथ एक की जनरेट करता हूँ, फिर JWKS में नई और पुरानी दोनों पब्लिक कीज़ प्रकाशित करता हूँ। मैं अधिकतम 10 मिनट की कैश विंडो की प्रतीक्षा करता हूँ, या सभी 200 वेरिफ़ायर्स को सक्रिय रूप से रिफ्रेश करता हूँ और उनका नया JWKS वर्शन एकत्र करता हूँ। नई पब्लिक की वेरिफ़ाइएबल होने के बाद ही जारीकर्ता नई प्राइवेट की के साथ साइन करना शुरू करता है।

मैं अंतिम पुराने टोकन जारी होने के 15 मिनट बाद तक, साथ ही 1 मिनट के क्लॉक स्क्यू तक पुरानी पब्लिक की को रखता हूँ। वेरिफ़ायर केवल एक विश्वसनीय जारीकर्ता के सेट के भीतर kid का चयन करते हैं, RS256 को पिन करते हैं, और सिग्नेचर, iss, aud, exp, और nbf को मान्य करते हैं। एक अज्ञात kid एक संयोजित (coalesced), दर-सीमित रिफ्रेश को ट्रिगर करता है; यदि यह अभी भी अनुपस्थित है, तो अस्वीकार करें। JWKS आउटेज के दौरान, एक ज्ञात की स्पष्ट रूप से सीमित बासी कैश का उपयोग कर सकती है, जबकि एक अज्ञात की फ़ेल-क्लोज़्ड होती है।

यदि प्राइवेट की से समझौता हो जाता है, तो मैं पुरानी की जारी करना बंद कर देता हूँ, एक नई की को प्रकाशित और स्विच करता हूँ, कैश अमान्यकरण प्रसारित करता हूँ, और पुरानी की द्वारा हस्ताक्षरित टोकन को निरस्त करता हूँ। मैं सामान्य ओवरलैप विंडो का उपयोग नहीं करता हूँ। मैं kid, कैश आयु, JWKS फ़ेच वॉल्यूम, और पुराने kid के अंतिम अवलोकन द्वारा परिणामों के माध्यम से पूर्णता साबित करता हूँ।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: ट्रस्ट रूट और वेरिफिकेशन इनवेरिएंट्स को पिन करें

एक वेरिफ़ायर एक कॉन्फ़िगर किए गए विश्वसनीय जारीकर्ता से शुरू होता है, उसके OpenID डिस्कवरी दस्तावेज़ को पढ़ता है, और उस दस्तावेज़ से HTTPS jwks_uri का उपयोग करता है। टोकन हेडर का kid केवल इस विश्वसनीय JWKS से एक उम्मीदवार पब्लिक की का चयन करता है। टोकन वेरिफ़ायर को jku के माध्यम से पुनर्निर्देशित नहीं कर सकता है, और एप्लिकेशन को kid को सीधे फ़ाइल, डेटाबेस या URL लुकअप में संयोजित (concatenate) नहीं करना चाहिए।

प्रत्येक वेरिफिकेशन इन इनवेरिएंट्स को बनाए रखता है:

1. केवल कॉन्फ़िगर किए गए RS256 को स्वीकार करें; टोकन अपने एल्गोरिदम पर बातचीत नहीं कर सकता है;
2. विश्वसनीय जारीकर्ता के JWKS में अद्वितीय रूप से एक साइनिंग की से मेल खाने के लिए kid की आवश्यकता है;
3. सिग्नेचर वेरिफिकेशन के बाद, अपेक्षित iss, इस API के aud, exp, और nbf की आवश्यकता है;
4. यदि कोई जांच विफल हो जाती है तो पूरे टोकन को अस्वीकार करें;
5. केवल पब्लिक की सामग्री प्रकाशित करें जबकि प्राइवेट कीज़ नियंत्रित साइनिंग सीमा के भीतर रहें।

रोटेशन के दौरान एक न्यूनतम की सेट इस तरह दिख सकता है:

{
  "keys": [
    { "kty": "RSA", "use": "sig", "alg": "RS256", "kid": "2026-07-a", "n": "...", "e": "AQAB" },
    { "kty": "RSA", "use": "sig", "alg": "RS256", "kid": "2026-07-b", "n": "...", "e": "AQAB" }
  ]
}

ऐरे का क्रम वरीयता नहीं है; वेरिफ़ायर एक सटीक kid का चयन करता है। एक नई पीढ़ी को एक नया, कभी-पुनः उपयोग न किया गया kid मिलता है, क्योंकि कैश एक ही पहचानकर्ता के पीछे छिपी परिवर्तित की सामग्री को अलग नहीं कर सकता है।

चरण 2: साइन करने से पहले पब्लिश के साथ नियोजित रोटेशन निष्पादित करें

नियोजित रोटेशन को स्पष्ट स्थितियों (explicit states) के रूप में मॉडल करें:

GENERATED
  -> PUBLISHED(old + new)
  -> VERIFIER_READY
  -> SIGNING_WITH_NEW
  -> OLD_TOKEN_DRAINED
  -> OLD_KEY_RETIRED

प्रोटोकॉल है:

1. नियंत्रित की प्रणाली में 2026-07-b जनरेट करें, लेकिन अभी इसके साथ साइन न करें;
2. एक नए ETag या सेट वर्शन के साथ, 2026-07-a और 2026-07-b युक्त एक JWKS प्रकाशित करें;
3. 10 मिनट की अधिकतम कैश-बासीपन विंडो की प्रतीक्षा करें, या सभी 200 वेरिफ़ायर्स को रिफ्रेश करें और पावती एकत्र करें कि वे नए kid को पहचानते हैं;
4. प्रत्येक परिवेश में कैनरी टोकन के साथ सिग्नेचर, जारीकर्ता, ऑडियंस और समय दावों (time claims) को वेरिफ़ाई करें;
5. वेरिफ़ायर्स द्वारा नई पब्लिक की स्वीकार किए जाने के बाद ही, 2026-07-b के साथ साइन करना शुरू करें;
6. T_last_old रिकॉर्ड करें, जो अंतिम पुरानी-की टोकन का जारी करने का समय है;
7. T_last_old + 15 minutes + 1 minute से पहले नहीं, और पुराने-kid ट्रैफ़िक की अपेक्षाओं से मेल खाने के बाद, JWKS से पुरानी पब्लिक की को हटा दें;
8. असामान्य पुराने-kid ट्रैफ़िक पर नज़र रखना जारी रखें, फिर पुरानी निजी सामग्री को अक्षम और नष्ट कर दें।

"साइन करने से पहले पब्लिश करें" नए टोकन की सुरक्षा करता है। "पुरानी साइनिंग बंद करें, पुराने टोकन ड्रेन करें, फिर हटाएं" पुराने टोकन की सुरक्षा करता है। कैश प्रसार सबसे प्रारंभिक साइनिंग स्विच को नियंत्रित करता है; पुराने टोकन की स्वीकृति लाइफटाइम और क्लॉक स्क्यू सबसे प्रारंभिक पब्लिक-की हटाने को नियंत्रित करते हैं।

चरण 3: एक नियंत्रित रिफ्रेश के साथ एक अज्ञात kid को संभालें

एक अज्ञात kid एक वैध नई पीढ़ी या हमलावर द्वारा आपूर्ति किया गया शोर हो सकता है। वेरिफ़ायर प्रत्येक पहली बार दिखने पर तुरंत अस्वीकार नहीं कर सकता है, और यह प्रत्येक दृश्य को असीमित अपस्ट्रीम ट्रैफ़िक में नहीं बदल सकता है। एक उपयुक्त प्रवाह है:

verify(token):
  header = parse_bounded_header(token)
  require header.alg == "RS256"
  key = trusted_cache.find(header.kid)
  if key is missing:
    refresh trusted_issuer_jwks once through single-flight
    key = trusted_cache.find(header.kid)
  if key is missing:
    short_negative_cache.add(header.kid)
    reject "unknown kid"
  verify signature and require iss, aud, exp, nbf

एक जारीकर्ता के लिए समवर्ती मिस्ड कॉल्स एक सिंगल-फ़्लाइट रिफ्रेश साझा करते हैं। रिफ्रेश में एक वैश्विक कूलडाउन और टाइमआउट होता है। एक ताज़ा सेट द्वारा पुष्टि किए जाने के बाद कि kid अनुपस्थित है, एक छोटा नेगेटिव कैश यादृच्छिक पहचानकर्ताओं को जारीकर्ता तक पहुँचने से रोकता है। नेगेटिव TTL वास्तविक रोटेशन को अवरुद्ध करने के लिए पर्याप्त लंबा नहीं हो सकता है, और उच्च-कार्डिनैलिटी मेमोरी हमलों को रोकने के लिए वेरिफ़ायर को kid लंबाई और प्रारूप को सीमित करना चाहिए।

रिफ्रेश केवल कॉन्फ़िगर किए गए jwks_uri को TLS पर, रिस्पॉन्स-आकार, कनेक्शन और पढ़ने की सीमाओं के साथ एक्सेस करता है। यह ETag सशर्त अनुरोधों का उपयोग कर सकता है। हमलावर द्वारा प्रदान किए गए jku, x5u, या समान स्थान कभी भी ट्रस्ट रूट को प्रतिस्थापित नहीं करते हैं।

चरण 4: JWKS विफलता के दौरान उपलब्धता सीमा को परिभाषित करें

सामान्य अनुरोध स्थानीय कैश का उपयोग करते हैं; JWKS एंडपॉइंट प्रत्येक प्रमाणीकरण अनुरोध के सिंक्रोनस पथ में नहीं बैठता है। यदि कोई रिफ्रेश विफल हो जाता है:

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

एक छोटा stale-if-error कंट्रोल-प्लेन ब्लिप को अवशोषित करता है लेकिन वर्तमान सेट से हटाई गई की में स्थानीय विश्वास को भी बढ़ाता है। वह अवधि सुरक्षा मॉडल से संबंधित है और कॉम्प्रोमाइज़ के दौरान स्पष्ट अमान्यकरण द्वारा ओवरराइड की जानी चाहिए। उपलब्धता अनिश्चित काल तक बासी कीज़ पर निर्भर नहीं हो सकती।

चरण 5: प्राइवेट-की कॉम्प्रोमाइज़ के लिए एक अलग आपातकालीन मार्ग का उपयोग करें

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

केंद्रीय JWKS से पुरानी पब्लिक की को हटाना अपर्याप्त है क्योंकि एक वेरिफ़ायर अपना 10 मिनट का कैश बनाए रख सकता है। एक अभ्यस्त (exercised) कंट्रोल-प्लेन ब्रॉडकास्ट, कैश-वर्शन पुश, सेवा पुनरारंभ, या किसी अन्य अमान्यकरण चैनल का उपयोग करें। यदि तृतीय-पक्ष वेरिफ़ायर्स तक नहीं पहुँचा जा सकता है, तो जारीकर्ता उनकी कैश ऊपरी सीमा द्वारा सीमित है और उसे उस एक्सपोज़र को स्पष्ट रूप से बताना होगा।

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

चरण 6: वर्शन, मेट्रिक्स और ऑडिट के साथ पूर्णता साबित करें

JWKS रिस्पॉन्स को एक अवलोकनीय सेट वर्शन या ETag को प्रदर्शित करना चाहिए। वेरिफ़ायर वर्तमान वर्शन, कैश आयु, रिफ्रेश परिणाम और मान्यता प्राप्त kid मानों की रिपोर्ट करते हैं। जारीकर्ता टोकन बॉडी या निजी सामग्री को लॉग किए बिना अपने सक्रिय साइनिंग kid को रिकॉर्ड करता है।

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

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

चरण 7: संक्रमण और प्रतिकूल इनपुट का परीक्षण करें

केवल एक स्थिर वैध टोकन का परीक्षण न करें। कम से कम निम्नलिखित को कवर करें:

1. केवल पुरानी पब्लिक की प्रकाशित होने के साथ, पुराना टोकन पास हो जाता है और एक नया-की टोकन विफल हो जाता है;
2. ओवरलैप के दौरान, दोनों टोकन पीढ़ियां पास हो जाती हैं और बार-बार की जाने वाली जांचें JWKS को फिर से फ़ेच नहीं करती हैं;
3. केवल पुरानी की कैश्ड होने के साथ, एक नया kid ठीक एक नियंत्रित रिफ्रेश के बाद पास हो जाता है;
4. कई समान या यादृच्छिक अज्ञात kid मान सीमित रिफ्रेश का कारण बनते हैं और अस्वीकार कर दिए जाते हैं;
5. JWKS टाइमआउट, 500, अत्यधिक बड़ा रिस्पॉन्स, और अमान्य JSON ज्ञात-की नीति को सुरक्षित रखते हैं जबकि अज्ञात कीज़ विफल हो जाती हैं;
6. गलत एल्गोरिदम, iss, aud, समाप्त हो चुका टोकन, और अभी तक मान्य नहीं हुआ टोकन सभी विफल हो जाते हैं;
7. एक हमलावर द्वारा आपूर्ति किया गया jku वेरिफ़ायर को किसी भिन्न स्थान से संपर्क नहीं कराता है;
8. पुरानी की को हटाने के बाद, एक नई प्रक्रिया पुराने टोकन को अस्वीकार कर देती है, जबकि एक पुराना कैश केवल अपनी बताई गई विंडो के भीतर स्वीकार करता है;
9. एक कॉम्प्रोमाइज़ ड्रिल प्रत्येक नियंत्रित वेरिफ़ायर पर पुराने kid को अमान्य कर देती है;
10. जब वेरिफ़ायर तैयार नहीं होते हैं तो साइनिंग गेट नई-की एक्टिवेशन को रोकता है।

स्वीकृति प्राधिकरण परिणामों और JWKS अनुरोध गणना दोनों की जांच करती है। एक टोकन जो पास हो जाता है जबकि प्रत्येक अनुरोध जारीकर्ता से टकराता है, एक सही कार्यान्वयन नहीं है। वैध नए टोकन को अस्वीकार किए जाने के साथ सामान्य फ़ेच वॉल्यूम भी सही नहीं है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं kid को एक विश्वसनीय जारीकर्ता के JWKS के भीतर एक चयनकर्ता के रूप में परिभाषित करता हूँ, न कि विश्वास के स्रोत के रूप में। प्रत्येक वेरिफ़ायर केवल कॉन्फ़िगर किए गए RS256 को स्वीकार करता है, निश्चित डिस्कवरी jwks_uri से पब्लिक कीज़ प्राप्त करता है, kid द्वारा चयन करता है, और सिग्नेचर, iss, aud, exp, और nbf को मान्य करता है। JWKS में केवल पब्लिक कीज़ होती हैं; प्राइवेट कीज़ एक KMS या HSM साइनिंग सीमा में रहती हैं।

नियोजित रोटेशन के लिए, मैं एक नए kid के साथ एक की जनरेट करता हूँ, पुरानी और नई दोनों पब्लिक कीज़ प्रकाशित करता हूँ, और ETag अपडेट करता हूँ। फिर मैं परिदृश्य की अधिकतम 10 मिनट की कैश विंडो की प्रतीक्षा करता हूँ या सभी 200 वेरिफ़ायर्स को सक्रिय रूप से रिफ्रेश करता हूँ और तत्परता एकत्र करता हूँ। कैनरी टोकन साबित करते हैं कि साइनर स्विच करने से पहले नई की काम करती है।

मैं अंतिम पुराने-टोकन जारी करने का समय रिकॉर्ड करता हूँ। पुरानी पब्लिक की कम से कम 15 मिनट के स्वीकृति लाइफटाइम और 1 मिनट के क्लॉक स्क्यू के लिए बनी रहती है, और मैं इसे पुराने-kid ट्रैफ़िक समाप्त होने के बाद ही हटाता हूँ। दोनों संक्रमण द्वार (transition gates) स्पष्ट हैं: नए टोकन तब तक साइन न करें जब तक कि नई पब्लिक की प्रसारित न हो जाए, और पुरानी पब्लिक की को तब तक न हटाएं जब तक कि पुराने टोकन अमान्य न हो जाएं।

कैश मिस होने पर, प्रत्येक जारीकर्ता को टाइमआउट, कूलडाउन और ETag के साथ एक सिंगल-फ़्लाइट रिफ्रेश मिलता है। यदि की अनुपस्थित रहती है, तो अस्वीकार करें और इसे संक्षेप में नेगेटिव-कैश करें। यादृच्छिक kid मान अपस्ट्रीम बाढ़ में परिवर्तित नहीं हो सकते। अस्थायी JWKS विफलता के दौरान, एक ज्ञात की केवल एक बताई गई सीमित बासी विंडो के भीतर जारी रह सकती है, जबकि एक अज्ञात की हमेशा फ़ेल-क्लोज़्ड होती है।

यदि पुरानी प्राइवेट की से समझौता हो जाता है, तो मैं पुरानी साइनिंग बंद कर देता हूँ, नई की को प्रकाशित और स्विच करता हूँ, कैश अमान्यकरण प्रसारित करता हूँ, और पुराने kid या पुराने iat श्रेणी के टोकन को निरस्त करता हूँ। मैं सामान्य ओवरलैप को बनाए नहीं रखता क्योंकि हमलावर साइन कर रहा हो सकता है। अंत में, मैं JWKS वर्शन, कैश आयु, kid द्वारा वेरिफिकेशन त्रुटियों, एक नई-की कैनरी, और अंतिम पुराने-kid अवलोकन के साथ पूर्णता साबित करता हूँ, और मैं नियमित रूप से संक्रमण और जारीकर्ता विफलता का अभ्यास करता हूँ।"

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

• पब्लिक की प्रकाशित करने से पहले साइनर को स्विच करना → बासी JWKS वाली सेवाएं नए टोकन को अस्वीकार करती हैं → प्रकाशित करें, प्रसार साबित करें, फिर नई साइनिंग शुरू करें।
• केवल नई की प्रकाशित करना → वैध पुराने टोकन तुरंत विफल हो जाते हैं → स्वीकृति विंडो के दौरान दोनों पीढ़ियों को प्रकाशित करें।
• एक मनमानी अवधि की प्रतीक्षा करना → यह वास्तविक कैश या टोकन लाइफटाइम से छोटा हो सकता है → अधिकतम बासीपन, अंतिम पुराने जारी करने, टोकन लाइफटाइम और क्लॉक स्क्यू से गेट्स प्राप्त करें।
• प्रत्येक अनुरोध के लिए JWKS डाउनलोड करना → एक जारीकर्ता विफलता सभी प्रमाणीकरण को तोड़ देती है और लोड को बढ़ाती है → स्थानीय कैशिंग, सशर्त रिफ्रेश और एक सीमित बासी नीति का उपयोग करें।
• प्रत्येक अज्ञात kid के लिए रिफ्रेश करना → यादृच्छिक पहचानकर्ता एक रिफ्रेश स्टॉर्म बनाते हैं → सिंगल-फ़्लाइट, दर सीमा, नेगेटिव कैशिंग और इनपुट सीमाओं का उपयोग करें।
• एक अज्ञात kid के लिए प्रत्येक की को आज़माना → की का चयन अस्पष्ट हो जाता है और हमले की सतह को चौड़ा करता है → एक बार रिफ्रेश करें, फिर सटीक मिलान के बिना अस्वीकार करें।
• टोकन से alg या jku पर भरोसा करना → एल्गोरिदम भ्रम या SSRF का पालन हो सकता है → वेरिफ़ायर कॉन्फ़िगरेशन में एल्गोरिदम और JWKS स्थान को पिन करें।
• केवल सिग्नेचर की जाँच करना → किसी अन्य जारीकर्ता, ऑडियंस या समय के लिए एक टोकन स्वीकार किया जा सकता है → iss, aud, exp, और nbf को भी मान्य करें।
• नई की सामग्री के साथ kid का पुन: उपयोग करना → कैश यह नहीं बता सकते कि एक पहचानकर्ता बदल गया है → प्रत्येक की पीढ़ी को एक नया पहचानकर्ता सौंपें।
• केंद्रीय JWKS हटाने को तत्काल निरसन के रूप में मानना → वेरिफ़ायर अभी भी पुराना कैश रख सकते हैं → स्पष्ट कैश अमान्यकरण और टोकन निरसन प्रदान करें।
• कॉम्प्रोमाइज़ के बाद सामान्य ओवरलैप बनाए रखना → एक हमलावर उस पूरी विंडो के दौरान टोकन बना सकता है → आपातकालीन मार्ग का उपयोग करें और आवश्यक पुनः प्रमाणीकरण स्वीकार करें।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती प्रश्न 1: पुरानी पब्लिक की को वास्तव में कितने समय तक रहना चाहिए?

अंतिम पुरानी-की टोकन के जारी करने के समय से शुरू करते हुए, इसे कम से कम "अधिकतम स्वीकृति लाइफटाइम + क्लॉक स्क्यू" के लिए रखें। इस परिदृश्य में, वह 15 + 1 = 16 मिनट है। कतार में देरी, ऑफ़लाइन जारी करना, या कोई लंबी अंतर्निहित (implicit) स्वीकृति विंडो यदि वे मौजूद हैं, तो जोड़ें। हटाने से पहले पुराने-kid ट्रैफ़िक का निरीक्षण करें ताकि कॉन्फ़िगरेशन और रनटाइम वास्तविकता सहमत हों।

अनुवर्ती प्रश्न 2: अज्ञात kid के लिए तुरंत 401 क्यों नहीं लौटाते?

एक वैध रोटेशन के बाद, इस प्रक्रिया के प्राकृतिक कैश रिफ्रेश से पहले एक नया टोकन आ सकता है। एक नियंत्रित रिफ्रेश उस अंतर को बंद कर देता है। इसे संयोजित (coalesced), दर-सीमित और विश्वसनीय URL तक ही सीमित होना चाहिए; केवल तभी अस्वीकार करें जब नवीनतम सेट में अभी भी kid की कमी हो, जिससे संगतता और प्रवर्धन प्रतिरोध (amplification resistance) संतुलित रहे।

अनुवर्ती प्रश्न 3: क्या JWKS डाउन होने पर वेरिफिकेशन फ़ेल-ओपन होना चाहिए?

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

अनुवर्ती प्रश्न 4: कॉम्प्रोमाइज़्ड की को हटाने के बाद पुराने टोकन क्यों काम कर सकते हैं?

वेरिफ़ायर्स के पास अभी भी 10 मिनट पुराना कैश हो सकता है, और सेल्फ-कंटेन्ड JWT किसी केंद्रीय प्राधिकरण से परामर्श नहीं करते हैं। आपातकालीन मार्ग को कैश को सक्रिय रूप से अमान्य करना चाहिए और पुराने kid, जारी करने के समय, या टोकन वर्शन द्वारा एक अस्थायी अस्वीकृति नियम लागू करना चाहिए। उच्च-जोखिम वाली प्रणालियाँ तेजी से निरसन के लिए आत्मनिरीक्षण या सर्वर-साइड सत्रों का उपयोग कर सकती हैं।

अनुवर्ती प्रश्न 5: आप रोटेशन के दौरान रिफ्रेश स्टॉर्म से कैसे बचते हैं?

प्री-पब्लिकेशन अधिकांश प्रक्रियाओं को प्राकृतिक रिफ्रेश के दौरान की प्राप्त करने की अनुमति देता है, और सक्रिय रिफ्रेश को जिटर (jitter) के साथ कंपित (staggered) किया जा सकता है। वास्तविक मिस के लिए, प्रति जारीकर्ता एक सिंगल-फ़्लाइट का उपयोग करें, साथ ही कूलडाउन, ETag, टाइमआउट और शॉर्ट नेगेटिव कैशिंग का उपयोग करें। JWKS अनुरोध वॉल्यूम और अज्ञात-kid कार्डिनैलिटी की निगरानी करें; बार-बार रीट्राय करने के बजाय विसंगतियों को दर-सीमित करें।

अनुवर्ती प्रश्न 6: साइनिंग गेट को कैसे स्वचालित किया जा सकता है?

प्रत्येक JWKS को एक वर्शन असाइन करें। वेरिफ़ायर समय-समय पर लोड किए गए वर्शन और मान्यता प्राप्त kid की रिपोर्ट करते हैं। रिलीज़ कंट्रोलर को प्राइवेट की को सक्रिय करने से पहले एक लक्ष्य तत्परता स्तर और महत्वपूर्ण पथों पर सफल कैनरी टोकन की आवश्यकता होती है। नए-kid वेरिफिकेशन विफलताओं में कोई भी वृद्धि साइनिंग को रोकती है या रोल बैक करती है; नई पब्लिक की को प्रकाशित छोड़ने से पुराने टोकन को कोई नुकसान नहीं होता है।

अनुवर्ती प्रश्न 7: क्या होगा यदि तृतीय-पक्ष वेरिफ़ायर तत्परता स्वीकार नहीं कर सकते हैं?

एक स्थिर ओवरलैप अनुबंध प्रकाशित करें: नई पब्लिक की को कम से कम एक अधिकतम कैश अवधि पहले प्रदर्शित करें, पुरानी की को तब तक बनाए रखें जब तक कि सभी पुराने टोकन समाप्त न हो जाएं, और उचित कैशिंग हेडर भेजें। जारीकर्ता तृतीय पक्षों को रिफ्रेश करने के लिए बाध्य नहीं कर सकता है, इसलिए संगतता विंडो, परिवर्तन नोटिस और कैनरी जांच आंतरिक पावती की जगह लेते हैं। आपातकालीन समझौता अभी भी एक अपरिहार्य जोखिम विंडो छोड़ सकता है।