JWT एक्सपायरेशन और Issued-At क्लेम्स: Unix Timestamps कैसे Token Auth को चलाते हैं

जब भी कोई उपयोगकर्ता किसी SaaS एप्लिकेशन में लॉगिन करता है, तो एक auth token बनाया जाता है और उसके ब्राउज़र या मोबाइल ऐप को दिया जाता है। उस token के अंदर एक छुपी हुई घड़ी होती है। JWT expiration फील्ड, जो एक सामान्य Unix timestamp के रूप में संग्रहीत होती है, हर उस सर्वर को बताती है जो उसे पढ़ता है कि उस credential पर भरोसा करना कब बंद करना है। अगर यह timestamp कुछ सेकंड के लिए भी गलत हो जाए, तो उपयोगकर्ता या तो जल्दी लॉक आउट हो जाते हैं, या इससे भी बुरा - वे आपकी सुरक्षा नीति से कहीं अधिक समय तक एक वैध सत्र रखते हैं। JSON web token के claims, खासकर exp और iat , को समझना किसी भी SaaS टीम के लिए सबसे व्यावहारिक काम है जो बिना किसी अतिरिक्त परेशानी के authentication को मजबूत बनाना चाहती है।

JWT क्या है और उसमें Timestamps क्यों होते हैं

एक JSON web token एक संक्षिप्त, URL-safe credential है जो तीन Base64-encoded भागों से बना होता है जो dots से अलग होते हैं: एक header, एक payload, और एक signature। payload वह जगह है जहाँ समय-संवेदनशील डेटा रहता है। चूंकि JWTs stateless होते हैं, इसलिए सर्वर उन्हें सत्यापित करने के लिए डेटाबेस में कोई सत्र नहीं खोजता। इसके बजाय, वह payload में बने claims को पढ़ता है और cryptographic signature पर भरोसा करता है। यह डिज़ाइन तेज और scalable है, लेकिन इसकी एक वास्तविक सीमा है: एक बार token जारी होने के बाद, सर्वर उसे "हटा" नहीं सकता। उसकी अवधि सीमित करने का एकमात्र विश्वसनीय तरीका यह है कि token के अंदर ही एक expiration timestamp डाला जाए।

इसीलिए समय, विशेष रूप से Unix epoch time, JWT सुरक्षा के केंद्र में है। RFC 7519 विनिर्देश जो JWTs को परिभाषित करता है, यह अनिवार्य करता है कि समय-संबंधित claims को "NumericDate" मानों के रूप में व्यक्त किया जाए, जो कि 1 जनवरी 1970 UTC के बाद से सेकंड की संख्या है। कोई timezone नहीं। कोई locale formatting नहीं। बस एक integer जिसे दुनिया में कहीं भी कोई भी सर्वर अपनी घड़ी से तुलना कर सकता है।

exp और iat Claims की व्याख्या

JWT विनिर्देश कई पंजीकृत claims परिभाषित करता है। Token जीवनचक्र प्रबंधन के लिए दो सबसे महत्वपूर्ण हैं:

• exp (Expiration Time): वह timestamp जिसके बाद token स्वीकार नहीं किया जाना चाहिए। सर्वरों को किसी भी ऐसे token को अस्वीकार करना आवश्यक है जहाँ वर्तमान समय इस मान के बराबर या उससे अधिक हो। यही JWT expiration का मूल तंत्र है।
• iat (Issued At): वह timestamp जब token बनाया गया था। iat claim डिफ़ॉल्ट रूप से लागू नहीं होता, लेकिन यह अत्यंत उपयोगी है। यह आपको token की आयु की गणना करने, स्वतंत्र रूप से exp से अधिकतम आयु नीति लागू करने, और संदिग्ध रूप से पुराने जारी किए गए tokens का पता लगाने देता है।

एक तीसरा claim, nbf (Not Before), वह सबसे पहला समय परिभाषित करता है जब token वैध होता है। यह कम सामान्यतः उपयोग किया जाता है लेकिन उसी Unix timestamp प्रारूप का पालन करता है।

तीनों मान integers हैं। अगर आपका सिस्टम उन्हें मिलीसेकंड में उत्पन्न करता है (JavaScript के Date.now() का उपयोग करते समय एक सामान्य गलती), तो परिणामी संख्या अपेक्षा से लगभग 1,000 गुना बड़ी होगी। एक सर्वर जो exp की तुलना वर्तमान epoch सेकंड से करता है, वह एक ऐसा token देखेगा जो वर्ष 33,658 में expire होता प्रतीत होता है और उसे कभी अस्वीकार नहीं करेगा। यह एक वास्तविक production बग है जिसने कई SaaS टीमों को प्रभावित किया है।

एक व्यावहारिक उदाहरण: असली Token Timestamps को Decode करना

मान लीजिए आपकी authentication सेवा 1 जुलाई 2025 को सुबह 10:00 AM UTC पर उपयोगकर्ता के लॉगिन के बाद निम्नलिखित JWT payload जारी करती है:

{
  "sub": "user_8821",
  "iat": 1751364000,
  "exp": 1751367600,
  "role": "admin"
}

आइए समझते हैं कि इन संख्याओं का क्या अर्थ है:

अंतर ठीक 3,600 सेकंड है, यानी एक घंटा। कोई भी सर्वर जो 11:00:00 UTC के बाद यह token प्राप्त करता है, उसे अस्वीकार करना होगा। इसे मैन्युअल रूप से सत्यापित करने के लिए, आप iat को exp से घटाते हैं: 1751367600 - 1751364000 = 3600 सेकंड। आप किसी भी इन मानों के पठनीय समतुल्य को Unix timestamp converter का उपयोग करके तुरंत जांच सकते हैं, जो पहले बताई गई मिलीसेकंड बनाम सेकंड की गलती से बचने के लिए एक त्वरित जांच है।

इन मानों को डेटाबेस में कैसे संग्रहीत किया जाना चाहिए, इस पर गहरी जानकारी के लिए हमारी गाइड देखें: डेटाबेस में Unix timestamps, क्योंकि वही integer प्रारूप लागू होता है चाहे आप exp को token में संग्रहीत कर रहे हों या audit log तालिका में।

Clock Skew: Token का मूक दुश्मन

यह एक वास्तविक समस्या है जो टीमों को अचानक परेशान करती है। एक distributed सिस्टम में, आपका authentication सर्वर और आपका API सर्वर दो अलग-अलग मशीनें हैं। उनकी सिस्टम घड़ियाँ NTP के माध्यम से समकालिक होती हैं, लेकिन वे कभी भी पूरी तरह से एक जैसी नहीं होतीं। क्लाउड वातावरण में 30 से 90 सेकंड का अंतर सामान्य है।

इस परिदृश्य पर विचार करें: एक token जिसमें exp = 1751367600 है, उसे एक API सर्वर द्वारा सत्यापित किया जाता है जिसकी घड़ी 1751367610 दिखाती है, यानी expiry के बाद केवल 10 सेकंड। Token अस्वीकार कर दिया जाता है। उपयोगकर्ता को 401 त्रुटि मिलती है। उनके नजरिए से, वे अभी-अभी लॉग इन हुए थे और ऐप अचानक काम करना बंद कर दिया।

इसका मानक समाधान यह है कि अपने validation logic में एक clock skew tolerance जोड़ें। अधिकांश JWT लाइब्रेरी एक leeway parameter का समर्थन करती हैं। 60 सेकंड का मान व्यापक रूप से स्वीकृत है और इसे OpenID Connect Core विनिर्देश में संदर्भित किया गया है। इसे सेट करें, दस्तावेज़ीकरण करें, और सुनिश्चित करें कि आपके stack की हर सेवा एक ही मान का उपयोग करे।

अपने SaaS उत्पाद के लिए सही Token Expiry चुनना

सही token expiry मान आपके एप्लिकेशन की संवेदनशीलता और अपेक्षित सत्र व्यवहार पर निर्भर करता है। यहाँ एक व्यावहारिक ढांचा है:

• उच्च-संवेदनशीलता ऐप्स (बैंकिंग, स्वास्थ्य सेवा, admin डैशबोर्ड): access tokens के लिए 15 से 30 मिनट। सत्र को चुपचाप नवीनीकृत करने के लिए refresh tokens का उपयोग करें।
• सामान्य SaaS ऐप्स (परियोजना प्रबंधन, CRM, analytics): 1 से 8 घंटे। सामान्य कार्य सत्र की लंबाई के अनुसार।
• कम जोखिम वाले या केवल पढ़ने योग्य APIs: 24 घंटे तक, लेकिन संवेदनशील कार्यों पर token rotation के साथ।
• Machine-to-machine सेवा tokens: अधिक लंबे (दिन या सप्ताह) हो सकते हैं, लेकिन सीमित दायरे वाले होने चाहिए और एक निर्धारित समय पर rotate किए जाने चाहिए।

जारी करने के समय अपने exp मान की गणना के लिए एक उपयोगी फॉर्मूला:

// Node.js example
const iat = Math.floor(Date.now() / 1000); // current time in seconds
const ttl = 3600; // time-to-live: 1 hour in seconds
const exp = iat + ttl;

const payload = {
  sub: userId,
  iat: iat,
  exp: exp
};

ध्यान दें कि मिलीसेकंड से सेकंड में बदलने के लिए 1000 से स्पष्ट भाग दिया गया है। यह एक पंक्ति JavaScript एप्लिकेशन में सबसे सामान्य JWT timestamp बग को रोकती है।

सुरक्षित JWT Expiration लागू करने के व्यावहारिक कदम

यहाँ एक ठोस चेकलिस्ट है जिसे आप आज किसी भी SaaS authentication सिस्टम पर लागू कर सकते हैं:

1. हमेशा iat और exp दोनों शामिल करें। iat claim तकनीकी रूप से वैकल्पिक है, लेकिन यह आपको एक audit trail देता है और expiry से स्वतंत्र रूप से अधिकतम आयु लागू करने में सक्षम बनाता है।
2. deploy करने से पहले timestamp प्रारूप सत्यापित करें। अपने token को decode करें और जांचें कि exp एक 10-अंकीय integer है। 13-अंकीय मान का मतलब है कि मिलीसेकंड आ गए हैं।
3. अपने validation middleware में 60 सेकंड का clock skew leeway सेट करें। इसे हर उस सेवा पर समान रूप से लागू करें जो auth tokens का उपयोग करती है।
4. refresh tokens के साथ short-lived access tokens का उपयोग करें। 7-दिन के refresh token के साथ 15-मिनट का access token एकल 7-दिन के access token से कहीं अधिक सुरक्षित है, क्योंकि refresh token को server-side revoke किया जा सकता है।
5. हर authenticated अनुरोध पर iat मान लॉग करें। यह आपको विसंगतियों का पता लगाने देता है, जैसे कि एक ही token का एक साथ दो अलग-अलग भौगोलिक क्षेत्रों से उपयोग।
6. staging में accelerated time के साथ expiry का परीक्षण करें। अपनी घड़ी को exp मान से आगे jump करने के लिए mock करें और पुष्टि करें कि आपका ऐप 401 को crash या loop करने के बजाय gracefully संभालता है।

अगर आपको किसी token से raw exp मान को पठनीय तारीख में बदलना हो, या किसी निर्धारित अवधि के लिए timestamp सेट करना हो, तो हमारे मुखपृष्ठ पर epoch converter दोनों दिशाओं में तुरंत काम करता है, बिना किसी कोड के।

निष्कर्ष

JWT expiration कोई जटिल अवधारणा नहीं है, लेकिन यह वह जगह है जहाँ छोटी गलतियाँ बड़े सुरक्षा अंतराल पैदा करती हैं। exp और iat claims केवल integers हैं, Unix timestamps जो epoch से सेकंड में गिने जाते हैं। यह सरलता ही उनकी ताकत है: हर सर्वर, हर भाषा, और हर platform बिना किसी अस्पष्टता के दो संख्याओं की तुलना कर सकता है। असली कौशल उन्हें सही तरीके से लागू करने में है - एक उचित token expiry अवधि चुनना, tolerance window के साथ clock skew को संभालना, और मिलीसेकंड बनाम सेकंड की गलती को production में जाने से पहले पकड़ना। इन आदतों को अपनी auth pipeline में शामिल करें और आपका JSON web token implementation सुरक्षित और रखरखाव योग्य दोनों होगा।

JWT Timestamps को तुरंत सत्यापित करें - बिना कोड के

JWT payload से कोई भी Unix timestamp पेस्ट करें और एक क्लिक में उसे पठनीय तारीख में बदलें। मिलीसेकंड बनाम सेकंड की गलतियाँ production में जाने से पहले पकड़ें।

हमारा मुफ्त टूल आज़माएं →