प्रॉम्प्ट और संदर्भ
आप एक OAuth 2.0 ऑथराइजेशन सर्वर के ओनर हैं। क्लाइंट ऑथराइजेशन अनुरोधों में उच्च-मूल्य वाले स्कोप, रिसोर्स इंडिकेटर्स और ट्रांज़ैक्शन संदर्भ शामिल हैं। टीम चाहती है कि सर्वर अनुरोध के स्रोत और अखंडता (integrity) को सत्यापित करे, और कभी-कभी उन पैरामीटर्स को छिपाए। एक JWT-Secured Authorization Request (JAR) डिज़ाइन करें: Request Object प्रारूप, साइनिंग और एन्क्रिप्शन, ट्रांसपोर्ट, लाइफटाइम, की रोटेशन, और विफलता हैंडलिंग।
यह प्रश्न पहचान (identity), भुगतान और बैकएंड भूमिकाओं के लिए उपयुक्त है। RFC 9101 ऑथराइजेशन पैरामीटर्स को एक JWT में रखता है; JWS अखंडता और स्रोत प्रमाणीकरण प्रदान करता है, जबकि JWE गोपनीयता प्रदान कर सकता है। JAR को PAR से अलग पहचानें: JAR अनुरोध ऑब्जेक्ट की सुरक्षा करता है, जबकि PAR इसे सीधे ऑथराइजेशन सर्वर पर पुश करता है और एक संदर्भ लौटाता है।
इंटरव्यूअर क्या जांच रहा है
- ऑथराइजेशन एंडपॉइंट, क्लाइंट, की डायरेक्टरी और टोकन एंडपॉइंट के बीच जिम्मेदारियों का पृथक्करण।
- जारीकर्ता (issuer), ऑडियंस, एल्गोरिदम, टाइम क्लेम्स और OAuth पैरामीटर्स का सत्यापन।
- बाहरी-पैरामीटर विरोधों, रीप्ले, डीकंप्रेशन या क्रिप्टो संसाधन दुरुपयोग, और की रोटेशन की हैंडलिंग।
- JAR, PAR, PKCE, state और nonce के लिए स्पष्ट खतरे की सीमाएं।
- ऑब्जर्वेबिलिटी, रोलआउट और रोलबैक नियंत्रणों के माध्यम से संचालन (operationalization)।
स्पष्टीकरण के लिए प्रश्न
- क्या क्लाइंट पब्लिक है या कॉन्फिडेंशियल? क्या क्लाइंट Request Object पर हस्ताक्षर करता है, या कोई विश्वसनीय बैकएंड इस पर हस्ताक्षर करता है?
- क्या हमें केवल अखंडता की आवश्यकता है, या ब्राउज़रों और मध्यस्थों को स्कोप, संसाधनों और ट्रांज़ैक्शन फ़ील्ड को पढ़ने में असमर्थ होना चाहिए?
- क्या बाहरी पैरामीटर JWT क्लेम्स को ओवरराइड कर सकते हैं? प्रति क्लाइंट
requestऔरrequest_uriके लिए नीतियां क्या हैं? - क्या यह OIDC लॉगिन, भुगतान ऑथराइजेशन, या सामान्य OAuth है? क्या nonce, स्टेप-अप प्रमाणीकरण और गैर-अस्वीकार्य ऑडिट की आवश्यकता है?
- क्या कीज स्थिर रूप से पंजीकृत हैं, JWKS के माध्यम से परोसी जाती हैं, या HSM में रखी जाती हैं? रोटेशन और निरस्तीकरण (revocation) लक्ष्य क्या हैं?
30-सेकंड का उत्तर
पहले स्थापित करें कि Request Object कौन जारी कर सकता है और किन कीज और एल्गोरिदम पर भरोसा किया जाता है। iss, aud, client_id, redirect_uri, response_type, स्कोप, टाइम क्लेम्स और एक रीप्ले पहचानकर्ता को सत्यापित करें। अखंडता और स्रोत प्रमाणीकरण के लिए अनुमति-सूचीबद्ध (allow-listed) JWS का उपयोग करें; जब अनुरोध गोपनीय होना चाहिए तो JWE जोड़ें। संरक्षित JWT क्लेम्स को प्रामाणिक मानें और बाहरी विरोधों को अस्वीकार करें। आकार और लाइफटाइम सीमित करें, TTL के साथ jti को ट्रैक करें, और सत्यापन अनुपलब्ध होने पर उच्च-जोखिम वाले अनुरोधों के लिए फेल क्लोज्ड (fail closed) करें। JAR ऑब्जेक्ट की सुरक्षा करता है, PAR ट्रांसपोर्ट और संदर्भ लाइफटाइम की सुरक्षा करता है, और PKCE ऑथराइजेशन-कोड रिडीमर को बांधता है।
गहन उत्तर
1. Request Object ट्रस्ट सीमा स्थापित करें
क्लाइंट request में एक JWT भेज सकता है, या इसे PAR के माध्यम से सबमिट कर सकता है और बाद में request_uri के साथ इसे संदर्भित कर सकता है। ऑथराइजेशन सर्वर विश्वसनीय जारीकर्ताओं और एल्गोरिदम का चयन करने के लिए क्लाइंट पंजीकरण का उपयोग करता है; इसे केवल इसलिए मनमानी कीज प्राप्त नहीं करनी चाहिए क्योंकि JWT हेडर में kid या jku शामिल है।
iss, aud, client_id, redirect_uri, response_type, स्कोप और संसाधन जैसे क्लेम्स पंजीकरण और ऑथराइजेशन संदर्भ से मेल खाने चाहिए। अहस्ताक्षरित बाहरी मान चुपचाप हस्ताक्षरित मानों को नहीं बदल सकते; परस्पर विरोधी या डुप्लिकेट महत्वपूर्ण पैरामीटर्स को अस्वीकार कर दिया जाता है।
2. JWS, JWE और एल्गोरिदम नीति चुनें
जब अखंडता और स्रोत प्रमाणीकरण की आवश्यकता हो तो JWS का उपयोग करें। जब अनुरोध में ऐसे फ़ील्ड हों जिन्हें ब्राउज़रों या मध्यस्थों को नहीं पढ़ना चाहिए तो JWE का उपयोग करें। एक एल्गोरिदम अनुमति-सूची लागू करें, none और एल्गोरिदम स्विचिंग को अस्वीकार करें, और हेडर आकार, नेस्टिंग और कुल बाइट्स को सीमित करें।
JWE के लिए प्राप्तकर्ता कीज विश्वसनीय ऑथराइजेशन-सर्वर पंजीकरण से आती हैं। JWS सत्यापन कीज क्लाइंट पंजीकरण या किसी विश्वसनीय JWKS डायरेक्टरी से आती हैं। डिक्रिप्शन, हस्ताक्षर और क्लेम विफलताएं एक व्यावसायिक त्रुटि सीमा साझा करती हैं ताकि प्रतिक्रियाएं की (key) या अनुरोध के अस्तित्व के विवरण का खुलासा न करें।
3. क्लेम्स और समय सीमाओं को सत्यापित करें
iss, aud, exp और लागू nbf और iat क्लेम्स को सत्यापित करें। exp को छोटा रखें; केवल सीमित क्लॉक स्क्यू (clock skew) की अनुमति दें। ऑडिट और रीप्ले का पता लगाने के लिए jti या समकक्ष अद्वितीय पहचानकर्ता का उपयोग करें, और दूसरे उपयोग को अस्वीकार करें या पुनरुत्पादन की मांग करें।
सर्वर अभी भी सटीक रीडायरेक्ट-यूआरआई मिलान करता है और क्लाइंट के अनुमत प्रतिक्रिया प्रकारों और स्कोप की जांच करता है। एक वैध JAR हस्ताक्षर का मतलब यह नहीं है कि कोई उपयोगकर्ता प्रमाणित है या उसने सहमति दी है; सत्र, सहमति, आश्वासन स्तर और जोखिम निर्णय ऑथराइजेशन-एंडपॉइंट की जिम्मेदारियां बने रहते हैं।
4. बाहरी पैरामीटर्स और अनुरोध स्रोतों का समाधान करें
विशिष्टता के पैरामीटर प्राथमिकता नियम लागू करने से पहले अनुरोध स्रोत को पार्स करें। यदि request और सामान्य क्वेरी पैरामीटर एक साथ दिखाई देते हैं, तो एक अहस्ताक्षरित बाहरी मान संरक्षित JWT क्लेम को ओवरराइड नहीं करना चाहिए। बेमेल, डुप्लिकेट, या छूटे हुए महत्वपूर्ण क्लेम्स invalid_request लौटाते हैं।
PAR के साथ, क्लाइंट Request Object को सीधे ऑथराइजेशन सर्वर पर भेजता है, जो एक अल्पकालिक request_uri लौटाता है। ब्राउज़र तब केवल संदर्भ ले जाता है, जिससे URL लीकेज और लंबाई सीमाएं कम हो जाती हैं। PAR, JAR साइनिंग या एन्क्रिप्शन की जगह नहीं लेता है, और JAR अपने आप संदर्भ लाइफटाइम का प्रबंधन नहीं करता है।
5. रीप्ले, प्रतिस्थापन और संसाधन दुरुपयोग का विरोध करें
TTL स्टोर में एक डिडुप्लीकेशन की के रूप में क्लाइंट आईडी प्लस jti का उपयोग करें; उच्च-जोखिम वाले प्रवाहों के लिए एक बार उपभोग की आवश्यकता हो सकती है। क्रिप्टो और संपीड़न दुरुपयोग को सीमित करने के लिए JWT आकार, नेस्टिंग, डिक्रिप्शन सीपीयू और JWKS रिफ्रेश आवृत्ति को सीमित करें।
Request Object को क्लाइंट और रीडायरेक्ट यूआरआई से बांधें। PKCE, state और OIDC nonce के साथ मिलकर, यह ऑथराइजेशन-कोड अवरोधन, सत्र CSRF और प्रमाणीकरण-प्रतिक्रिया प्रतिस्थापन को संबोधित करता है। पूर्ण JWTs, ट्रांज़ैक्शन फ़ील्ड, या क्लाइंट असर्शन को कभी भी लॉग न करें।
6. की (Key) डायरेक्टरी और रोटेशन डिज़ाइन करें
प्रत्येक क्लाइंट सत्यापन की और प्रत्येक ऑथराइजेशन-सर्वर एन्क्रिप्शन की को एक संस्करण, उद्देश्य और स्थिति दें। JWKS कैश को स्पष्ट TTL की आवश्यकता होती है। रोटेशन के दौरान नई की प्रकाशित करें, जारीकर्ताओं को स्विच करें, सबसे लंबे अनुरोध या टोकन लाइफटाइम तक पुरानी की को बनाए रखें, फिर इसे निरस्त करें।
यदि कोई kid गायब है, तो असीमित बाहरी पुनर्चेष्टाओं के बजाय एक नियंत्रित डायरेक्टरी रिफ्रेश की अनुमति दें। की निरस्तीकरण, डायरेक्टरी आउटेज और एल्गोरिदम बेमेल के लिए मेट्रिक्स और अलर्ट की आवश्यकता होती है; उच्च-जोखिम वाले क्लाइंट फेल क्लोज्ड होते हैं जब सत्यापन पूरा नहीं किया जा सकता है।
7. ऑब्जर्वेबिलिटी, रोलआउट और रोलबैक जोड़ें
एक अनुरोध-ऑब्जेक्ट हैश, क्लाइंट, एल्गोरिदम, सत्यापन परिणाम, हैशेड jti और विलंबता (latency) रिकॉर्ड करें, सिफरटेक्स्ट या पूर्ण टोकन कभी नहीं। हस्ताक्षर और डिक्रिप्शन विफलताओं, क्लेम विरोधों, समाप्ति, डुप्लिकेट jti, JWKS रिफ्रेश और ऑथराइजेशन पूर्णता को ट्रैक करें।
क्लाइंट द्वारा JAR सक्षम करें, पुराने प्रवाह के साथ पूर्णता दर, विलंबता और त्रुटि वितरण की तुलना करें, और की-डायरेक्टरी या संगतता संकेतों में गिरावट आने पर रोलआउट रोकें। रोलबैक को स्पष्ट रूप से अनुमोदित नीति को पुनर्स्थापित करना चाहिए; इसे अहस्ताक्षरित बाहरी पैरामीटर्स को उच्च-जोखिम वाले स्कोप के लिए फ़ॉलबैक में नहीं बदलना चाहिए।
मॉडल उत्तर
मैं JAR को ऑथराइजेशन अनुरोध के लिए अखंडता और गोपनीयता परत के रूप में मानूंगा। क्लाइंट या विश्वसनीय बैकएंड पंजीकरण के अनुसार एक Request Object बनाता है। ऑथराइजेशन सर्वर केवल अनुमति-सूचीबद्ध एल्गोरिदम और विश्वसनीय कीज को स्वीकार करता है, जारीकर्ता, ऑडियंस, क्लाइंट, रीडायरेक्ट यूआरआई, प्रतिक्रिया प्रकार, स्कोप, iat/exp और jti को सत्यापित करता है, और संरक्षित क्लेम्स के साथ विरोध करने वाले अहस्ताक्षरित बाहरी मानों को अस्वीकार करता है। अखंडता और स्रोत प्रमाणीकरण के लिए JWS और गोपनीयता के लिए JWE का उपयोग करें।
ऑब्जेक्ट को एक छोटा लाइफटाइम और क्लाइंट बाइंडिंग दें, TTL के साथ jti को डिडुप्लीकेट करें, और आकार, नेस्टिंग और डिक्रिप्शन संसाधनों को सीमित करें। रोटेशन के दौरान ओवरलैप के साथ संस्करणित JWKS कीज का उपयोग करें। JAR को PAR के साथ संयोजित किया जा सकता है: JAR ऑब्जेक्ट की सुरक्षा करता है, PAR ब्राउज़र पैरामीटर्स को छुपाता है और एक संदर्भ का प्रबंधन करता है, जबकि PKCE, state और nonce अपने अलग कोड और सत्र बाइंडिंग को बनाए रखते हैं।
सत्यापन विफलताओं, रीप्ले, JWKS रिफ्रेश, पूर्णता दर और विलंबता का निरीक्षण करते हुए प्रति क्लाइंट रोल आउट करें। की-डायरेक्टरी विफलताएं या असत्यापनीय उच्च-जोखिम अनुरोध फेल क्लोज्ड होते हैं। रोलबैक एक परिभाषित पुरानी नीति को पुनर्स्थापित करता है और कभी भी अहस्ताक्षरित बाहरी पैरामीटर्स को समकक्ष सुरक्षा के रूप में नहीं मानता है।
सामान्य गलतियां
- जारीकर्ता, ऑडियंस, एल्गोरिदम, समय और रीडायरेक्ट यूआरआई की जांच किए बिना यह कहना कि "JWT हस्ताक्षर सुरक्षित हैं"।
kidयाjkuको मनमानी नेटवर्क की पुनर्प्राप्ति ट्रिगर करने की अनुमति देना, जिससे विश्वास और SSRF जोखिम बढ़ जाता है।- बाहरी क्वेरी मानों को हस्ताक्षरित स्कोप या रीडायरेक्ट यूआरआई को ओवरराइड करने की अनुमति देना।
- अनुरोध, ट्रांसपोर्ट और कोड सुरक्षा के बजाय JAR, PAR और PKCE को एक ही सुविधा के रूप में मानना।
jti, छोटे TTLs, आकार सीमाओं, या क्रिप्टो संसाधन सीमाओं को छोड़ना।- रोटेशन के दौरान पुरानी कीज को तुरंत हटाना और अभी भी वैध अनुरोधों को तोड़ना।
- सत्यापन विफल होने के बाद सामान्य ऑथराइजेशन पर बिना शर्त वापस लौटना (फ़ॉलबैक करना)।
फॉलो-अप प्रश्न और उत्तर
क्लाइंट और ऑथराइजेशन-सर्वर हस्ताक्षर कैसे भिन्न होते हैं?
क्लाइंट हस्ताक्षर सर्वर को अनुरोध स्रोत को प्रमाणित करने और छेड़छाड़ का पता लगाने की अनुमति देता है। एक सर्वर हस्ताक्षर आमतौर पर डाउनस्ट्रीम सर्वर अटेस्टेशन ले जाता है। उनके ट्रस्ट एंकर, की उद्देश्य और रोटेशन ओनर भिन्न होते हैं।
जब JAR हस्ताक्षरित होता है तब भी PKCE की आवश्यकता क्यों होती है?
JAR अनुरोध सामग्री की सुरक्षा करता है; PKCE ऑथराइजेशन कोड को रिडीम करने वाले पक्ष की सुरक्षा करता है। इंटरसेप्ट किए गए ब्राउज़र कॉलबैक को अभी भी सत्यापनकर्ता (verifier) की आवश्यकता होती है।
क्या प्रत्येक पैरामीटर JWT के अंदर होना चाहिए?
उन पैरामीटर्स को Request Object में रखें जिनके लिए अखंडता, स्रोत प्रमाणीकरण या गोपनीयता की आवश्यकता होती है। अनुमत बाहरी पैरामीटर्स के लिए प्राथमिकता परिभाषित करें और विरोधों या छूटे हुए महत्वपूर्ण मानों को अस्वीकार करें।
यदि JWKS अस्थायी रूप से अनुपलब्ध हो तो क्या होगा?
अल्पकालिक कैश और एक नियंत्रित रिफ्रेश का उपयोग करें। यदि कोई विश्वसनीय की उपलब्ध नहीं है, तो उच्च-जोखिम वाले अनुरोधों के लिए फेल क्लोज्ड करें और अलर्ट करें। उपलब्धता के लिए कभी भी अज्ञात की को स्वीकार न करें या सत्यापन को न छोड़ें।
आप उन क्लाइंट्स को कैसे माइग्रेट करते हैं जो केवल सामान्य अनुरोधों का समर्थन करते हैं?
क्लाइंट मेटाडेटा के माध्यम से JAR सक्षम करें, सत्यापन और पूर्णता को मापें, फिर माइग्रेट किए गए क्लाइंट्स के लिए इसे अनिवार्य करें। पुराने प्रवाह के लिए शेष स्कोप, जोखिम सीमाएं और सनसेट (समाप्ति) तिथि स्पष्ट रूप से कॉन्फ़िगर करें।
आप कैसे साबित करते हैं कि संवेदनशील JWTs लॉग से अनुपस्थित हैं?
गेटवे, ऑथराइजेशन सेवा और त्रुटि ट्रैकर पर फ़ील्ड रिडैक्शन लागू करें। केवल ऑब्जेक्ट और jti हैश, क्लाइंट और परिणाम को बनाए रखें; लॉग का नमूना लें और रिग्रेशन चेक चलाएं जो टोकन, सिफरटेक्स्ट और ट्रांज़ैक्शन फ़ील्ड को अस्वीकार करते हैं।