उपयोगकर्ता सत्रों के लिए JSON Web Tokens का उपयोग बंद करें

मूल लेख ↗ Hacker News चर्चा ↗

डेवलपर्स इस बात पर बहस कर रहे हैं कि क्या JSON Web Tokens (JWTs) वेब ऐप्स, खासकर single-page applications, में user sessions को संभालने के लिए उपयुक्त हैं। कई लोगों का कहना है कि समस्या JWTs में नहीं है; असली जोखिम इन्हें JavaScript-accessible जगहों जैसे localStorage में रखने, कमजोर XSS सुरक्षा, और token revocation की कठिनाई से आता है, इसलिए कुछ लोग पारंपरिक server-side sessions या HttpOnly, SameSite cookies में रखे JWTs को प्राथमिकता देते हैं। दूसरों का मानना है कि वितरित प्रणालियों और APIs में JWTs अब भी उपयोगी हैं, लेकिन वे ज़ोर देते हैं कि common security pitfalls से बचने के लिए इन्हें स्पष्ट threat models, short lifetimes, और सावधानीपूर्ण implementation के साथ उपयोग करना चाहिए।

बहस का दायरा

  • कई लोगों का तर्क है कि लेख वास्तव में XSS और स्टोरेज विकल्पों के बारे में है, JWTs के बारे में नहीं।
  • बार-बार स्पष्ट किया गया है: JWT केवल एक टोकन फॉर्मेट है; इसे cookies या अन्य स्टोरेज के साथ उपयोग किया जा सकता है, और यह स्वाभाविक रूप से “cookie-based sessions” के विरोध में नहीं है।

सेशन स्टेट कहाँ स्टोर करें

  • मजबूत पक्ष: session identifiers/JWTs को HttpOnly, Secure, SameSite cookies में स्टोर करें।
    • XSS द्वारा सीधे टोकन चोरी से सुरक्षा मिलती है।
    • मैन्युअल header plumbing से बचाता है; browser cookies अपने-आप भेजता है।
  • localStorage / JS-accessible स्टोरेज की आलोचना:
    • XSS द्वारा आसानी से exfiltrate किया जा सकता है; खासकर long-lived refresh tokens के लिए यह समस्या है।
    • कुछ frameworks (Firebase, Cognito) डिफ़ॉल्ट रूप से local/IndexedDB का उपयोग करते हैं और HttpOnly का उपयोग नहीं कर सकते।
  • अल्पमत का मत: localStorage “ठीक” है क्योंकि XSS का मतलब वैसे भी “game over” है, और हमलावर browser में requests के जरिए cookies का दुरुपयोग कर सकते हैं।

CSRF, SameSite और Cookies

  • सिफ़ारिश: संवेदनशील cookies पर SameSite सेट करें।
    • CSRF सुरक्षा के लिए Lax अक्सर पर्याप्त माना जाता है; Strict पहली पेज पर logged-in व्यवहार को तोड़ सकता है।
  • cross-site form posts और cookies के पारस्परिक प्रभाव को लेकर कुछ भ्रम है; नियंत्रण के रूप में SameSite को सामने रखा जाता है।

XSS Threat Model

  • एक पक्ष: यदि JS inject किया जा सकता है, तो हमलावर पहले से ही user की तरह कार्य कर सकता है (requests issue कर सकता है), इसलिए cookie बनाम localStorage का महत्व कम है।
  • दूसरा पक्ष: HttpOnly फिर भी meaningful रूप से नुकसान सीमित करता है, क्योंकि यह token exfiltration और दूसरे device से reuse को रोकता है; layered defenses मायने रखती हैं।

JWT Design और Revocation

  • JWT के फायदे बताए गए:
    • Stateless validation; APIs, distributed systems, और microservices के लिए अच्छा।
    • Downstream services JWT के जरिए auth DB को हर बार hit किए बिना authorization कर सकते हैं।
  • बड़ा नुकसान: revoke / logout करना कठिन है:
    • आम pattern: short-lived access tokens + long-lived refresh tokens, जिनमें refresh tokens अक्सर opaque होते हैं और DB-checked होते हैं।
    • जैसे ही आप revocation lists या DB checks जोड़ते हैं, कुछ “stateless” लाभ खो देते हैं; कुछ लोग पूछते हैं कि फिर JWT का उपयोग ही क्यों करें।
  • कई लोग simple opaque session IDs को cookies में रखने की सलाह देते हैं, और JWTs को केवल gateways पर internal रूप से convert करने का सुझाव देते हैं।

कानूनी / UX / व्यावहारिक चिंताएँ

  • यह स्पष्ट किया गया है कि functional/session cookies के लिए आमतौर पर consent banners की आवश्यकता नहीं होती; “cookie directive” को लेकर भ्रम है।
  • कुछ लोग अत्यधिक सख़्त security guidance (जैसे बहुत छोटे timeouts) को उपयोगिता के लिए हानिकारक मानते हैं।
  • अन्य लोग “Stop using X” लेखों की आलोचना करते हैं जो स्पष्ट, व्यावहारिक विकल्प या nuance नहीं देते।