JWTs का उपयोग बंद करें
बहस का दायरा
- अधिकांश प्रतिभागी दो मुख्य उपयोग-परिदृश्यों में भेद करते हैं:
- ब्राउज़र-आधारित यूज़र सेशन्स।
- सर्विस-टू-सर्विस / बैकएंड टोकन्स।
- व्यापक नरम सहमति: JWTs अक्सर ब्राउज़र सेशन्स के लिए खराब विकल्प होते हैं, लेकिन बैकएंड और फेडरेशन परिदृश्यों के लिए ठीक या कभी-कभी आदर्श भी हो सकते हैं।
ब्राउज़र-आधारित सेशन्स के लिए JWTs
- आलोचकों का कहना है कि यदि वही सर्वर उन्हें जारी और सत्यापित करता है, तो HttpOnly कुकीज़ में साधारण opaque session IDs की तुलना में JWTs अनावश्यक जटिलता जोड़ते हैं, और कोई वास्तविक लाभ नहीं देते।
- उठाई गई मुख्य समस्याएँ:
- रद्द करना और logout करना कठिन/अटपटा, खासकर per-device logout।
- replayability और लंबे समय तक जीवित रहने वाले टोकन्स।
- टोकन्स में संवेदनशील या mutable डेटा ठूँस देने की प्रवृत्ति, जिससे cache invalidation और security समस्याएँ पैदा होती हैं।
- कई लोगों का तर्क है: यदि आपको पहले से ही एक datastore चाहिए (users, permissions के लिए), तो सेशन state वहीं रखें और sessions के लिए cryptography से बचें।
सुरक्षा गुण और implementation की गलतियाँ
- ऐतिहासिक समस्याएँ:
alg=none, algorithm downgrade/confusion, libraries का public keys को HMAC secrets के रूप में स्वीकार करना, खराब defaults। - कुछ लोगों का तर्क है कि ये library bugs थे और अधिकांशतः ठीक हो चुके हैं; अन्य लोग कहते हैं कि ये एक ऐसे spec से आते हैं जो footguns और जटिलता को प्रोत्साहित करता है।
- इस पर असहमति है कि आज JWT कितना “insecure” है:
- एक पक्ष: “यदि आप algorithms सीमित करें और अच्छी libs उपयोग करें, तो JWT ठीक है।”
- दूसरा पक्ष: “Spec misuse को प्रोत्साहित करता है; CVEs आते रहते हैं; सुरक्षित designs मौजूद हैं।”
Revocation, “stateless” auth, और logout
- मूल तनाव: JWTs को “stateless” के रूप में प्रचारित किया जाता है, लेकिन सुरक्षित logout और compromise handling के लिए state की आवश्यकता होती है:
- Revocation lists / denylists.
- प्रति-उपयोगकर्ता “not valid before” timestamps.
- Key rotation schemes.
- कुछ लोगों का तर्क है कि एक बार यह state जोड़ दी जाए, तो क्लासिक sessions पर मुख्य बढ़त खो जाती है।
- दूसरे जवाब देते हैं कि revocation lists पूरे session stores की तुलना में बहुत छोटी होती हैं और वैश्विक रूप से replicate करना आसान होता है।
Cookies, storage, और XSS/CSRF
- ब्राउज़र सेशन्स के लिए HttpOnly, Secure, SameSite cookies का मजबूत समर्थन।
- कई लोग localStorage में JWTs रखने के विरुद्ध चेतावनी देते हैं, क्योंकि XSS exfiltration हो सकती है; कुछ इसे यह कहकर कम आँकते हैं कि “untrusted JS की अनुमति मत दो,” जबकि अन्य इसे अवास्तविक कहते हैं।
- यह बात कि HttpOnly token theft रोकता है लेकिन XSS-चालित misuse नहीं।
विकल्प और व्यापक ecosystem
- उल्लेखित विकल्प: opaque random tokens, signed cookies, PASETO, macaroons, SAML/OIDC patterns, custom schemes.
- कुछ लोग PASETO/macaroon designs की misuse-resistance की प्रशंसा करते हैं, लेकिन सीमित ecosystem और adoption की ओर इशारा करते हैं।
- कई लोगों की नज़र में “stop using JWTs” framing जरूरत से ज़्यादा या clickbait जैसा है; वे “JWTs का उपयोग सीमित और सावधानीपूर्वक करें” को प्राथमिकता देते हैं।