मैजिक लिंक के साथ पासवर्डलेस लॉगिन: UX और सुरक्षा चेकलिस्ट

मैजिक लिंक साइन-इन क्या है, और क्या गलत हो सकता है

मैजिक लिंक आपकी ईमेल पर भेजा गया एक एक-बार उपयोग होने वाला साइन-इन लिंक है। पासवर्ड टाइप करने के बजाय, आप ईमेल खोलते हैं, लिंक पर टैप करते हैं, और लॉग इन हो जाते हैं।

यह उन स्थितियों में अच्छा काम कर सकता है जहाँ लोग पासवर्ड से नफ़रत करते हैं, अक्सर भूल जाते हैं, या केवल कभी-कभार साइन इन करते हैं। इससे साइटों पर पासवर्ड के पुन:उपयोग में भी कमी आती है, क्योंकि पासवर्ड मौजूद ही नहीं रहता। लेकिन इससे सुरक्षा की आवश्यकता खत्म नहीं होती—यह मुख्य "कुंजी" को आपके ईमेल इनबॉक्स में स्थानांतरित कर देता है।

यह वही व्यापार-बंद है जिसे साफ़ बताना ज़रूरी है: मैजिक लिंक के साथ पासवर्डलेस लॉगिन केवल उतना ही सुरक्षित है जितना उपयोगकर्ता का ईमेल खाता और उसकी निजी पहुँच बनाए रखने की क्षमता। अगर कोई आपका ईमेल पढ़ सकता है, तो अक्सर वे आपकी तरह साइन इन कर सकते हैं।

यहाँ वे सबसे सामान्य तरीके हैं जिनसे मैजिक लिंक असल जीवन में गलत हो जाते हैं:

• इनबॉक्स की पहुँच चोरी हो जाती है (फिशिंग से ईमेल पासवर्ड, ईमेल रिकवरी के लिए SIM स्वैप, मैलवेयर, या किसी साझा कंप्यूटर पर साइन इन छोड़ देना)।
• लिंक फॉरवर्ड कर दिया जाता है (जानबूझकर या गलती से) और गलत व्यक्ति इसका उपयोग कर लेता है।
• उपयोगकर्ता ईमेल एक डिवाइस पर खोलता है पर सत्र दूसरे डिवाइस पर चाहिए, और जब ऐप "गलत" जगह पर खुलता है तो भ्रम हो जाता है।
• साझा डिवाइस पर लॉगिन होता है और वह लॉग्‌इन बना रहता है, जिससे अगला व्यक्ति पहुँच पाता है।
• ईमेल पता गलत टाइप किया गया और लॉगिन लिंक किसी और को चला जाता है।

एक छोटा उदाहरण: कोई व्यक्ति वर्क लैपटॉप पर लिंक का अनुरोध करता है, फिर व्यक्तिगत फोन पर ईमेल चेक करता है। वे लिंक पर टैप करते हैं, फोन उन्हें साइन इन कर देता है, और लैपटॉप अभी भी लॉगिन स्क्रीन दिखाता है। अगर आपका फ्लो यह नहीं समझाता कि क्या हुआ, तो सपोर्ट टिकट आएँगे।

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

क्या पासवर्डलेस ईमेल साइन-इन आपके प्रोडक्ट के लिए सही है?

मैजिक लिंक के साथ पासवर्डलेस लॉगिन तब सबसे अच्छा काम करता है जब लक्ष्य कम अवरोध के साथ तेज़ पहुँच हो, न कि अधिकतम सुरक्षा। यह उन प्रोडक्ट्स के लिए उपयुक्त है जहाँ लोग कभी-कभार साइन इन करते हैं और पासवर्ड रीसेट पसंद नहीं करते, और जहाँ ईमेल इनबॉक्स पहले से ही उपयोगकर्ता का “होम बेस” है।

निर्णय लेने का सरल तरीका: अगर कोई गलत खाते में पहुँच जाए तो सबसे खराब यथार्थवादी नुकसान क्या होगा? अगर जवाब है “कष्टप्रद, पर ठीक किया जा सकता है,” तो मैजिक लिंक एक अच्छा डिफ़ॉल्ट हो सकते हैं।

अच्छी फिट अक्सर शामिल होती हैं:

