वेब ऐप्स के लिए सत्र प्रबंधन: कुकीज़ बनाम JWTs बनाम रिफ्रेश

सत्र प्रबंधन असल में क्या कर रहा है

एक सत्र यह बताता है कि किसी ने लॉग इन करने के बाद आपकी ऐप इस सवाल का जवाब कैसे देती है: "अभी आप कौन हैं?" जब यह जवाब भरोसेमंद हो जाता है, तो ऐप तय कर सकती है कि उपयोगकर्ता क्या देख सकता है, क्या बदल सकता है, और किन कार्रवाईयों को रोका जाना चाहिए।

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

ज्यादातर वेब ऐप सेटअप तीन बिल्डिंग ब्लॉकों पर निर्भर करते हैं:

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

ये प्रतिस्पर्धी "स्टाइल" नहीं हैं जितना कि एक ही ट्रेड-ऑफ को संभालने के अलग तरीके: गति बनाम नियंत्रण, सादगी बनाम लचीलापन, और "क्या हम इसे अभी निरस्त कर सकते हैं?" बनाम "क्या यह अपने आप एक्सपायर हो जाएगा?"

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

किसी एक विकल्प की सार्वभौमिक जीत नहीं है। सही तरीका आपके थ्रेट मॉडल, लॉगआउट की सख्ती, और आपकी टीम कितनी जटिलता संभाल सकती है, पर निर्भर करता है।

वे थ्रेट मॉडल जो सही जवाब बदलते हैं

अच्छा सत्र डिज़ाइन इस बात पर कम निर्भर करता है कि "सबसे अच्छा" टोकन प्रकार क्या है और अधिक इस पर कि कौन से हमलों से आपको बचना है।

अगर कोई अटैकर ब्राउज़र स्टोरेज (जैसे localStorage) से डेटा चुरा लेता है, तो JWT एक्सेस टोकन आसानी से पकड़े जा सकते हैं क्योंकि पेज का JavaScript उन्हें पढ़ सकता है। एक चुराई गई कुकी अलग होती है: अगर वह HttpOnly के रूप में सेट है, तो सामान्य पेज कोड इसे पढ़ नहीं सकता, इसलिए सरल "टोकन ग्रैब" हमले कठिन हो जाते हैं। लेकिन अगर अटैकर के पास डिवाइस है (खोया लैपटॉप, मैलवेयर, साझा कंप्यूटर), तो ब्राउज़र प्रोफ़ाइल से कुकी अभी भी कॉपी की जा सकती है।

XSS (आपके पेज पर अटैकर कोड चलना) सब कुछ बदल देता है। XSS के साथ, अटैकर को शायद कुछ भी चुराने की ज़रूरत नहीं है — वे पीड़ित के पहले से-लॉग-इन सत्र का उपयोग करके कार्रवाई कर सकते हैं। HttpOnly कुकीज़ सत्र रहस्यों को पढ़ने से रोकती हैं, लेकिन वे पेज से अनुरोध करने से अटैकर को नहीं रोकतीं।

CSRF (एक अलग साइट द्वारा अनचाहे क्रियाएँ ट्रिगर करना) मुख्य रूप से कुकी-आधारित सत्रों को खतरा देता है, क्योंकि ब्राउज़र कुकीज़ अपने आप जोड़ देता है। अगर आप कुकीज़ पर निर्भर हैं तो आपको साफ CSRF बचाव चाहिए: सावधानीपूर्वक SameSite सेटिंग्स, एंटी-CSRF टोकन, और स्टेट-चेंजिंग अनुरोधों का सावधान हैंडलिंग। JWTs जिन्हें Authorization हेडर में भेजा जाता है वे क्लासिक CSRF से कम प्रभावित होते हैं, पर यदि वे JavaScript-से पढ़ने योग्य जगह पर संग्रहीत हैं तो वे XSS के लिए उजागर रहते हैं।

