लॉगिन निर्भरता पर भरोसा करने या उसे हटाने से पहले उसे मैप करें

प्रमाणीकरण (ऑथेंटिकेशन) को वैकल्पिक डेटा एक्सेस से अलग रखें

फ़ेडरेटेड साइन-इन एक पहचान प्रदाता को किसी निर्भर ऐप पर पहचान या प्रमाणीकरण दावा भेजने की अनुमति देता है। NIST SP 800-63C इन्हें फ़ेडरेशन में अलग-अलग भूमिकाओं के रूप में वर्णित करता है। ऐप को खाता स्थापित करने के लिए आवश्यक एक स्थिर पहचानकर्ता और चयनित विशेषताएँ प्राप्त हो सकती हैं। एक आसन्न सहमति स्क्रीन अन्य डेटा तक पहुंचने के लिए प्राधिकरण (ऑथराइजेशन) का अनुरोध भी कर सकती है, लेकिन प्राधिकरण और प्रमाणीकरण एक दूसरे के स्थान पर उपयोग नहीं किए जा सकते। RFC 9700 OAuth ऑथराइजेशन फ्लो, क्लाइंट्स, रीडायरेक्ट्स और टोकन के आसपास की सुरक्षा से संबंधित है। उपभोक्ता ऑडिट के लिए, साइन-इन पहचान, बुनियादी विशेषताओं, वैकल्पिक डेटा अनुमतियों, खाता लिंकिंग और ऐप सत्रों के लिए अलग-अलग पंक्तियों को रिकॉर्ड करें। यह निष्कर्ष न निकालें कि लॉगिन बटन हर अनुमति प्रदान करता है, या कि एक अनुमति रद्द करने से लॉगिन संबंध समाप्त हो जाता है।

पहचानकर्ता और डुप्लिकेट-खाता सीमा की जाँच करें

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

निर्भरता त्रिकोण और रिकवरी श्रृंखला का ऑडिट करें

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

डिस्कनेक्ट-पूर्व मैट्रिक्स का उपयोग करें

किसी कनेक्शन को हटाने से पहले, पाँच पंक्तियाँ भरें: सत्यापित वैकल्पिक साइन-इन, वर्तमान प्रदाता पहचानकर्ता, वैकल्पिक डेटा अनुमतियाँ, सक्रिय ऐप सत्र, और ऐप-स्वामित्व वाला डेटा या सदस्यता (सब्सक्रिप्शन)। Google की वर्तमान सहायता Sign in with Google, लिंक्ड खातों और Google खाता डेटा के एक्सेस में अंतर करती है, और बताती है कि कनेक्शन हटाने से अन्य सेवा द्वारा पहले से रखे गए डेटा को नहीं हटाया जाता है। Apple भी इसी तरह उपयोगकर्ताओं को Sign in with Apple का उपयोग करने वाले ऐप्स का निरीक्षण करने और उस कनेक्शन का उपयोग बंद करने की अनुमति देता है, जबकि बाद में ऐप का एक्सेस ऐप पर निर्भर करता है। इसलिए, प्रदाता के डिस्कनेक्ट बटन को कंपैनियन ऐप के डिलीशन, निर्यात, सदस्यता या सत्र नियंत्रण के विकल्प के रूप में उपयोग न करें। केवल सेटिंग के नाम और तारीखें दर्ज करें, टोकन, कोड या निजी सामग्री नहीं।

पुनर्प्राप्त करने योग्य क्रम में डिस्कनेक्ट करें और परिणाम सत्यापित करें

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

सार्वभौमिक विजेता के आधार पर नहीं, बल्कि नियंत्रण के स्वामित्व के आधार पर चुनें

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

इस विषय को आगे पढ़ें