• कम से मध्यम जोखिम वाले ऐप्स (आंतरिक टूल, छोटे टीमों के लिए एडमिन पैनल, सीमित अनुमति वाले कस्टमर पोर्टल)
• ऐसे प्रोडक्ट जहां उपयोगकर्ता दुर्लभ हैं और पासवर्ड रीसेट से नफ़रत करते हैं
• "मुझे जल्दी अंदर ले आओ" अनुभव जैसे सपोर्ट, ऑनबोर्डिंग, या अनुमोदन
• शुरुआती-चरण के प्रोडक्ट जिनको कम सपोर्ट टिकट चाहिए

निम्न परिस्थितियों में सावधानी बरतें या मैजिक लिंक को केवल साइन-इन विधि के रूप में न अपनाएँ:

• खातों का उच्च मूल्य हो (पैसे का लेन-देन, बड़े बैलेंस, अपरिवर्तनीय क्रियाएँ)
• आप संवेदनशील या विनियमित डेटा रखते हैं (स्वास्थ्य, कानूनी, विस्तृत वित्तीय रिकॉर्ड)
• उपयोगकर्ता सामान्यतः ईमेल इनबॉक्स साझा करते हैं (shared mailboxes, फ्रंट-डेस्क खाते)
• आपका ऑडियंस निशाना बना सकता है (एक्सेक्युटिव्स, एडमिन, उच्च-विशेषाधिकार रोल)

यदि आपके प्रोडक्ट में संवेदी पलों (sensitive moments) हैं बजाय संवेदी खातों के, तो एंट्री के लिए ईमेल साइन-इन का उपयोग करें और जोखिम भरे कार्यों के लिए सेकंड फ़ैक्टर या स्टेप-अप चेक जोड़ें। उदाहरण के लिए, पेस्ट डिटेल बदलने, डेटा एक्सपोर्ट करने, या नया एडमिन जोड़ने पर अतिरिक्त पुष्टि माँगें।

यह भी तय करें कि ईमेल को क्या करने की अनुमति होगी। "सिर्फ़ लॉगिन" वाले मैजिक लिंक अधिक सुरक्षित और समझना आसान होते हैं। "लॉगिन + अकाउंट रिकवरी" सुविधाजनक है, लेकिन इसका अर्थ यह है कि किसी भी व्यक्ति के पास जो ईमेल पहुँच है वह अकाउंट पर कब्ज़ा कर सकता है। यदि आप ईमेल पता बदलने का समर्थन करते हैं, तो इसे उच्च-जोखिम क्रिया की तरह संभालें।

यदि आप AppMaster जैसे नो-कोड प्लेटफ़ॉर्म में ऐप बना रहे हैं, तो यह निर्णय फिर भी मायने रखता है: UI सरल हो सकती है, लेकिन संवेदनशील क्रियाओं और रिकवरी के आसपास आपकी नीति पहले दिन से स्पष्ट होनी चाहिए।

बुनियादी मैजिक लिंक फ्लो (और उसके भीतर के निर्णय)

मैजिक लिंक उपयोगकर्ताओं को सरल लगता है, पर नीचे कई छोटे निर्णय होते हैं। एक साफ़ फ्लो लोगों को आगे बढ़ने देता है और सपोर्ट टिकट घटाता है।

उपयोगकर्ताओं को जो दिखता है

ज़्यादातर प्रोडक्ट एक ही रास्ता अपनाते हैं: उपयोगकर्ता ईमेल डालता है, संदेश मिलता है, लिंक पर टैप करता है, और साइन इन होकर लैंड करता है।

एक सामान्य सुधार है लिंक खुलने के बाद एक अंतिम पुष्टि स्टेप दिखाना। तुरंत साइन-इन करने के बजाय, आप एक छोटा स्क्रीन दिखा सकते हैं जैसे “Confirm sign-in to Acme” और एक बटन। यह तब मदद करता है जब कोई लिंक गलत डिवाइस पर टैप कर दे या ईमेल किसी प्रिव्यू टूल से खुला हो।

मोबाइल पर, तय करें कि "लिंक पर टैप करना" का क्या अर्थ है। अगर आपका नेटिव ऐप है, तो सबसे अच्छा अनुभव आमतौर पर होगा: लिंक टैप करें -> ऐप खोलें -> साइन-इन पूरा करें। अगर ऐप इंस्टॉल नहीं है, तो मोबाइल वेब पर फ़ॉलबैक दें और बाद में "Open the app" विकल्प दें।

जिन निर्णयों को आपको लेना होगा

पासवर्डलेस लॉगिन को बनाना शुरू करने से पहले ये नियम तय करें ताकि अनुभव अनुमान्य रहे:

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

पहले से साइन इन होना अक्सर नज़रअंदाज़ हो जाता है। अगर एक लॉग्ड-इन उपयोगकर्ता नया मैजिक लिंक टैप करता है, तो आप (a) उन्हें उसी खाते में रखें और "You are already signed in" दिखाएँ, या (b) इसे अकाउंट स्विच के रूप में ट्रीट कर के पुष्टि माँगें। AppMaster में बने ऐप्स (जैसे कस्टमर पोर्टल या आंतरिक टूल) के लिए विकल्प (a) आमतौर पर सुरक्षित होता है जब तक कि अकाउंट स्विचिंग असली फीचर न हो।

समाप्ति नियम: सुरक्षित बनाने के लिए छोटा, काम करने के लिए पर्याप्त लंबा

मैजिक लिंक तभी "पासवर्डलेस" लगता है जब वह बेझिझक काम करे। समाप्ति वह हिस्सा है जो चुपके से उस वादे को तोड़ सकता है। बहुत छोटा हो तो लोग अपने इनबॉक्स में एक्सपायर लिंक पाते हैं और हार मान लेते हैं। बहुत लंबा हो तो फॉरवर्ड या एक्सपोज़ हुआ ईमेल बड़ा जोखिम बन सकता है।

passwordless login with magic links के लिए एक व्यावहारिक शुरुआती बिंदु है 10 से 30 मिनट के बीच का एक्सपायरी विंडो। उच्च-जोखिम क्रियाओं (जैसे एडमिन एरिया में साइन-इन या पेमेंट अनुमोदन) के लिए 3 से 10 मिनट की छोटी विंडो बेहतर रहती है। कम जोखिम वाले ऐप्स के लिए 30 से 60 मिनट काम कर सकता है, पर तब आपके पास मजबूत सत्र नियंत्रण और अच्छा डिवाइस प्रबंधन होना चाहिए।

ईमेल और "Check your email" स्क्रीन पर समाप्ति स्पष्ट करें। इसे छोटे टेक्स्ट में छिपाएँ नहीं। सरल शब्दावली का उपयोग करें जैसे "यह लिंक 15 मिनट में समाप्त हो जाएगा।" अगर संभव हो तो वेटिंग स्क्रीन पर काउंटडाउन दिखाएँ, पर उपयोगकर्ता के डिवाइस क्लॉक पर भरोसा न करें।

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

• समाप्ति के लिए अपने सर्वर समय का उपयोग करें, उपयोगकर्ता के समय का नहीं।
• अगर लिंक समाप्ति के करीब है तो स्पष्ट संदेश दें जैसे "लिंक एक्सपायर हो गया है। नया लिंक मांगे।"
• अगर लिंक अभी भी वैध है पर पहले से उपयोग हुआ है, तो सीधे बताएं (और एक त्वरित अगले कदम ऑफ़र करें)।

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

एक छोटी खास बात जो सपोर्ट टिकट घटाती है: वेटिंग स्क्रीन पर उस सटीक ईमेल पते को दिखाएँ जिसपर लिंक भेजा गया (आंशिक रूप से मास्क किया हुआ) और साथ में "Change email" विकल्प दें। AppMaster जैसे नो-कोड टूल में यह आमतौर पर कुछ UI स्टेट्स ही होते हैं, पर यह बहुत सारे "मुझे ईमेल नहीं मिला" कन्फ्यूज़न रोकता है।

एक-बार उपयोग और पुन:उपयोग नियम (वो हिस्से जिनसे उपयोगकर्ता वास्तव में टकराते हैं)

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

कुंजी यह तय करना है कि वास्तविक जीवन में "उपयोग किया गया" का अर्थ क्या है। लोग दो बार क्लिक करते हैं, गलत डिवाइस पर खोलते हैं, या ईमेल प्रीव्यू में टैप कर देते हैं। आपके नियम सुरक्षित होने चाहिए, पर साथ ही वे न्यायसंगत महसूस भी होने चाहिए।

एक ही लिंक दो बार खोला जाए तो क्या होना चाहिए?