रीप्ले अटैक (चुराए गए प्रमाण का फिर से उपयोग) में सर्वर-साइड सत्र आगे बढ़कर बेहतर होते हैं: आप सत्र ID तुरंत अमान्य कर सकते हैं। शॉर्ट-लाइव्ड JWTs रीप्ले समय कम करते हैं, लेकिन वे टोकन वैध रहने तक रीप्ले को नहीं रोकते।

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

कुकी सत्र: वे कैसे काम करते हैं और क्या सुरक्षा देते हैं

कुकी-आधारित सत्र क्लासिक सेटअप है। साइन-इन के बाद, सर्वर एक सत्र रिकॉर्ड बनाता है (अक्सर एक ID प्लस फ़ील्ड जैसे उपयोगकर्ता ID, बनाये जाने का समय, और समाप्ति)। ब्राउज़र केवल सत्र ID को कुकी में स्टोर करता है। हर अनुरोध पर ब्राउज़र वह कुकी वापस भेजता है, और सर्वर सत्र देखकर तय करता है कि उपयोगकर्ता कौन है।

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

बहुत सुरक्षा कुकी सेटिंग्स से आती है:

• HttpOnly: JavaScript से कुकी पढ़ने से रोकता है।
• Secure: कुकी केवल HTTPS पर भेजी जाती है।
• SameSite: ब्राउज़र कब क्रॉस-साइट अनुरोधों पर कुकी भेजता है उसे सीमित करता है।

आप कहां सत्र स्टेट स्टोर करते हैं वह स्केलिंग को प्रभावित करता है। ऐप मेमोरी में सत्र रखना सरल है, लेकिन यह टूट जाता है जब आप कई सर्वर चलाते हैं या अक्सर रिस्टार्ट करते हैं। डाटाबेस स्थिरता के लिए अच्छा काम करता है। Redis सामान्य है जब आपको तेज़ लुकअप और बहुत सारे सक्रिय सत्र चाहिए। मुख्य बात वही है: सर्वर को हर अनुरोध पर सत्र मिलना और वैध करना चाहिए।

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

JWT एक्सेस टोकन: ताकत और नुकीले पहलू

A JWT (JSON Web Token) एक साइन किया हुआ स्ट्रिंग है जो उपयोगकर्ता के बारे में कुछ क्लेम रखता है (जैसे उपयोगकर्ता ID, भूमिका, टेनेन्ट) और एक एक्सपायरी टाइम। आपका API लोकली सिग्नेचर और एक्सपायरी को सत्यापित करता है, बिना डेटाबेस कॉल के, फिर अनुरोध को ऑथराइज़ करता है।

इसी वजह से JWTs API-फ़र्स्ट उत्पादों, मोबाइल ऐप्स, और उन सिस्टमों में लोकप्रिय हैं जहाँ कई सेवाओं को एक ही पहचान को सत्यापित करना होता है। अगर आपके पास कई बैकएंड इंस्टेंसेस हैं, तो हर एक वही टोकन सत्यापित कर सकता है और वही जवाब पा सकता है।

ताकत

JWT एक्सेस टोकन चेक करने में तेज़ और API कॉल्स के साथ पास करने में आसान होते हैं। अगर आपका फ्रंटएंड कई एंडपॉइंट कॉल करता है, तो एक शॉर्ट-लाइव्ड एक्सेस टोकन प्रवाह को सीधा रख सकता है: सिग्नेचर सत्यापित करें, उपयोगकर्ता ID पढ़ें, आगे बढ़ें।

उदाहरण: एक कस्टमर पोर्टल "लिस्ट इनवॉइसेज़" और "अपडेट प्रोफ़ाइल" अलग सेवाओं पर कॉल करता है। एक JWT ग्राहक ID और customer जैसी भूमिका रख सकता है, इसलिए हर सेवा अनुरोध को सत्र लुकअप किए बिना ऑथराइज़ कर सकती है।

नुकीले पहलू

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

