टोकन के अंदर क्या होता है
JWT बिंदुओं से अलग हुए तीन हिस्सों का बना होता है। पहले दो हिस्से Base64url में एन्कोड किया JSON हैं, जिन्हें कोई भी पढ़ सकता है; तीसरा हिस्सा हस्ताक्षर है।
- हेडर — इसमें हस्ताक्षर का एल्गोरिदम (
alg) और प्रकार (typ) रहता है। जो सेवाएँ कई चाबियाँ बदल-बदलकर चलाती हैं, वेkidभी जोड़ती हैं जो बताता है कि किस चाबी से हस्ताक्षर हुआ। - पेलोड — इसमें क्लेम आते हैं।
subउपयोगकर्ता की पहचान है,issजारी करने वाला,audवह पक्ष जिसके लिए टोकन बना, औरexp,iat,nbfसमय बताते हैं। - हस्ताक्षर — पहले दो हिस्सों पर चाबी से किया गया हस्ताक्षर।
नियमों के अनुसार समय वाले क्लेम सेकंड की पूर्णांक संख्या होते हैं। जिस टोकन में मिलीसेकंड डाल दिए गए हों, वह यहाँ हज़ारों साल आगे दिखेगा — यह जारी करने वाले पक्ष की गलती है।
डिकोड करना और जाँचना अलग बातें हैं
यहाँ सामग्री पढ़ लेने का मतलब यह नहीं कि टोकन असली है। पेलोड पर कोई ताला नहीं है, उसे कोई भी बदल सकता है, और हस्ताक्षर बेमेल है या नहीं, यह सिर्फ़ चाबी रखने वाला ही जान सकता है।
इसीलिए सर्वर को हर अनुरोध पर हस्ताक्षर जाँचना चाहिए, और जाँचते समय हेडर के alg पर भरोसा नहीं करना चाहिए। जाँच का एल्गोरिदम सर्वर पर पहले से तय रखें, और alg में none मिले या अपेक्षा से अलग कुछ मिले तो टोकन ठुकरा दें। हेडर के कहे पर चलने वाली इम्प्लीमेंटेशन ही वह पुराना रास्ता है जिससे बिना हस्ताक्षर वाले टोकन निकल जाते हैं।
पेलोड में राज़ न रखें
जिसके पास टोकन है, वह ब्राउज़र के डेवलपर टूल खोलकर भी पेलोड पढ़ लेगा। उसमें पहचान संख्या, भीतरी प्रशासनिक टिप्पणी या भुगतान की जानकारी हो, तो मान लीजिए वह सार्वजनिक हो चुकी है।
वहाँ वही रखें जो टोकन रखने वाले को दिख जाए तो हर्ज़ न हो — उपयोगकर्ता आईडी, भूमिका के नाम, समाप्ति का समय। बाकी सब सर्वर पर रहे और ज़रूरत पड़ने पर देखा जाए।
किसी और का टोकन चिपकाने से पहले
यह टूल टोकन कहीं नहीं भेजता। फिर भी, जिसकी अवधि बची है वह टोकन अपने आप में लॉगिन का प्रमाण है — चैट या टिकट सिस्टम में चिपकाते ही जो पढ़ेगा, वह उसे इस्तेमाल कर सकता है। गलती से साझा हो जाए तो अवधि खत्म होने का इंतज़ार न करें, उस सत्र को तुरंत रद्द करें।