एक अच्छा बेसलाइन: पहली सफल लॉगिन टोकन को खा जाता है (consume कर देता है), और बाद के किसी भी खोलने पर स्पष्ट संदेश दिखाएँ जैसे "This link was already used. Request a new one." अस्पष्ट त्रुटियों से बचें। अगर आप निराशा कम करना चाहते हैं, तो आप खपत से पहले छोटा सुरक्षा विंडो दे सकते हैं—for example: सत्र बनाने के बाद ही इसे उपयोग किया हुआ marqué करें।

यहाँ उपयोगकर्ता-फ्रेंडली पैटर्न हैं जो सुरक्षित रहते हैं:

• अगर लिंक उसी डिवाइस पर फिर से खोला जाए और उपयोगकर्ता पहले से साइन इन है, तो उन्हें ऐप पर ले जाएँ (और कुछ न दिखाएँ)।
• अगर लिंक फिर से खोला जाए पर कोई सक्रिय सत्र न हो, तो "Used or expired" दिखाएँ और नया लिंक भेजने के लिए एक बटन दें।
• अगर लिंक किसी अलग डिवाइस पर उपयोग के बाद खोला गया है, तो इसे अमान्य मानें और नया लिंक माँगें।

अगर उपयोगकर्ता कई लिंक अनुरोध करते हैं, तो क्या पुराने लिंक बंद हो जाते हैं?

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

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

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

अगर आप अपना ऑथ फ़्लो AppMaster जैसे नो-कोड टूल में बना रहे हैं, तो इन नियमों को सामान्य भाषा स्टेट्स (valid, used, expired, replaced) के रूप में लिखें ताकि आपके UI संदेश वही बोलें जो आपके बैकएंड वास्तव में लागू करता है।

उलझन और सपोर्ट टिकट घटाने वाले UX विवरण

मैजिक लिंक के आसपास के अधिकांश सपोर्ट टिकट सुरक्षा बग नहीं होते। वे होते हैं "मुझे ईमेल नहीं मिला", "मैंने क्लिक किया और कुछ नहीं हुआ", या "क्या यह फिशिंग है?"। अच्छा UX इन तीनों को रोकता है।

उपयोगकर्ता ईमेल सबमिट करने के बाद, एक समर्पित "Check your email" स्क्रीन दिखाएँ न कि एक छोटा टोस्ट। इसे शांत और विशिष्ट रखें: बताएं कि आपने किस पते पर भेजा, अगला कदम क्या है, और अगर यह न पहुँचे तो क्या ट्राई करें।

एक मजबूत चेक-ईमेल स्क्रीन में आमतौर पर शामिल हों:

• प्रयुक्त सटीक ईमेल पता, साथ में स्पष्ट "Change email" विकल्प
• एक रिसेंड बटन जिस पर छोटा काउंटडाउन हो (ताकि उपयोगकर्ता बार-बार क्लिक न करें)
• सामान्य डिलीवरी समय के बारे में नोट (उदाहरण: "आम तौर पर 1 मिनट के भीतर आता है")
• स्पैम, प्रमोशन्स और कंपनी फिल्टर्स चेक करने की विनम्र याद दिलाना
• सुरक्षा के बारे में एक छोटा वाक्य: "इस लिंक को फॉरवर्ड न करें"

विश्वास ईमेल में जीता जाता है। एक सुसंगत भेजने वाले नाम और विषय पंक्ति का प्रयोग करें, और सामग्री को अनुमान्य रखें। उपयोगकर्ताओं को भरोसा दिलाने के लिए एक-दो विवरण जोड़ें जैसे "Requested from Chrome on Windows" या "Requested at 3:42 PM"। डरावना कॉपी न लिखें। सरल बेहतर है: "यह लिंक आपको साइन-इन कराता है। अगर आपने अनुरोध नहीं किया है, तो आप इस ईमेल को नज़रअंदाज़ कर सकते हैं।"

विलंबित या फ़िल्टर हुई ईमेल के सबसे आम फेलियर के लिए भी योजना बनाएं। आपकी UI को डेड-एंड नहीं होना चाहिए। अगर लिंक में समय लग सकता है, तो उपयोगकर्ताओं को बताएं कि प्रतीक्षा के दौरान क्या करना है, और एक दोस्ताना फ़ॉलबैक ऑफ़र करें।

