JWT access-token validation: SaaS implementation guide
हर SaaS API request से पहले JWT access token को explicit algorithm और trusted key से verify करें; फिर issuer, audience, expiry, token purpose और resource authorization जाँचें।
इस मार्गदर्शिका में
SaaS API को JWT access token कैसे validate करना चाहिए?
JWT सिर्फ इसलिए भरोसेमंद नहीं हो जाता कि उसका format सही है या claims विश्वसनीय दिखते हैं। Maintained library में स्वीकार्य algorithm और trusted verification key स्पष्ट करें, signature जाँचें, फिर API के लिए जरूरी issuer, audience, समय-सीमा और token purpose validate करें। इसके बाद requested resource पर authorization करें। Signed JWT सामान्यतः उसे रखने वाला व्यक्ति पढ़ सकता है; signature payload को encrypt नहीं करता।
स्वीकार्य algorithm तय करें और trusted key source का उपयोग करें
Verifier को उन्हीं algorithms के लिए configure करें जिन्हें issuer और application वास्तव में support करते हैं; untrusted token को कमजोर या अनपेक्षित verification तरीका चुनने न दें। Keys trusted configuration या issuer के authenticated key set से लें। Token header के `kid` को केवल उस trusted set में lookup hint मानें; token में दिए मनमाने key URL से key fetch न करें।
Issuer, audience, समय-सीमा और token profile जाँचें
`iss` को expected issuer और `aud` को इसी API या service से मिलाएँ। Expiration और not-before नियम लागू करें तथा clock tolerance बहुत छोटी और आवश्यक रखें। Claim types, जरूरी scopes और client context validate करें। Access token को ID token या किसी अन्य JWT प्रकार से अलग पहचानें और identity provider द्वारा तय token profile का पालन करें।
Token verification के बाद requested action की permission जाँचें
सही signature यह बताती है कि स्वीकार्य issuer ने claims sign किए; इससे हर tenant या record पर unrestricted access नहीं मिलता। Verified subject, client, scopes और tenant context को वर्तमान access policy से मिलाएँ, फिर specific object और operation जाँचें। Identity या tenant अस्पष्ट हो तो client के भेजे ID से access अनुमान लगाने के बजाय request अस्वीकार करें।
| API या token profile | स्वीकृत issuer और audience | स्वीकृत algorithms और trusted keys | जरूरी claims और lifetime | Authorization और negative test |
|---|---|---|---|---|
| Customer API | ||||
| Background service | ||||
| Administrative endpoint |
JWT validation policy में क्या-क्या तय होना चाहिए?
अलग token types के validation नियम अलग रखें
ID token आम तौर पर client को authenticated user की जानकारी देने के लिए होता है; access token resource server के लिए जारी होता है। जब तक लागू profile स्पष्ट रूप से न कहे, एक को दूसरे की जगह स्वीकार न करें। Cross-purpose token confusion रोकने के लिए endpoint या trust boundary के अनुसार token type, issuer, audience और जरूरी claims तय करें।
Key rotation, clock tolerance और emergency response की योजना बनाएँ
Issuer signing keys को कैसे publish, cache, rotate और retire करता है, यह जानें। Provider के documented तरीके से trusted keys refresh करें, unknown key ID को सुरक्षित ढंग से संभालें और rotation के दौरान overlap test करें। Clock drift छिपाने के लिए validity अनिश्चित समय तक न बढ़ाएँ। Key या issuer compromise हो तो क्या करना है, यह लिखें।
Sensitive claims कम रखें और revocation की सीमा समझें
Token में password, secret या गैरज़रूरी personal data न रखें; holder सामान्यतः payload decode कर सकता है। Self-contained token expiry तक valid रह सकता है, जब तक system revocation state या कोई दूसरा control न जाँचे। जोखिम के अनुसार expiry तय करें और session, refresh-token तथा account revocation के साथ जोड़ें; signed token अपने-आप वापस नहीं लिया जा सकता।
Team JWT handling को end-to-end कैसे जाँचे?
स्वीकृत token और हर महत्वपूर्ण rejection case test करें
Valid token के साथ invalid signature, अनपेक्षित algorithm, गलत issuer, गलत audience, expired token, भविष्य का not-before claim, गलत claim type, unknown key ID और गलत token purpose के cases बनाएँ। पक्का करें कि हर स्थिति में API protected data या state change किए बिना request reject करे।
सही signature पर भी कम permission वाले tokens जाँचें
ठीक से signed token में सीमित scope, किसी दूसरे tenant का subject या target object की अनुमति न हो तो उसे फिर भी deny होना चाहिए। Read, update, bulk और administrative actions जाँचें। Test fixtures में वास्तविक issuer और key-rotation behavior दर्शाएँ, लेकिन production secrets को tests या CI logs में न कॉपी करें।
Bearer credentials log किए बिना verifier के फैसले देखें
जहाँ उपयोगी हो, सुरक्षित reason category, issuer identifier, key version, endpoint और outcome दर्ज करें; पूरा bearer token कभी log न करें। बार-बार failures और issuer-key retrieval समस्याएँ देखें। Identity provider config, JWT library, token profile या signing keys बदलने पर validation tests फिर चलाएँ।
JWT access-token के सवाल
क्या JWT decode कर लेना request authenticate करने के लिए पर्याप्त है?
नहीं। Decode करने से claims केवल पढ़े जाते हैं। Trusted key और allowed algorithm से signature verify करें, token profile व claims जाँचें, फिर requested action authorize करें।
क्या JWT claims अपने-आप encrypted होते हैं?
नहीं। Signed JWT payload आम तौर पर token रखने वाला पढ़ सकता है। जानबूझकर उपयुक्त encryption profile उपयोग न हो तो इसमें secret या गैरज़रूरी personal data न डालें।
क्या हर API और web client में एक ही JWT इस्तेमाल कर सकते हैं?
Token का audience, issuer और purpose जाँचे बिना उसे स्वीकार न करें। हर API के लिए अपेक्षित resource और token profile तय करें ताकि किसी अन्य client या service का token बदला न जा सके।
Stateless JWT को expiry से पहले revoke कैसे करें?
पूरी तरह stateless verifier के पास automatic revocation lookup नहीं होता। जरूरत के अनुसार short lifetime, high-risk actions पर revocation/session check या issuer का दूसरा तरीका अपनाएँ; response speed और availability का trade-off देखें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .