प्रॉम्प्ट और संदर्भ
आप एक बहुभाषी साइट के लिए एंटरप्राइज़ साइन-इन एंट्री पॉइंट के ओनर हैं। प्रोडक्ट टीम चाहती है कि उपयोगकर्ता द्वारा स्पष्ट विकल्प चुनने के बाद ही ब्राउज़र आइडेंटिटी-प्रोवाइडर अकाउंट प्रस्तुत करे, जबकि प्राइवेसी आवश्यकताएं ट्रैकिंग के लिए थर्ड-पार्टी कुकीज़ पर निर्भर रहने से रोकती हैं। रिलाइंग पार्टी (RP), आइडेंटिटी प्रोवाइडर (IdP) और सर्वर के बीच सहयोग को डिज़ाइन करें, जिसमें असमर्थित ब्राउज़र, उपयोगकर्ता अस्वीकृति, एकाधिक IdP, सेशन निर्माण और साइन-आउट शामिल हैं।
इंटरव्यूअर क्या जांच रहा है
एक मजबूत उत्तर FedCM को ब्राउज़र-मध्यस्थता वाले आइडेंटिटी-फेडरेशन इंटरफ़ेस के रूप में मानता है, न कि टोकन वैलिडेशन के प्रतिस्थापन के रूप में। RP navigator.credentials.get() के साथ आइडेंटिटी का अनुरोध करता है, ब्राउज़र अकाउंट विकल्प प्रस्तुत करता है, और IdP एक अल्पकालिक (short-lived) असर्शन या ऑथराइजेशन परिणाम लौटाता है। सर्वर लोकल सेशन बनाने से पहले सिग्नेचर, issuer, audience, nonce और state को सत्यापित करता है। उत्तर में थर्ड-पार्टी-कुकी सीमाओं, परमिशन पॉलिसी, उपयोगकर्ता की पसंद और पारंपरिक OAuth/OIDC रीडायरेक्ट फॉलबैक को भी अलग किया जाना चाहिए।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
प्रोटोकॉल और ट्रस्ट मॉडल
पुष्टि करें कि क्या IdP OAuth, OIDC या कस्टम असर्शन का उपयोग करता है, क्या एकाधिक IdP की अनुमति है, और सर्वर JWKS, issuer और audience कॉन्फ़िगरेशन को कैसे प्रबंधित करता है। FedCM IdP सीमा पर की-रोटेशन या टोकन वैलिडेशन की जगह नहीं लेता है।
ब्राउज़र और प्राइवेसी आवश्यकताएं
लक्षित ब्राउज़र, एम्बेडेड iframe, एंटरप्राइज़ नीतियां और वर्तमान थर्ड-पार्टी-कुकी स्थिति की पुष्टि करें। FedCM सपोर्ट और UI व्यवहार ब्राउज़र पर निर्भर हैं; Chrome के व्यवहार को हर जगह नहीं माना जा सकता है।
अकाउंट लिंकिंग और लॉगआउट नीति
पुष्टि करें कि क्या एक बाहरी subject को एक स्थानीय खाते से मैप किया जा सकता है, डुप्लिकेट ईमेल पतों को कैसे संभाला जाता है, क्या ग्लोबल लॉगआउट को IdP को सूचित करना चाहिए, और क्या अस्वीकृत अनुरोध पासवर्ड या ईमेल साइन-इन पर वापस आ सकता है।
30-सेकंड का उत्तर ढांचा
"मैं FedCM को ब्राउज़र-नियंत्रित आइडेंटिटी-च्वाइस लेयर के रूप में मानता हूँ। RP अपने सर्वर से वन-टाइम state प्राप्त करता है, फिर navigator.credentials.get() को कॉल करता है। ब्राउज़र एक IdP अकाउंट चयनकर्ता प्रस्तुत करता है, और IdP एक प्रोटोकॉल-बाउंड आइडेंटिटी परिणाम लौटाता है। सर्वर साइट सेशन बनाने से पहले issuer, सिग्नेचर, audience, nonce, state और अकाउंट मैपिंग को सत्यापित करता है। असमर्थित ब्राउज़र, परमिशन ब्लॉक, रद्दीकरण और सर्वर अस्वीकृति अलग-अलग स्थितियां हैं। फॉलबैक CSRF सुरक्षा और PKCE के साथ OAuth/OIDC है। साइन-आउट को साइट सेशन को IdP सेशन से अलग करना चाहिए; एक कुकी को साफ़ करना ग्लोबल लॉगआउट नहीं है।"
चरण-दर-चरण गहन उत्तर
चरण 1: RP और IdPs को कॉन्फ़िगर करें
सर्वर प्रत्येक विश्वसनीय IdP के लिए issuer, क्लाइंट ID, JWKS एंडपॉइंट, अनुमत प्रोटोकॉल और कॉलबैक नीति संग्रहीत करता है। फ़्रंटएंड केवल सर्वर-स्वीकृत कॉन्फ़िगरेशन पहचानकर्ता प्राप्त करता है और उपयोगकर्ता से कभी भी मनमाना IdP URL स्वीकार नहीं करता है। मल्टी-टेनेंट परिनियोजन के लिए, ओपन रीडायरेक्ट या क्रॉस-टेनेंट टोकन वितरण को रोकने के लिए प्रत्येक टेनेंट को एक अनुमति सूची (allowlist) बाइंड करें।
चरण 2: वन-टाइम लॉगिन स्टेट बनाएं
उपयोगकर्ता द्वारा साइन-इन शुरू करने के बाद, RP सर्वर अप्रत्याशित state, nonce और ब्राउज़र सेशन, टेनेंट और रिटर्न पाथ से बंधा एक अल्पकालिक फ़्लो रिकॉर्ड बनाता है। फ़्रंटएंड FedCM को सर्वर-प्रदत्त पैरामीटर भेजता है। State और nonce सर्वर-स्वामित्व वाले, एकल-उपयोग मान बने रहते हैं; फ़्रंटएंड को उन्हें बनाना या पुन: उपयोग नहीं करना चाहिए।
चरण 3: ब्राउज़र-मध्यस्थता अनुरोध करें
फ़्रंटएंड एक सुरक्षित संदर्भ में और आवश्यक परमिशन पॉलिसी के तहत navigator.credentials.get() को कॉल करता है। ब्राउज़र एक अकाउंट चयनकर्ता प्रस्तुत करता है और केवल स्पष्ट उपयोगकर्ता चयन के बाद ही जारी रहता है। FedCM अनुरोधों में एक समर्पित फ़ेच डेस्टिनेशन होता है ताकि सर्वर आइडेंटिटी फ़्लो की पहचान कर सके; फ़्रंटएंड को UI के दिखने को प्रमाणीकरण की सफलता नहीं मानना चाहिए।
चरण 4: सर्वर पर आइडेंटिटी परिणाम को सत्यापित करें
सर्वर issuer, सिग्नेचर, समाप्ति, audience, nonce, state और subject की जांच करता है, फिर एक स्पष्ट नीति का उपयोग करके बाहरी आइडेंटिटी को मैप करता है। ईमेल एक सहायक विशेषता है, स्वचालित खाता-मर्ज कुंजी नहीं। सत्यापन के बाद ही सर्वर साइट सेशन जारी करता है और IdP, subject, प्रमाणीकरण समय और प्रासंगिक जोखिम संकेतों को रिकॉर्ड करता है।
चरण 5: फॉलबैक और विफलता स्थितियों को डिज़ाइन करें
असमर्थित ब्राउज़र, परमिशन ब्लॉक, उपयोगकर्ता रद्दीकरण और नेटवर्क विफलताओं को अलग से संभालने की आवश्यकता है। एक OAuth/OIDC रीडायरेक्ट फॉलबैक PKCE, सटीक रीडायरेक्ट URI, state और nonce का उपयोग करता है; यह उसी सर्वर-साइड अकाउंट-मैपिंग लेयर के माध्यम से वापस आता है। UI जारीकर्ताओं, टोकन या आंतरिक सत्यापन त्रुटियों को उजागर किए बिना अगली कार्रवाई की व्याख्या करता है।
चरण 6: एकाधिक IdPs और अकाउंट लिंकिंग को संभालें
जब कई IdP की अनुमति होती है, तो पेज एक व्यवसाय-स्वीकृत सूची प्रस्तुत करता है और ब्राउज़र तथा IdP खाता चयन पूरा करते हैं। सर्वर (issuer, subject) को स्थिर बाहरी कुंजी के रूप में उपयोग करता है और कभी भी केवल ईमेल द्वारा चुपचाप मर्ज नहीं करता है। IdP जोड़ने के लिए एक प्रमाणित सेशन या स्टेप-अप सत्यापन की आवश्यकता होती है और यह एक ऑडिट योग्य लिंक या अनलिंक इवेंट उत्पन्न करता है।
चरण 7: लॉगआउट, निरस्तीकरण (revocation), और क्रमिक रोलआउट
साइट लॉगआउट स्थानीय सेशन को रद्द करता है, सुरक्षित कुकीज़ को साफ़ करता है, और रिफ्रेश टोकन को अमान्य करता है; यदि प्रोटोकॉल और IdP इसका समर्थन करते हैं, तो क्लाइंट IdP लॉगआउट को भी इनवोक कर सकता है। हो सकता है कि FedCM हर कुकी-निर्भर लॉगआउट क्षमता को कवर न करे, इसलिए साइट से साइन आउट करने और प्रोवाइडर से साइन आउट करने के बीच के अंतर को स्पष्ट करें। एक ऑब्ज़र्वेबल फॉलबैक स्विच के साथ ब्राउज़र क्षमता और त्रुटि दर द्वारा क्रमिक रूप से रोल आउट करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं ब्राउज़र आइडेंटिटी च्वाइस, IdP प्रूफ़ और RP सेशन निर्माण को अलग रखूंगा। RP सर्वर अल्पकालिक state, nonce और टेनेंट-बाउंड फ़्लो डेटा बनाता है। फ़्रंटएंड एक सुरक्षित संदर्भ में FedCM शुरू करता है; ब्राउज़र अकाउंट चयनकर्ता दिखाता है, और IdP उपयोगकर्ता की पुष्टि के बाद एक परिणाम लौटाता है। सर्वर जारीकर्ता के JWKS सिग्नेचर, audience, nonce, state, समाप्ति और subject को सत्यापित करता है, फिर साइट सेशन बनाने से पहले (issuer, subject) को एक स्थानीय खाते से मैप करता है।
असमर्थित ब्राउज़र, नीति ब्लॉक, रद्दीकरण और नेटवर्क विफलताएं अलग स्थिति बनी रहती हैं और PKCE के साथ OAuth/OIDC पर वापस आ जाती हैं। फॉलबैक समान सर्वर सत्यापन और लिंकिंग नीति रखता है। एकाधिक IdP केवल सर्वर अनुमति सूची से आते हैं, और ईमेल स्वचालित मर्ज कुंजी नहीं है। लॉगआउट साइट सेशन को रद्द करता है; प्रोवाइडर लॉगआउट एक अलग क्षमता है जिसे उपयोगकर्ता को समझाया जाता है। रोलआउट के दौरान मैं ब्राउज़र और IdP द्वारा सफलता, रद्दीकरण, फॉलबैक और अकाउंट-लिंक संघर्षों की निगरानी करूंगा, एक ऐसे स्विच के साथ जो त्रुटियां बढ़ने पर केवल FedCM एंट्री पॉइंट को अक्षम करता है।
सामान्य गलतियाँ
- गलती: FedCM परिणाम को प्रमाणित सेशन के रूप में मानना। → यह क्यों विफल होता है: ब्राउज़र-मध्यस्थता वाला विकल्प issuer, सिग्नेचर या nonce को सत्यापित नहीं करता है। → सुधार: प्रत्येक परिणाम को एक सर्वर सत्यापन और सेशन-निर्माण पथ के माध्यम से भेजें।
- गलती: किसी मौजूदा खाते का केवल ईमेल द्वारा मिलान करना। → यह क्यों विफल होता है: ईमेल असत्यापित हो सकता है, पुनर्नवीनीकरण (recycled) किया गया हो सकता है, या IdPs में डुप्लिकेट हो सकता है। → सुधार: बाहरी कुंजी के रूप में
(issuer, subject)का उपयोग करें और ईमेल-आधारित लिंकिंग के लिए स्पष्ट पुष्टि की आवश्यकता रखें। - गलती: FedCM विफल होने के बाद फ़्रंटएंड स्टोरेज में टोकन संग्रहीत करना। → यह क्यों विफल होता है: यह XSS जोखिम को बढ़ाता है और मौजूदा सेशन नीति को बायपास करता है। → सुधार: सर्वर को परिणाम का आदान-प्रदान करने दें और एक संरक्षित सेशन कुकी सेट करने दें; फ़्रंटएंड केवल स्थिति को संभालता है।
- गलती: यह मान लेना कि साइट लॉगआउट उपयोगकर्ता को IdP से लॉग आउट कर देता है। → यह क्यों विफल होता है: सेशन के अलग-अलग जीवनचक्र और प्रोटोकॉल क्षमताएं होती हैं। → सुधार: प्रत्येक सेशन को अलग से रद्द करें और लॉगआउट के दायरे के बारे में बताएं।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: FedCM एक सामान्य OAuth रीडायरेक्ट से कैसे संबंधित है?
FedCM बदलता है कि ब्राउज़र अकाउंट च्वाइस और क्रॉस-साइट इंटरैक्शन की मध्यस्थता कैसे करता है; OAuth/OIDC अभी भी ऑथराइजेशन और आइडेंटिटी प्रूफ़ प्रदान करते हैं। वे issuer, nonce, state, PKCE और सर्वर-साइड अकाउंट मैपिंग साझा कर सकते हैं। फ़ॉलबैक को उन जांचों को नहीं हटाना चाहिए।
फॉलो-अप 2: थर्ड-पार्टी-कुकी प्रतिबंध फेडरेशन को क्यों प्रभावित करते हैं?
एक एम्बेडेड IdP पहले साइन-इन किए गए उपयोगकर्ता को पहचानने के लिए थर्ड-पार्टी कुकी का उपयोग कर सकता था। पार्टिशन्ड या ब्लॉक की गई कुकीज़ के लिए इसके बजाय एक स्पष्ट, उपयोगकर्ता-दृश्यमान विकल्प की आवश्यकता होती है। FedCM अंतर्निहित क्रॉस-साइट पहचान को कम करता है लेकिन एप्लिकेशन अनुमतियों का निर्णय नहीं करता है।
फॉलो-अप 3: क्या अस्वीकृत IdP को चुपचाप दूसरे से बदला जा सकता है?
अस्वीकृति को मूक सहमति के रूप में न लें। एक अन्य अनुमोदित IdP या पासवर्ड प्रविष्टि को एक स्पष्ट उपयोगकर्ता कार्रवाई के रूप में प्रस्तुत करें, और पूर्ण किए गए अनुरोध का पुन: उपयोग करने के बजाय चयनित प्रोवाइडर के लिए नया state, nonce और फ़्लो डेटा बनाएं।
फॉलो-अप 4: आप कैसे साबित करते हैं कि क्रमिक रोलआउट से साइन-इन को नुकसान नहीं पहुंचा?
ब्राउज़र, IdP, क्षेत्र और एम्बेडिंग संदर्भ द्वारा सफलता, रद्दीकरण, नीति-ब्लॉक, फॉलबैक, खाता-संघर्ष और पूर्णता-समय मेट्रिक्स को विभाजित करें। जारीकर्ता विसंगतियों, सिग्नेचर विफलताओं और nonce रीप्ले पर अलर्ट करें। एक सर्वर स्विच रखें जो स्थापित OAuth सत्यापन पथ को बरकरार रखते हुए केवल FedCM को अक्षम करता है।