एक व्यवहारिक फ़ॉलबैक है ईमेल में उसी संदेश के साथ एक छोटा वन-टाइम कोड शामिल करना। तब चेक-ईमेल स्क्रीन "कोड दर्ज करें" विकल्प दे सकती है उन मामलों के लिए जहाँ लिंक गलत डिवाइस पर खुलता है या ईमेल सिक्योरिटी स्कैनर द्वारा ब्लॉक हो रहा है।

एक छोटी पर महत्वपूर्ण बात: अगर उपयोगकर्ता किसी पुराने या पहले से उपयोग किए गए लिंक पर क्लिक करता है, तो एक मददगार संदेश और एक स्पष्ट अगला कदम दिखाएँ जैसे "Send me a new link"—ना कि एक सामान्य त्रुटि संदेश।

पीछे की तरफ़ सुरक्षा की बुनियादी बातें (भारी क्रिप्टो टॉक के बिना)

मैजिक लिंक उतना ही सुरक्षित है जितना उसके पीछे का टोकन। उस टोकन को एक अस्थायी अकाउंट-कुंजी की तरह ट्रीट करें: इसे अनुमान लगाना मुश्किल होना चाहिए, अल्पकालिक होना चाहिए, और केवल तय किए गए तरीके से उपयोग होने योग्य होना चाहिए।

अनपेक्षितता से शुरू करें। लंबे, रैंडम टोकन जनरेट करें (ईमेल, समय, या इन्क्रीमेंटल IDs पर आधारित न हों)। जितना हो सके उतना कम स्टोर करें। एक आम पैटर्न है टोकन का हैश्ड वर्शन स्टोर करना (ताकि अगर आपकी डेटाबेस लीक हो जाए तब भी कच्चा लिंक पुन:उपयोग न किया जा सके) और सत्यापित करने के लिए केवल आवश्यक मेटाडेटा रखना।

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

रेट लिमिटिंग शानदार गणित से ज़्यादा मायने रखती है। इसके बिना, अटैकर्स आपकी लॉगिन फ़ॉर्म स्पैम कर सकते हैं, उपयोगकर्ताओं को परेशान कर सकते हैं, और यह जांच सकते हैं कि ईमेल मौजूद है या नहीं।

• प्रति ईमेल और प्रति IP अनुरोधों को सीमित करें (रिसेंड्स सहित)
• ईमेल के बीच छोटा कूलडाउन जोड़ें (उदाहरण: 30-60 सेकंड)
• यह संदेश दिखाएँ कि ईमेल मौजूद है या नहीं—समान संदेश दिखाएँ
• स्पाइक्स पर अलर्ट रखें (कई पतों पर बहुत सारी ईमेल्स)

अंत में, उन इवेंट्स को लॉग करें जिनकी आपको वास्तव में ज़रूरत होगी जब कोई कहे "मैंने यह नहीं किया।" जैसे इवेंट कैप्चर करें: लिंक अनुरोध, ईमेल भेजा गया, लिंक खोला गया, टोकन स्वीकार/असफल (और क्यों), और सत्र बनाया गया। टाइमस्टैम्प, IP, और यूज़र-एजेंट शामिल करें। AppMaster में बने टूल में ये इवेंट आपके लॉगिन बिज़नेस प्रोसेस का हिस्सा बन सकते हैं ताकि सपोर्ट और सुरक्षा के पास साफ़ ट्रेल हो बिना सर्वर इनराल्स खोदने के।

उपयोगकर्ता समझ सकें ऐसे डिवाइस और सत्र प्रबंधन

मैजिक लिंक पासवर्ड हटा देता है, पर उपयोगकर्ता तब भी डिवाइस के संदर्भ में सोचते हैं: "मैंने अपने फोन पर लॉग इन किया" या "मैंने साझा लैपटॉप उपयोग किया"। अगर आप उन्हें सत्र देखने और समाप्त करने का सरल तरीका नहीं देते, तो सपोर्ट टिकट तेज़ी से बढ़ते हैं।

एक निर्णय से शुरू करें: एक खाते में एक साथ कितने सक्रिय सत्र हो सकते हैं। अधिकांश उपभोक्ता उत्पादों के लिए कई सत्र ठीक हैं (फोन + लैपटॉप)। संवेदनशील टूल्स (एडमिन पैनल, फाइनेंस, आंतरिक ऑप्स) के लिए आप इसे कैप कर सकते हैं या नए डिवाइस पर आने पर नया मैजिक लिंक माँग सकते हैं।