JWTs सामान्य तरीकों से लीक भी होते हैं। सामान्य कमजोरी के बिंदु localStorage (XSS इसे पढ़ सकता है), ब्राउज़र मेमोरी (मैलिशियस एक्सटेंशन), लॉग और एरर रिपोर्ट्स, प्रॉक्सी और एनालिटिक्स टूल्स जो हेडर कैप्चर करते हैं, और सपोर्ट चैट या स्क्रीनशॉट्स में कॉपी किए गए टोकन शामिल हैं।

इसलिए JWT एक्सेस टोकन लंबे समय तक चलने वाले "हमेशा लॉग इन" के लिए सबसे अच्छे नहीं हैं। इन्हें न्यूनतम रखें (भीतर संवेदनशील व्यक्तिगत डेटा न रखें), एक्सपायर छोटा रखें, और मान लें कि चुराया गया टोकन उसके एक्सपायर तक उपयोग योग्य रहेगा।

रिफ्रेश टोकन: JWT सेटअप को व्यवहार्य बनाना

JWT एक्सेस टोकन शॉर्ट-लाइव्ड होने के लिए बनाए गए हैं। यह सुरक्षा के लिए अच्छा है, लेकिन एक व्यावहारिक समस्या पैदा करता है: उपयोगकर्ताओं को हर कुछ मिनट में फिर से लॉगिन नहीं करना चाहिए। रिफ्रेश टोकन इसे हल करते हैं — वे ऐप को बिना उपयोगकर्ता हस्तक्षेप के पुराने एक्सेस टोकन की जगह नया एक्सेस टोकन लेने देते हैं।

रिफ्रेश टोकन को कहाँ रखा जाता है यह और भी महत्वपूर्ण है। ब्राउज़र-आधारित वेब ऐप में, सबसे सुरक्षित डिफ़ॉल्ट HttpOnly, Secure कुकी है ताकि JavaScript इसे न पढ़ सके। Local storage लागू करने में आसान है, पर XSS बग होने पर इसे चुराना भी आसान है। अगर आपका थ्रेट मॉडल XSS को शामिल करता है, तो लंबे समय तक रहने वाले रहस्यों को JavaScript-पहुंच योग्य स्टोरेज में न रखें।

रोटेशन वह चीज़ है जो रिफ्रेश टोकन को असली सिस्टम में काम करने योग्य बनाती है। हमेशा एक ही रिफ्रेश टोकन के बजाय, आप हर उपयोग पर उसे बदलते हैं: क्लाइंट रिफ्रेश टोकन A प्रस्तुत करता है, सर्वर नया एक्सेस टोकन और नया रिफ्रेश टोकन B जारी करता है, और रिफ्रेश टोकन A अमान्य हो जाता है।

एक सरल रोटेशन सेटअप आमतौर पर कुछ नियमों का पालन करता है:

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

रीयूज़ डिटेक्शन मुख्य अलार्म है। अगर रिफ्रेश टोकन A पहले ही एक्सचेंज हो चुका था, पर आप उसे बाद में फिर देखते हैं, तो मान लें कि वह कॉपी हो गया है। आम प्रतिक्रिया आम तौर पर पूरे सत्र (अक्सर उपयोगकर्ता के सभी सत्र) को रिवोक करना और ताज़ा लॉगिन की आवश्यकता रखना है, क्योंकि आप नहीं जान सकते कि वास्तविक कॉपी कौन सी है।

लॉगआउट के लिए, आपको कुछ ऐसा चाहिए जिसे सर्वर लागू कर सके। इसका मतलब आमतौर पर एक सत्र टेबल (या एक रिवोकेशन लिस्ट) है जो रिफ्रेश टोकन को रिवोक्ड के रूप में चिह्नित करती है। एक्सेस टोकन तब भी एक्सपायर होने तक काम कर सकते हैं, पर आप एक्सेस टोकन की विंडो छोटी रखकर उस विंडो को सीमित कर सकते हैं।

लॉगआउट आवश्यकताएँ और असल में क्या लागू किया जा सकता है

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

