- JWT, JSON Web Tokens का संक्षिप्त रूप है, और यह authenticated token के लिए एक standard है।
- JWT, header, payload, signature या message authentication code से मिलकर बना होता है।
- जिसके पास verification key होती है, वह payload की प्रामाणिकता की पुष्टि कर सकता है।
JWT के सामान्य उपयोग पैटर्न
- JWT में issuer, audience, subject, expiration time जैसी जानकारी शामिल होती है।
- प्राप्तकर्ता टोकन की प्रामाणिकता की पुष्टि करने के बाद यह जांचता है कि expiration time बीता नहीं है, और subject को authenticated user मानता है।
JWT के फायदे
- JWT का मुख्य फायदा यह है कि प्राप्तकर्ता user database से जुड़े बिना भी टोकन की प्रामाणिकता की पुष्टि कर सकता है।
- बड़े deployment environment में authentication service, central user database तक पहुंच रखने वाली एकमात्र service हो सकती है।
logout और session invalidation की समस्या
- authentication token की lifetime छोटी होनी चाहिए। उदाहरण के लिए, अधिकतम 5 मिनट।
- client को एक refresh token भी दिया जाता है, जिसके जरिए वह नया authentication token मांग सकता है।
- refresh token वास्तव में session token की भूमिका निभाता है।
जब JWT की जरूरत नहीं होती
- logout लागू करने के लिए valid JWT की allowlist या revoked JWT की denylist बनाए रखनी पड़ती है।
- किसी user को block करने के लिए database में "user active" flag जांचना पड़ता है।
- user object और दूसरे object के बीच अतिरिक्त relationships की जरूरत होती है।
- database से संबंधित operations किए जाते हैं।
निष्कर्ष
- अगर ऊपर दी गई शर्तों में से एक भी लागू होती है, तो JWT की जरूरत नहीं है।
- सामान्य opaque session token का उपयोग करना और उसे database में store करना बेहतर है।
- इससे JWT के नुकसान से बचा जा सकता है और complexity कम होती है।
GN⁺ की राय
- JWT बड़े पैमाने की services के लिए उपयुक्त है, लेकिन अधिकांश छोटी services के लिए यह अनावश्यक complexity ला सकता है।
- सामान्य session management mechanism अधिकांश web applications के लिए पर्याप्त है।
- JWT का उपयोग करने पर logout और session invalidation जैसी सुविधाओं को लागू करना कठिन हो सकता है।
- JWT के फायदों का लाभ उठाने के लिए service के scale और requirements पर सावधानी से विचार करना चाहिए।
- एक अन्य विकल्प के रूप में OAuth2 जैसे authentication framework पर विचार किया जा सकता है।
8 टिप्पणियां
जब विभिन्न क्लाइंट authentication की ज़रूरत होती है, तब JWT का उपयोग करने से काफ़ी फ़ायदे मिले।
हालाँकि scalability और security हमेशा अलग दिशाओं में देखते हैं, इसलिए अगर security विशेष रूप से महत्वपूर्ण है तो मुझे लगता है कि कोई दूसरा तरीका इस्तेमाल करना बेहतर है।
व्यक्तिगत रूप से, मेरा मानना है कि jwt token का इस्तेमाल तब करना ठीक है जब ब्राउज़र के ज़रिए सिस्टमों के बीच ऐसी अस्थायी data का आदान-प्रदान करना हो जो सार्वजनिक हो जाने पर भी समस्या न हो
और authentication में इस्तेमाल होने वाले, व्यक्तिगत जानकारी वाले token के लिए opaque token इस्तेमाल करना बेहतर है..
मेरे व्यक्तिगत अनुभव के हिसाब से, MVP बनाते समय JWT के कुछ फायदे थे.
उदाहरण के लिए, अगर यह ऐसी सेवा हो जिसे आप अकेले बनाते और मेंटेन करते हों, तो मेरा मानना था कि इससे अचानक आने वाली रिक्वेस्ट्स के कारण होने वाली planning cost कम की जा सकती है। अक्सर शुरू में बनाई गई data relationships एक-दो महीने बाद पूरी तरह बदल जाती थीं, इसलिए जब planning स्पष्ट न हो, तो कम-से-कम auth से जुड़ी चीज़ों में JWT payload को optional fields के रूप में डिज़ाइन करके feature implementation पहले से कर दी जाए, तो planning टीम को domain separation और service separation का काम किए बिना भी, monolithic service में पहले domain को आसानी से अलग करने लायक रूप में implement करके market test किया जा सकता था—मुझे ऐसा याद है। (और बाद में ज़रूरत पड़े तो service separation की प्रक्रिया अपनाई जा सकती थी। या फिर उसे हटा भी सकते थे।)
लेकिन मुझे लगता है कि यह उस सेवा के domain पर भी निर्भर करेगा जिसे आप बनाना चाहते हैं। वह प्रोजेक्ट real-time services में भी third-party के साथ high coupling वाला प्रोजेक्ट था.... इसलिए शायद तेजी से implement करते हुए अगर DB में बहुत बड़ी मात्रा में documents/rows जमा हो जाते, तो management cost बढ़ जाती—ऐसा सोचकर हमने उस दिशा में काम किया था, मुझे याद है।
बेशक, अगर फोकस जल्दी बनाने पर हो, तो मुझे लगता है कि session-based तरीका बेहतर है। (शुरुआत में अलग-अलग services के बीच coupling इतनी मज़बूत नहीं होती, इसलिए सब कुछ बदलकर फिर से बनाना भी आसान होता है।) और जब दूसरी टीम के सदस्य जुड़ते हैं, तब handover cost भी कम रहती है।
उस समय मैंने थोड़ी देर के लिए इस पर कई तरह से सोचा था, लेकिन सच कहूँ तो अब पीछे मुड़कर देखता हूँ, तो लगता है कि किसी भी तरीके से implement किया होता, प्रोजेक्ट पर उसका प्रभाव शायद इतना गंभीर नहीं होता।
मेरी व्यक्तिगत राय में, जब api gateway का उपयोग किया जाता है, तब auth implementation को JWT से करने पर फ़ायदा मिलता है। लेकिन मैं जानना चाहता हूँ कि छोटे पैमाने की service में JWT के क्या फ़ायदे होते हैं। क्या आपका मतलब उन मामलों से है जहाँ JWT में शामिल user जानकारी को बार-बार बदलना पड़ता है?
आपकी बात से बड़े स्तर पर मैं सहमत हूँ। बस फर्क इतना था कि user itself की modeling बदलकर जानकारी बार-बार अपडेट करनी पड़े, ऐसा कम था; बल्कि जब कोई नया feature जोड़ना हो या third-party tool इस्तेमाल करने वाली नई service को अतिरिक्त जानकारी चाहिए हो, तब उसे optional रूप से जोड़ने वाले मामले के ज़्यादा करीब था। (थोड़ा और कहूँ तो, auth को API gateway जैसी किसी चीज़ से संभालकर management unit अलग करना है या नहीं, या फिर वैसी भूमिका निभाने वाला कोई एक server होगा या नहीं—ऐसी थोड़ी पेचीदा स्थिति भी थी...)
थोड़ा और ठोस उदाहरण दूँ तो, उस समय A नाम की service मुख्य रूप से चल रही थी। MVP होने की वजह से user table में सिर्फ payment information और user verified है या नहीं, इतनी ही जानकारी थी। लेकिन फिर ऐसी services B और C जोड़ने का अनुरोध आया, जिन्हें इस्तेमाल करने के लिए हर user के लिए अलग authentication information चाहिए थी। इनमें B को A service के अंदर शामिल किया जाएगा या नहीं, यह भी तय नहीं था, और C तो शायद हट भी सकती थी, इसलिए उसे हल्के तौर पर test करना चाहते थे। (plan management feature तो बिना कहे भी जोड़ना पड़ता, नहीं तो आगे समस्या होती।) इसके अलावा, वे B और C को पहले से A service दे रही web service page के भीतर साथ में इस्तेमाल करने वाले रूप में शुरू करना चाहते थे। चल रही service की प्रकृति के कारण, जब तक plan management table (या कोई generic authentication-related table) बनाकर हर service के लिए domain relation define करके mapping के साथ implement न कर लिया जाए, तब तक कई tables query करना (या collections query करना) अपरिहार्य था। अगर project को व्यवस्थित करने वाला कोई व्यक्ति होता, तो कुछ meetings करके यह साफ़ निकालना अच्छा रहता कि आखिर solve किस problem को करना है और चाहिए कौन-से features; लेकिन ऐसी गारंटी नहीं थी। और ये debts कब साफ़ किए जा सकेंगे, यह भी अस्पष्ट था। इसलिए इस तरह की स्थिति बन सकती है, इसके संकेत तो A service launch होने से पहले ही दिख रहे थे... शुरुआती design बनाते समय सोचा कि auth के समय जितना हो सके lookup cost और आगे की maintenance cost बचाने वाली दिशा में जाएँ, और उसी सोच से JWT चुना। इसके अलावा भी ऐसी छोटी-बड़ी मिलती-जुलती स्थितियाँ बहुत थीं।
लेकिन जैसा मैंने comment के आख़िर में कहा था, सच तो यह है कि चाहे इसे किसी भी तरीके से implement किया होता, project पर बहुत बड़ा असर शायद नहीं पड़ता। अगर session से implement किया होता, तब भी session के हिसाब से कोई न कोई तरीका निकाल ही लेते। बल्कि ज़्यादा घातक बात शायद यह थी कि developers लगातार ऐसी स्थिति में exposed थे जहाँ उन्हें दूसरे roles का काम भी करना पड़ता था, या communication cost बार-बार टूटती-बिखरती थी।
भले ही यह monolith संरचना के लिए उपयुक्त हो, लेकिन जब कुछ services को अलग करने या विस्तार के मोड़ पर आना पड़ता है, तब jwt और session-आधारित logic के बीच स्पष्ट अंतर दिखाई देता है। यह सिर्फ authentication प्रक्रिया का सवाल नहीं है; internal logic की usability में data के source को संभालने के तरीके भी अलग हो जाते हैं। लेकिन "छोटी service" वाले context को किस मानक पर उपयुक्त माना जाए, यह मुझे ठीक से समझ नहीं आता। क्या यह मान लिया गया है कि सभी services अनिवार्य रूप से छोटी ही होंगी? या यह कि बड़ी services को संभालना आसान नहीं होगा? फिर भी, मुझे लगता है कि हम जो भी services बनाते हैं, उनमें कम से कम इतनी संरचना तो होनी चाहिए कि वे ऐसे contexts को support कर सकें जो अभी भले स्पष्ट न हों, लेकिन फिर भी उपयोगी साबित हो सकते हैं। "छोटी service" की धारणा शायद बस लगातार और छोटी होती जाने वाली चीज़ बनकर रह जाएगी।
Hacker News राय
Hacker News टिप्पणियों का सार