एक छोटा "Devices" या "Active sessions" पेज इसे समझना आसान बनाता है। इसे सादा और थोड़ा अपूर्ण रखें बजाय अत्यधिक-सटीक के। एक अच्छा रो आमतौर पर शामिल करता है:

• डिवाइस नाम (या ब्राउज़र और OS अगर आप मॉडल नहीं पता कर सकते)
• मोटा स्थान (शहर या क्षेत्र, पूरा पता नहीं)
• आख़िरी सक्रिय समय
• पहली बार देखा गया समय
• एक छोटा लेबल जैसे "This device" वर्तमान सत्र के लिए

वहाँ से, दो स्पष्ट क्रियाएँ दें। "Log out" केवल उस सत्र को समाप्त करे। "Log out of all devices" सब कुछ समाप्त कर दे, वर्तमान डिवाइस सहित, और हर जगह नए मैजिक लिंक के लिए मजबूर करे।

इन क्रियाओं के बीच तय करें कि खोया या साझा डिवाइस होने पर क्या होगा। सबसे सुरक्षित डिफ़ॉल्ट है: लॉग आउट करने से सभी मौजूदा सत्र और किसी भी अनयूज़्ड मैजिक लिंक को अमान्य कर दिया जाए। उपयोगकर्ताओं को विवरण की ज़रूरत नहीं; उन्हें केवल यह गारंटी चाहिए कि पुराना एक्सेस गया।

यहाँ एक सरल व्यवहार सेट है जिसे उपयोगकर्ता कम ही अजीब पाते हैं:

• नया मैजिक लिंक लॉगिन एक नया सत्र बनाता है
• प्रत्येक सत्र की एक आइडल टाइमआउट होती है (उदाहरण: दिन) और एक हार्ड अधिकतम आयु (उदाहरण: हफ्ते)
• ईमेल बदलने पर "log out of all devices" ट्रिगर होता है
• "Log out of all devices" पेंडिंग साइन-इन लिंक को भी कैंसिल करता है

अगर आप इसे AppMaster में बना रहे हैं, तो आप Data Designer में सत्र मॉडल कर सकते हैं, उन्हें बेसिक वेब/मोबाइल UI में दिखा सकते हैं, और बिज़नेस प्रोसेस में वन-बटन क्रियाएँ जोड़ सकते हैं। उपयोगकर्ता को परिचित "active sessions" व्यू मिल जाता है बिना कि आप इसे सुरक्षा पाठ्यपुस्तक बना दें।

खतरे और किनारे के मामले: फॉरवर्डिंग, साझा ईमेल और टाइपो

मैजिक लिंक सरल लगता है, पर ईमेल गड़बड़ हो सकता है। लोग संदेश फ़ॉरवर्ड करते हैं, इनबॉक्स साझा करते हैं, और पतों को गलत टाइप कर देते हैं। अगर आप सिर्फ़ परफेक्ट केस के लिए डिज़ाइन करेंगे तो आप उलझन वाले लॉकआउट और संभालने में मुश्किल सपोर्ट रिक्वेस्ट पाएँगे।

फॉरवर्डिंग सबसे बड़ा सरप्राइज़ है। मैजिक लिंक के साथ पासवर्डलेस लॉगिन को यह मान लेना चाहिए कि लिंक किसी और द्वारा, किसी अन्य डिवाइस पर, मिनट्स या घंटे बाद खोला जा सकता है। सबसे सुरक्षित बेसलाइन है एक-बार उपयोग + स्पष्ट "this link was already used" संदेश, और नया अनुरोध बटन। अगर आप अतिरिक्त सुरक्षा चाहते हैं, तो क्लिक के बाद नए डिवाइस पर एक हल्का पुष्टि स्टेप दिखाएँ (उदाहरण: "क्या यह आप थे?" और एक त्वरित रद्द विकल्प जो सत्र को रद्द कर दे)।

साझा इनबॉक्स को प्रोडक्ट निर्णय की ज़रूरत होती है, तकनीकी पैच की नहीं। अगर कई लोग वैध रूप से एक ही ईमेल पढ़ते हैं (जैसे support@ या sales@), तो मैजिक लिंक डिफ़ॉल्ट रूप से साझा एक्सेस बन जाते हैं। टीम अकाउंट्स के लिए एक अतिरिक्त स्टेप (जैसे व्यक्तिगत ईमेल पर आमंत्रण) या UI में स्पष्ट करना कि ईमेल पहुँच = अकाउंट पहुँच, पर विचार करें।

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