एक समय का भी प्रश्न है। "तुरंत लॉगआउट" का मतलब है कि ऐप अभी उस प्रमाण को स्वीकार करना बंद कर दे। "एक्सपायरी के बाद लॉगआउट" का मतलब है कि ऐप वर्तमान सत्र या टोकन के प्राकृतिक एक्सपायर होने पर उसे स्वीकार करना बंद कर दे।

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

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

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

आप उपयोगकर्ताओं से यथार्थवादी वादे कर सकते हैं:

• इस डिवाइस को लॉगआउट: उस सत्र या रिफ्रेश टोकन को रिवोक करें, और स्थानीय कुकीज़ या स्टोरेज हटा दें।
• सभी जगह लॉगआउट: खाते के सभी सत्र या सभी रिफ्रेश टोकन परिवार रिवोक करें।
• "तुरंत" प्रभाव: सर्वर सत्रों के साथ गारंटीड, एक्सेस टोकन के साथ सर्वश्रेष्ठ प्रयास जब तक वे एक्सपायर नहीं होते।
• फोर्स्ड लॉगआउट इवेंट्स: पासवर्ड बदलना, अकाउंट डिसेबल करना, रोल डाउनग्रेड।

पासवर्ड बदलाव और अकाउंट डिसेबल के लिए, "उम्मीद न रखें कि उपयोगकर्ता खुद लॉग आउट होगा।" एक अकाउंट-वाइड सत्र वर्शन (या "टोकन वैलिड आफ्टर" टाइमस्टैम्प) स्टोर करें। हर रिफ्रेश (और कभी-कभी हर अनुरोध) पर इसे कंपेयर करें। अगर यह बदल गया है, तो इनकार करें और फिर से साइन-इन की आवश्यकता बताएं।

चरण-दर-चरण: अपनी ऐप के लिए सत्र तरीका चुनना

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

शुरू करें: हर जगह जहाँ उपयोगकर्ता साइन इन करता है, उसकी एक सूची बनाएं। एक ब्राउज़र ऐप, नेटिव मोबाइल ऐप, आंतरिक एडमिन टूल, या पार्टनर इंटीग्रेशन अलग तरह से व्यवहार करते हैं। हर एक तय करता है कि क्या सुरक्षित रूप से संग्रहीत किया जा सकता है, लॉगिन कैसे नवीनीकृत होते हैं, और "लॉगआउट" का क्या अर्थ होना चाहिए।

एक व्यावहारिक क्रम जो अधिकांश टीमों के लिए काम करता है:

1. अपने क्लाइंट्स सूचीबद्ध करें: वेब, iOS/Android, आंतरिक टूल, थर्ड-पार्टी एक्सेस।
2. एक डिफ़ॉल्ट थ्रेट मॉडल चुनें: XSS, CSRF, खोया डिवाइस।
3. तय करें कि लॉगआउट क्या गारंटी देनी चाहिए: इस डिवाइस, सभी डिवाइसेस, एडमिन फोर्स्ड लॉगआउट।
4. एक बेसलाइन पैटर्न चुनें: कुकी-आधारित सत्र (सर्वर याद रखे) या एक्सेस टोकन + रिफ्रेश टोकन।
5. टाइमआउट और रिस्पॉन्स नियम सेट करें: आइडल बनाम एब्सोल्यूट एक्सपायरी, और संदिग्ध रीयूज़ पर क्या करें।

फिर अपनी सिस्टम की सटीक प्रतिज्ञाएँ दस्तावेज़ करें। उदाहरण: "वेब सत्र 30 मिनट आइडल या 7 दिन एब्सोल्यूट पर एक्सपायर होते हैं। एडमिन 60 सेकंड के भीतर फोर्स-लॉगआउट कर सकता है। खोया फोन रिमोटली डिसेबल किया जा सकता है।" ये वाक्य लाइब्रेरी से ज़्यादा मायने रखते हैं।

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

अकाउंट टेकओवर के सामान्य गलतियाँ

