प्रॉम्प्ट और संदर्भ
एक SaaS क्लाइंट एक एंटरप्राइज़ IdP, एक पब्लिक IdP और एक पार्टनर ऑथराइजेशन सर्वर के साथ एकीकृत होता है। एक हमलावर क्लाइंट से सर्वर A पर शुरू किए गए अनुरोध को सर्वर B से प्राप्त रिस्पॉन्स के रूप में व्यवहार कराने का प्रयास करता है, जिससे संभावित रूप से गलत टोकन एंडपॉइंट पर कोड भेजा जा सकता है या गलत क्लाइंट कॉन्फ़िगरेशन लागू हो सकता है। इश्यूअर बाइंडिंग, ऑथराइजेशन रिस्पॉन्स, टोकन एक्सचेंज, मेटाडेटा डिस्कवरी, एरर और माइग्रेशन को कवर करते हुए Mix-Up सुरक्षा डिज़ाइन करें।
RFC 9207 iss रिस्पॉन्स पैरामीटर को परिभाषित करता है ताकि एक ऑथराइजेशन सर्वर OAuth ऑथराइजेशन रिस्पॉन्स में अपनी पहचान बता सके। RFC 9700 इश्यूअर पहचान को Mix-Up डिफेंस के रूप में सूचीबद्ध करता है। इसका लक्ष्य केवल state पर निर्भर रहने के बजाय "उपयोगकर्ता वापस आ गया है" को "किस ऑथराइजेशन सर्वर ने इस फ़्लो को पूरा किया" के साथ बाइंड करना है।
इंटरव्यूअर क्या जांच रहा है
- मल्टी-इश्यूअर फ़्लो में कोड, टोकन-एंडपॉइंट और क्लाइंट-कॉन्फ़िगरेशन के भ्रम की पहचान।
- इश्यूअर को state, रीडायरेक्ट URI, PKCE और ऑथराइजेशन अनुरोध रिकॉर्ड से बाइंड करना।
- डिस्कवरी मेटाडेटा, इश्यूअर URLs, TLS, JWKS और टोकन एंडपॉइंट्स के बीच निरंतरता की जांच।
- अनुपलब्ध, अज्ञात, परस्पर विरोधी या जाली
issमानों की सुरक्षित हैंडलिंग। - एक माइग्रेशन योजना जो हमेशा के लिए एक असुरक्षित फ़ॉलबैक रखे बिना पुराने IdPs का समर्थन करती है।
स्पष्टीकरण हेतु प्रश्न
- क्या इश्यूअर सूची स्थिर है, डायनामिक रूप से पंजीकृत है, या प्रति टेनेंट खोजी जाती है?
- क्या क्लाइंट एक शेयर्ड रीडायरेक्ट URI का उपयोग करता है या प्रत्येक इश्यूअर के लिए एक अलग कॉलबैक का उपयोग करता है?
- क्या OIDC समर्थित है, जिसके लिए ID टोकन
iss,audऔर nonce वैलिडेशन की आवश्यकता है? - क्या लीगेसी ऑथराइजेशन सर्वर
issलौटाते हैं, और क्या प्रत्येक एक अलग क्लाइंट कॉन्फ़िगरेशन का उपयोग कर सकता है? - क्या PKCE अनिवार्य है, और क्या टोकन एंडपॉइंट को मूल इश्यूअर कॉन्फ़िगरेशन का उपयोग करना चाहिए?
30-सेकंड का उत्तर
प्रत्येक ऑथराइजेशन सर्वर के लिए एक अपरिवर्तनीय इश्यूअर, डिस्कवरी दस्तावेज़, ऑथराइजेशन एंडपॉइंट, टोकन एंडपॉइंट, JWKS, क्लाइंट ID और रीडायरेक्ट-URI नीति संग्रहीत करें। ऑथराइजेशन की शुरुआत में, state, nonce और PKCE जेनरेट करें और अपेक्षित इश्यूअर को एक अल्पकालिक सर्वर-साइड रिकॉर्ड में सुरक्षित रखें। कॉलबैक को उस अपेक्षित मान के बराबर एक स्वीकृत iss की आवश्यकता होनी चाहिए, फिर केवल रिकॉर्ड किए गए इश्यूअर कॉन्फ़िगरेशन का उपयोग करके कोड को रिडीम करें। अनुपलब्ध, अज्ञात या परस्पर विरोधी मान फ़्लो को रोक देते हैं; क्लाइंट कभी भी अनुमान नहीं लगाता है या चुपचाप स्विच नहीं करता है।
गहराई से उत्तर
1. प्रति इश्यूअर एक विश्वास कॉन्फ़िगरेशन स्थापित करें
स्कीम, होस्ट, पोर्ट और पाथ सहित एक कैनोनिकल इश्यूअर URL को कॉन्फ़िगरेशन की के रूप में उपयोग करें, और इश्यूअर के सटीक नियमों के अनुसार इसकी तुलना करें। ऑथराइजेशन और टोकन एंडपॉइंट्स, JWKS, क्लाइंट क्रेडेंशियल्स, स्वीकृत स्कोप और रीडायरेक्ट URIs को स्टोर करें।
जब डिस्कवरी की अनुमति हो, तो दस्तावेज़ के issuer को कॉन्फ़िगर किए गए मान से बिल्कुल मेल खाने की आवश्यकता होनी चाहिए और इसे HTTPS पर प्राप्त करें। उपयोगकर्ता द्वारा प्रदान किया गया इश्यूअर अनियंत्रित मेटाडेटा या JWKS पुनर्प्राप्ति का कारण नहीं बनना चाहिए।
2. ऑथराइजेशन शुरू करते समय इश्यूअर को बाइंड करें
एक अप्रत्याशित state जेनरेट करें और सर्वर-साइड सत्र या अल्पकालिक स्टोर में state, अपेक्षित इश्यूअर, क्लाइंट-कॉन्फ़िगरेशन संस्करण, रीडायरेक्ट URI, PKCE चैलेंज और निर्माण समय को बनाए रखें। ब्राउज़र केवल एक संदर्भ रखता है, परिवर्तनशील टेनेंट कॉन्फ़िगरेशन नहीं।
ऑथराइजेशन URL को उस इश्यूअर और क्लाइंट के लिए पंजीकृत सटीक रीडायरेक्ट URI का उपयोग करना चाहिए। यदि किसी टेनेंट या IdP को डायनामिक रूप से चुना जाता है, तो उसे सर्वर पर चुनें और रिकॉर्ड करें; कॉलबैक को प्रारंभिक कॉन्फ़िगरेशन को पूर्वव्यापी रूप से नहीं चुनना चाहिए।
3. ऑथराइजेशन रिस्पॉन्स iss को मान्य करें
RFC 9207 iss रिस्पॉन्स पैरामीटर स्वीकृत इश्यूअर सेट में होना चाहिए और state रिकॉर्ड में अपेक्षित इश्यूअर के बराबर होना चाहिए। बिना iss वाला सर्वर केवल एक अलग कॉलबैक, क्लाइंट या विश्वसनीय सीमा के साथ संगतता पथ का उपयोग कर सकता है; एक शेयर्ड कॉलबैक को प्रत्येक इश्यूअर के बीच अनुमान नहीं लगाना चाहिए।
कोड को प्रोसेस करने से पहले state, इश्यूअर, एरर रिस्पॉन्स और रीडायरेक्ट संदर्भ को मान्य करें। अज्ञात, डुप्लिकेट, या एन्कोडिंग और केस वेरिएंट को अस्वीकार करें। एरर पेज एक सामान्य विफलता दिखाते हैं और कभी भी असत्यापित URL को प्रतिबिंबित नहीं करते हैं।
4. टोकन एक्सचेंज को मूल इश्यूअर पर बनाए रखें
टोकन एंडपॉइंट, क्लाइंट प्रमाणीकरण और PKCE सत्यापनकर्ता को state रिकॉर्ड से पढ़ें, कॉलबैक इनपुट से URL को जोड़कर कभी नहीं। यदि टोकन रिस्पॉन्स में कोई इश्यूअर, ID टोकन या पहचान के दावे शामिल हैं, तो उनकी तुलना मूल इश्यूअर और क्लाइंट ID से करें।
PKCE कोड रिडीमर को बाइंड करता है, state ब्राउज़र सत्र को बाइंड करता है, और इश्यूअर ऑथराइजेशन सर्वर को बाइंड करता है। OIDC के लिए ID टोकन इश्यूअर, ऑडियंस, हस्ताक्षर, समय और nonce वैलिडेशन की भी आवश्यकता होती है; केवल कॉलबैक iss पर्याप्त नहीं है।
5. सुरक्षित डिस्कवरी, JWKS और रोटेशन
डिस्कवरी, टोकन एंडपॉइंट और JWKS को एक स्वीकृत इश्यूअर ट्रस्ट सीमा के भीतर रहना चाहिए। नियंत्रित JWKS कैशिंग और की वर्ज़न का उपयोग करें; एक अनुपलब्ध kid एक सीमित रीफ़्रेश को ट्रिगर कर सकता है, कभी भी अनियंत्रित URL एक्सेस नहीं। इश्यूअर कॉन्फ़िगरेशन का वर्ज़न बनाएं ताकि इन-फ़्लाइट state निर्माण के समय रिकॉर्ड किए गए वर्ज़न का उपयोग जारी रखे।
डिस्कवरी विफलता, इश्यूअर बेमेल, TLS विफलता या असत्यापनीय हस्ताक्षर उच्च जोखिम वाले फ़्लो के लिए क्लोज़्ड फ़ेल (fail closed) होते हैं। उपलब्धता के लिए टोकन एंडपॉइंट्स को किसी अन्य इश्यूअर पर स्विच न करें।
6. state के दुरुपयोग और संसाधन की कमी को रोकें
state रिकॉर्ड्स को एक छोटा TTL, वन-टाइम उपयोग और समवर्ती सीमाएं दें। डुप्लिकेट कॉलबैक, अज्ञात या समाप्त हो चुका state, और गलत इश्यूअर फ़्लो को अमान्य कर देते हैं। कॉलबैक पैरामीटर सीमित करें और असामान्य JWTs, URLs या लंबे एरर विवरणों को लॉग करने से बचें।
अनुपलब्ध और परस्पर विरोधी इश्यूअर्स, अज्ञात इश्यूअर्स, state रीप्ले, डिस्कवरी विफलताओं, JWKS रीफ़्रेश, PKCE विफलताओं और इश्यूअर द्वारा पूर्णता को ट्रैक करें। हमलों से कॉन्फ़िगरेशन गलतियों को अलग करने के लिए अलर्ट्स को टेनेंट और इश्यूअर द्वारा समूहीकृत करें।
7. लीगेसी ऑथराइजेशन सर्वरों को माइग्रेट करें
इश्यूअर्स और कॉलबैक क्षमताओं की सूची बनाएं, फिर संगत सर्वरों के लिए RFC 9207 लागू करें। लीगेसी सर्वर स्पष्ट बाइंडिंग, समाप्ति तिथि और ऑडिट के साथ अलग रीडायरेक्ट URIs, अलग क्लाइंट या सर्वर-साइड प्रॉक्सी का उपयोग कर सकते हैं। किसी ऐसे शेयर्ड कॉलबैक को अनिश्चित काल तक न रखें जो कोड से इश्यूअर का अनुमान लगाता हो।
रोलआउट के दौरान पूर्णता, एरर, कॉलबैक विलंबता और इश्यूअर संघर्षों की तुलना करें। संकेत बिगड़ने पर नए-टेनेंट रोलआउट को रोकें। state रिकॉर्ड और एक रोलबैक स्विच बनाए रखें, लेकिन कभी भी PKCE को अक्षम न करें या अनबाउंड टोकन एंडपॉइंट को फिर से न खोलें।
मॉडल उत्तर
प्रत्येक ऑथराइजेशन सर्वर के लिए मैं एक निश्चित इश्यूअर, डिस्कवरी दस्तावेज़, ऑथराइजेशन एंडपॉइंट, टोकन एंडपॉइंट, JWKS, क्लाइंट और रीडायरेक्ट-URI नीति बनाए रखूंगा। ऑथराइजेशन की शुरुआत state, nonce और PKCE बनाती है और अपेक्षित इश्यूअर और कॉन्फ़िगरेशन वर्ज़न को सर्वर-साइड स्टोर करती है। कॉलबैक state और RFC 9207 iss को मान्य करता है, जिसके लिए अपेक्षित इश्यूअर के बराबर एक स्वीकृत मान की आवश्यकता होती है; टोकन एक्सचेंज फिर केवल रिकॉर्ड किए गए एंडपॉइंट और क्लाइंट क्रेडेंशियल्स का उपयोग करता है।
डिस्कवरी इश्यूअर, OIDC ID टोकन इश्यूअर, ऑडियंस, हस्ताक्षर और nonce की फिर से जांच की जाती है। अनुपलब्ध या परस्पर विरोधी इश्यूअर, समाप्त या दोहराया गया state, और JWKS विफलताएं चुपचाप स्विच करने के बजाय फ़्लो को रोक देती हैं। लीगेसी IdPs अलग कॉलबैक या एक समय सीमा के साथ प्रॉक्सी का उपयोग करते हैं। इश्यूअर संघर्ष, state रीप्ले, PKCE विफलताओं और इश्यूअर द्वारा पूर्णता की निगरानी करें।
सामान्य गलतियां
- केवल state की जांच करना और यह मान लेना कि यह ऑथराइजेशन सर्वर की पहचान करता है।
- कॉलबैक इश्यूअर इनपुट से सीधे टोकन या JWKS URLs बनाना।
- प्रत्येक IdP को आज़माकर अनुपलब्ध या अज्ञात
issमानों को जारी रहने देना। - डिस्कवरी इश्यूअर, ID टोकन इश्यूअर और टोकन एंडपॉइंट के बीच क्रॉस-चेक छोड़ना।
- माइग्रेशन के दौरान शेयर्ड कॉलबैक और कोड-आधारित इश्यूअर अनुमान को अनिश्चित काल तक बनाए रखना।
- PKCE, state, nonce और इश्यूअर बाइंडिंग को एक नियंत्रण के रूप में वर्णित करना।
- लॉग या पेजों में असत्यापित इश्यूअर्स, JWTs या एरर URLs लिखना।
फॉलो-अप प्रश्न और उत्तर
केवल state ही Mix-Up को क्यों नहीं रोक सकता?
State एक ब्राउज़र सत्र और कॉलबैक को बाइंड करता है, लेकिन यदि क्लाइंट को रिस्पॉन्स इश्यूअर का पता नहीं है, तो वह अभी भी एक वैध-state कोड को गलत टोकन एंडपॉइंट पर भेज सकता है। इश्यूअर बाइंडिंग वह सर्वर पहचान प्रदान करती है।
क्या कॉलबैक में iss न होने पर भी फ़्लो जारी रह सकता है?
केवल स्पष्ट रूप से अलग संगतता नीति के तहत, जैसे कि प्रति लीगेसी सर्वर एक अलग कॉलबैक या प्रॉक्सी। एक शेयर्ड कॉलबैक को सभी इश्यूअर्स पर पुनरावृति करके अनुमान नहीं लगाना चाहिए।
क्या कोई उपयोगकर्ता इश्यूअर URL दर्ज कर सकता है?
चयन केवल एक स्वीकृत इश्यूअर से मैप होना चाहिए। सर्वर को मनमाने इनपुट के लिए डिस्कवरी या JWKS प्राप्त नहीं करना चाहिए, जो SSRF, फ़िशिंग और ट्रस्ट-रूट जोखिम पैदा करेगा।
आप टेनेंट कॉन्फ़िगरेशन मिक्स-अप को कैसे रोकते हैं?
State रिकॉर्ड में टेनेंट, इश्यूअर, कॉन्फ़िगरेशन वर्ज़न और रीडायरेक्ट URI शामिल होते हैं। कॉलबैक और टोकन एक्सचेंज केवल उस रिकॉर्ड को पढ़ते हैं। कॉन्फ़िगरेशन अपडेट इसके TTL के दौरान इन-फ़्लाइट state को अधिलेखित नहीं करते हैं।
OIDC के लिए और क्या आवश्यक है?
कॉलबैक iss के अलावा ID टोकन हस्ताक्षर, इश्यूअर, ऑडियंस, समाप्ति, जारी करने का समय, nonce और आवश्यक प्रमाणीकरण संदर्भ को मान्य करें। कॉलबैक पैरामीटर ID टोकन वैलिडेशन को प्रतिस्थापित नहीं कर सकते।
आप कैसे साबित करते हैं कि माइग्रेशन ने सुरक्षा को कमजोर नहीं किया?
प्रति इश्यूअर लागू नीति, सक्रियण समय और कॉलबैक प्रकार रिकॉर्ड करें। अनुपलब्ध और जाली इश्यूअर्स, क्रॉस-टेनेंट state, एंडपॉइंट प्रतिस्थापन और दोहराए गए कॉलबैक का परीक्षण करें, और फ़ॉलबैक हिट्स की निगरानी करें ताकि वे शून्य रहें या एक स्वीकृत अपवाद के भीतर रहें।