अलियास भी मायने रखते हैं। तय करें कि आप प्लस-एड्रेसिंग (name+tag@) और प्रोवाइडर अलियास को कैसे ट्रीट करेंगे:

• ईमेल को सटीक स्ट्रिंग के रूप में ट्रीट करें (सरल, कम आश्चर्य)
• या सामान्य पैटर्न को सामान्यीकृत करें (डुप्लिकेट अकाउंट कम, पर उपयोगकर्ताओं का अप्रत्याशित मर्ज होने का जोखिम)

सपोर्ट वह जगह है जहाँ चीजें तेज़ाई से गलत हो सकती हैं। उपयोगकर्ताओं से ईमेल अग्रेषित करने, टोकन पेस्ट करने, या लिंक के स्क्रीनशॉट साझा करने को न माँगें। इसके बजाय सरल इन-प्रोडक्ट क्रियाएँ ऑफ़र करें जैसे "send a new link", "sign out of other devices", और "report this wasn’t me", ताकि सपोर्ट संवेदनशील डेटा को छुए बिना मदद कर सके।

भेजने से पहले त्वरित चेकलिस्ट

पासवर्डलेस लॉगिन के साथ मैजिक लिंक लॉन्च करने से पहले तय करें कि आप अव्यवस्थित असली दुनिया में क्या होने देंगे: धीमी ईमेल डिलीवरी, लोग दो बार लिंक पर टैप करना, और उपयोगकर्ता फोन और लैपटॉप के बीच स्विच करना।

उन नियमों से शुरू करें जो जोखिम और सपोर्ट लोड को नियंत्रित करते हैं। अगर आप इन्हें गलत सेट करेंगे, तो UI आपकी मदद नहीं कर पाएगा।

• एक स्पष्ट एक्सपायरी विंडो सेट करें (अक्सर 10-20 मिनट), और इसे ईमेल और "Check your email" स्क्रीन में दिखाएँ।
• डिफ़ॉल्ट रूप से लिंक को एक-बार उपयोग वाला रखें, और तय करें कि "उपयोग" का मतलब क्या है (क्लिक के बाद, सफल सत्र बनाने के बाद, या पहली बार खुलने के बाद)।
• रिसेंड सीमाएँ और पेसिंग जोड़ें (उदाहरण: छोटा कूलडाउन), साथ ही दोस्ताना संदेश जो समझाएँ कि वे बार-बार "send again" क्यों नहीं दबा सकते।
• जहाँ उपयुक्त हो, प्रति उपयोगकर्ता सक्रिय सत्र सीमित करें, और तय करें कि सीमा पहुँचने पर क्या होगा (नया रखें, पुराना रखें, या पूछें)।
• कई टैप और पुराने लिंक को पूर्वानुमेय तरीके से संभालें: अगर लिंक एक्सपायर या पहले से उपयोग हो चुका है, तो एक साधारण पेज दिखाएँ जिसमें एक प्राथमिक कार्रवाई हो ("Send a new link")।

अगला, उन हिस्सों की जाँच करें जिन्हें उपयोगकर्ता वास्तव में देखते हैं। अधिकांश शिकायतें अस्पष्ट ईमेल और भ्रमित मोबाइल व्यवहार से आती हैं।

• ईमेल सामग्री: पहचाने जाने वाला भेजने वाला नाम, स्पष्ट सब्जेक्ट लाइन, सरल भाषा, और एक छोटी "Didn’t request this?" पंक्ति जो बताती है क्या करना है।
• मोबाइल व्यवहार: पुष्टि करें कि अगर उपयोगकर्ता एक डिवाइस पर ईमेल खोलता है पर दूसरे डिवाइस पर साइन-इन चाहिए तो क्या होगा, और क्या आप अपने ऐप में डीप लिंकिंग सपोर्ट करते हैं।
• कई क्लिक: अगर उपयोगकर्ता दो बार टैप करे, तो डरावनी त्रुटियों से बचें; बताएं कि वे पहले से साइन इन हैं या लिंक अब वैध नहीं है।
• डिवाइस प्रबंधन: एक सरल डिवाइस सूची, "log out this device" विकल्प, और बुनियादी ऑडिट नोट्स (समय, डिवाइस, स्थान अगर उपलब्ध) दें।
• रिकवरी: "मैं अपना ईमेल एक्सेस नहीं कर सकता" के लिए एक योजना रखें (सपोर्ट फ्लो, वैकल्पिक सत्यापन, या सुरक्षित अकाउंट चेंज प्रोसेस)।