ज़्यादातर अकाउंट टेकओवर "स्मार्ट हैक्स" नहीं होते। वे साधारण जीत होते हैं जो अनुमानित सत्र गलतियों की वजह से मिलते हैं। अच्छा सत्र हैंडलिंग ज्यादातर चीज़ यह सुनिश्चित करने के बारे में है कि हम अटैकर को प्रमाण चुराने या रीप्ले करने का आसान तरीका न दें।

एक सामान्य陷阱 है एक्सेस टोकन को localStorage में रखना और उम्मीद करना कि आप कभी XSS नहीं पाएंगे। अगर पेज पर कोई भी स्क्रिप्ट चलती है (कोई खराब निर्भरता, इनजेक्टेड विजेट, स्टोर्ड कमेंट), तो वह localStorage पढ़ सकती है और टोकन बाहर भेज सकती है। HttpOnly कुकीज़ इस जोखिम को कम करती हैं क्योंकि JavaScript उन्हें नहीं पढ़ सकता।

एक और陷阱 JWTs को लंबे समय तक चलने देना है ताकि रिफ्रेश टोकन की ज़रूरत न पड़े। 7-दिन का एक्सेस टोकन 7-दिन की रीयूज़ विंडो है अगर वह लीक हो जाता है। छोटा एक्सेस टोकन और अच्छी तरह प्रबंधित रिफ्रेश टोकन उसे दुरुपयोग करना कठिन बनाते हैं, खासकर जब आप रिफ्रेश काट सकते हैं।

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

अन्य सामान्य गलतियाँ जो घटना समीक्षा में अक्सर निकलकर आती हैं:

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

एक ठोस उदाहरण: एक सपोर्ट एजेंट एक "डिबग लॉग" टिकट में पेस्ट करता है। लॉग में Authorization हेडर शामिल है। टिकट एक्सेस रखने वाला कोई भी व्यक्ति उस टोकन को रीयूज़ कर सकता है और एजेंट के रूप में काम कर सकता है। टोकन को पासवर्ड की तरह ट्रीट करें: उन्हें न प्रिंट करें, न संग्रहीत करें, और उन्हें छोटा रखें।

शिप करने से पहले तेज़ जांचें

ज़्यादातर सत्र बग फैंसी क्रिप्टो के बारे में नहीं होते। वे एक गायब फ़्लैग, एक बहुत लंबे समय तक रहने वाला टोकन, या एक ऐसा एंडपॉइंट होते हैं जिसे रि-ऑथ चाहिए था।

रिलीस से पहले, स्टेजिंग में और फिर प्रोडक्शन सेटिंग्स में एक छोटी पास करें कि एक अटैकर एक चोरी किए गए कुकी या टोकन से क्या कर सकता है। यह आपकी सुरक्षा को बिना पूरे ऑथ सेटअप को फिर से लिखे बेहतर करने का तेज़ तरीका है।

प्री-रिलीज़ चेकलिस्ट

स्टेजिंग में और प्रोडक्शन में इन चेक्स को चलाएँ:

• एक्सेस टोकन को शॉर्ट-लाइव्ड रखें (मिनट्स), और सत्यापित करें कि API वास्तव में उन्हें एक्सपायरी के बाद रिजेक्ट कर देता है।
• रिफ्रेश टोकन को पासवर्ड जैसा ट्रीट करें: जहाँ संभव हो JavaScript उन्हें न पढ़ सके, केवल रिफ्रेश एंडपॉइंट पर भेजें, और हर उपयोग पर रोटेट करें।
• अगर आप ऑथ के लिए कुकीज़ का उपयोग करते हैं, तो फ़्लैग्स जांचें: HttpOnly ऑन, Secure ऑन, और SameSite को इरादतन सेट करें। कुकी का स्कोप (डोमेन और पाथ) ज़रूरत से ज़्यादा चौड़ा न रखें।
• अगर कुकीज़ अनुरोधों का प्रमाणीकरण करती हैं, तो CSRF बचाव जोड़ें, और पुष्टि करें कि स्टेट-चेंजिंग एंडपॉइंट बिना CSRF सिग्नल के फ़ेल होते हैं।
• रिवोकेशन को असली बनाएं: पासवर्ड रीसेट या अकाउंट डिसेबल के बाद, मौजूदा सत्र जल्दी काम करना बंद कर दें (सर्वर-साइड सत्र डिलीट, रिफ्रेश टोकन अमान्य करना, या "सत्र वर्शन" चेक)।