अगर आप AppMaster जैसे टूल में बना रहे हैं, तो हर चेकलिस्ट आइटम को एक स्क्रीन और अपनी लॉजिक में एक बिज़नेस रूल के रूप में मैप करें, ताकि व्यवहार वेब और मोबाइल में सुसंगत रहे।

एक यथार्थवादी उदाहरण: नया डिवाइस लॉगिन, एक्सपायर लिंक, और क्लीनअप

Maya सपोर्ट में काम करती हैं। सोमवार सुबह वह नए लैपटॉप पर कस्टमर पोर्टल खोलती हैं। वह अपना वर्क ईमेल भरती हैं और "Send me a sign-in link" पर टैप करती हैं। ईमेल आता है जिसमें मैजिक लिंक है जो 10 मिनट में एक्सपायर होता है।

वह उस पर क्लिक करती हैं, ब्राउज़र खुलता है, और वह पोर्टल के अंदर लैंड करती हैं। बैकग्राउंड में, लिंक को एक बार स्वीकार किया जाता है और फिर उसे उपयोग किया हुआ मार्क कर दिया जाता है। पोर्टल "Maya - Laptop Chrome" के लिए एक नया सत्र बनाता है और उसे 14 दिनों तक साइन इन रखता है जब तक कि वह साइन आउट न करें।

दिन के बाद, Maya अपने फोन से लॉग इन करने की कोशिश करती हैं। वह सुबह का वही ईमेल फिर से उपयोग करती हैं और उसी लिंक पर टैप करती हैं। ऐप स्पष्ट संदेश दिखाता है: "That link was already used. Request a new one." वह नया लिंक मांगती हैं, पर ध्यान भंग हो जाता है। पंद्रह मिनट बाद जब वह फिर टैप करती हैं तो संदेश आता: "This link expired. Send a fresh one." वह फिर अनुरोध करती हैं, तुरंत टैप करती हैं, और फोन सत्र "Maya - iPhone Safari" के रूप में बन जाता है।

शुक्रवार को, Maya एक साझे ऑफिस लैपटॉप पर टीममेट की मदद करती हैं। वह साइन इन करती हैं, काम पूरा करती हैं, फिर "Devices" में जाकर "Sign out of this device" पर टैप करती हैं। जाने से पहले, वह अपने खाते से साझा लैपटॉप सत्र भी हटा देती हैं ताकि वह फिर उपयोग न किया जा सके।

यहाँ वो सरल नियम हैं जिन्हें ऐप ने फॉलो किया:

• लिंक जल्दी (मिनटों में) एक्सपायर होते हैं, पर सत्र लंबे समय तक रह सकते हैं (दिन)
• हर लिंक एक बार काम करता है; उपयोग किए गए या एक्सपायर लिंक को पुन: उपयोग नहीं किया जा सकता
• हर साइन-इन एक नामित डिवाइस सत्र बनाता है जिसे उपयोगकर्ता रिव्यू कर सकता है
• उपयोगकर्ता एक डिवाइस से साइन आउट कर सकते हैं, या ज़रूरत पड़ने पर सभी सत्र रद्द कर सकते हैं

AppMaster में यह फ्लो बनाने के लिए, ऑथेंटिकेशन मॉड्यूल से शुरू करें और ईमेल साइन-इन सक्षम करें। सत्रों को डेटाबेस में स्टोर करें (यूज़र, डिवाइस नाम, बनाया गया समय, आख़िरी उपयोग समय)। लॉगिन ईमेल भेजने के लिए ईमेल मेसेजिंग मॉड्यूल का उपयोग करें, और टोकन स्टेट (unused, unexpired) को वैलिडेट करने के लिए एक छोटा बिज़नेस प्रोसेस बनाएं, फिर सत्र बनाएं या रिवोक करें। अगर आप भारी कस्टम कोड के बिना मैजिक लिंक के साथ पासवर्डलेस लॉगिन बनाना चाहते हैं, तो आप विज़ुअल एडिटर्स में स्क्रीन और लॉजिक क्रिएट कर के अभी ट्राय कर सकते हैं।