उसके बाद, अपने लॉगआउट वादों का परीक्षण करें। "लॉग आउट" अक्सर "स्थानीय सत्र हटाएं" का मतलब होता है, पर उपयोगकर्ता उससे ज़्यादा की उम्मीद करते हैं।

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

उदाहरण: स्टाफ खातों और फोर्स्ड लॉगआउट वाले कस्टमर पोर्टल

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

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

यहाँ एक व्यावहारिक सेटअप है: शॉर्ट-लाइव्ड एक्सेस टोकन + रोटेटिंग रिफ्रेश टोकन, सर्वर-साइड रिवोकेशन के साथ। यह आपको तेज़ API कॉल्स और ऑफ़लाइन सहनशीलता देता है, जबकि एडमिन को भी सत्र काटने की शक्ति देता है।

यह कुछ इस तरह दिख सकता है:

• एक्सेस टोकन लाइफटाइम: 5 से 15 मिनट।
• रिफ्रेश टोकन रोटेशन: हर रिफ्रेश पर नया रिफ्रेश टोकन, और पुराना अमान्य।
• रिफ्रेश टोकन को सुरक्षित रखें: वेब पर HttpOnly, Secure कुकी; मोबाइल पर OS सिक्योर स्टोरेज।
• रिफ्रेश टोकन को सर्वर-साइड ट्रैक करें: एक टोकन रिकॉर्ड स्टोर करें (उपयोगकर्ता, डिवाइस, जारी किया गया समय, अंतिम उपयोग, रिवोक फ्लैग)। अगर किसी रोटेट किए गए टोकन का फिर से उपयोग होता है, तो उसे चोरी मानें और पूरी चेन रिवोक करें।

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

खोए हुए डिवाइस के लिए, नियम को सरल भाषा में परिभाषित करें: "10 मिनट के अंदर, ऐप सिंक करना बंद कर देगा और फिर से साइन-इन की आवश्यकता होगी।" ऑफ़लाइन काम डिवाइस पर रह सकता है, पर अगली ऑनलाइन सिंक तब तक फेल कर देनी चाहिए जब तक उपयोगकर्ता फिर से साइन इन न करे।

अगले कदम: लागू करें, परीक्षण करें, और इसे बनाए रखने योग्य रखें

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

प्रतिज्ञाओं को एक छोटे टेस्ट प्लान में बदलें। टोकन और सत्र बग अक्सर हैप्पी-पाथ डेमो में ठीक दिखते हैं, पर असली जीवन (स्लीप मोड, खराब नेटवर्क, कई डिवाइस) में फेल होते हैं।

एक व्यावहारिक टेस्ट चेकलिस्ट

इन गंदे केस कवर करने वाले टेस्ट चलाएँ:

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

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

अगर आपको तेज़ी से आगे बढ़ना है, तो कस्टम ग्लू को घटाएँ। AppMaster (appmaster.io) एक विकल्प है जब आप एक जेनरेटेड, प्रोडक्शन-रेडी बैकएंड और वेब व नेटिव मोबाइल ऐप चाहें, ताकि आप expiry, rotation, और forced logout जैसे नियम क्लाइंट्स के बीच सुसंगत रख सकें।

लॉन्च के बाद फ़ॉलो-अप रिव्यू शेड्यूल करें। रीयल सपोर्ट टिकट और घटनाओं का उपयोग करके टाइमआउट, सत्र सीमाएँ, और "सभी जगह लॉगआउट" व्यवहार समायोजित करें, फिर वही चेकलिस्ट फिर चलाएँ ताकि फिक्स चुपचाप regress न हों।