Mock ऑथेंटिकेशन रिस्पॉन्स

ब्राउज़र में चलता है मॉकिंग

वास्तविक जैसे auth रिस्पॉन्स बनाएँ (OAuth 2.0 token रिस्पॉन्स, session login, डिकोड होने योग्य unsigned JWT वाला OIDC id_token) और साथ में expired, invalid तथा locked अकाउंट के failure वेरिएंट।

केवल टेस्ट डेटा — सभी जनरेट किए गए नाम, संपर्क, पहचानकर्ता और संख्याएँ कृत्रिम हैं और किसी वास्तविक व्यक्ति या खाते से संबंधित नहीं हैं।
गोपनीयता: यह टूल पूरी तरह आपके ब्राउज़र में चलता है। आपका इनपुट कभी आपके डिवाइस से बाहर नहीं जाता।

टोकन से API ऑथेंटिकेशन कैसे काम करता है?

ज़्यादातर API हर रिक्वेस्ट को हेडर में भेजे गए क्रेडेंशियल से ऑथेंटिकेट करते हैं: बेयरर टोकन (अक्सर OAuth 2.0 फ़्लो से जारी JWT), API की, या TLS पर Basic क्रेडेंशियल। सर्वर हर कॉल पर उसे जाँचता है — सिग्नेचर, एक्सपायरी, ऑडियंस, स्कोप — और गायब या अमान्य होने पर 401 तथा मान्य पर अनुमति न होने पर 403 देता है। ऑथेंटिकेशन टेस्ट करने का मतलब इन सभी रास्तों को आज़माना है, सिर्फ़ हैप्पी पाथ नहीं।

सुरक्षा नोट: टूटा ऑथेंटिकेशन और टूटा ऑब्जेक्ट-लेवल ऑथराइज़ेशन OWASP API सुरक्षा सूची में सबसे ऊपर हैं। जाँचें कि एक्सपायर्ड, छेड़छाड़ किया गया या दूसरे यूज़र का टोकन अस्वीकार होता है, और हर ऑब्जेक्ट id कॉलर के विरुद्ध जाँचा जाता है — सिर्फ़ एंडपॉइंट नहीं।

गाइड पढ़ें: JWT क्या है? JSON Web Token समझें

Mock ऑथेंटिकेशन रिस्पॉन्स कैसे इस्तेमाल करें

  1. चाहें तो यूज़र का ईमेल, scopes और roles डालें।
  2. ढाँचा और नतीजा चुनें (success या कोई failure केस)।
  3. Generate दबाएँ और बॉडी को फ़्रंट-एंड auth mock में इस्तेमाल करें।

Mock ऑथेंटिकेशन रिस्पॉन्स की खूबियाँ

  • OAuth 2.0, OpenID Connect, JWT जोड़ी, session cookie और API key ढाँचे
  • डिकोड होने योग्य unsigned JWT (alg "none") या वास्तविक जैसे claims के साथ mock HS256 signature
  • failure वेरिएंट: invalid credentials, expired token, locked account, unverified email, MFA required
  • सही हेडर: Cache-Control: no-store, WWW-Authenticate, Set-Cookie, Retry-After
  • रिस्पॉन्स के साथ-साथ डिकोड किए हुए claims भी दिखते हैं

Mock ऑथेंटिकेशन रिस्पॉन्स का उदाहरण

OAuth 2.0 token रिस्पॉन्स

इनपुट:

Shape: OAuth 2.0, outcome: success, expires in 3600

आउटपुट:

{
  "access_token": "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiI…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "rt_9kM2…",
  "scope": "openid profile email offline_access"
}

Mock ऑथेंटिकेशन रिस्पॉन्स के बारे में अक्सर पूछे जाने वाले सवाल

कौन-कौन से ढाँचे बनते हैं?

OAuth 2.0 token रिस्पॉन्स, id_token वाले OpenID Connect रिस्पॉन्स, यूज़र ऑब्जेक्ट के साथ JWT access/refresh जोड़ी, Set-Cookie हेडर और CSRF token वाले session login, तथा API key जारी करने वाला रिस्पॉन्स।

क्या ये JWT असली हैं?

ये किसी भी JWT टूल में डिकोड हो जाते हैं और इनमें वास्तविक जैसे claims (iss, sub, aud, iat, exp, scope, roles) होते हैं, लेकिन ये unsecured हैं (alg "none") या इन पर रैंडम mock signature होती है। किसी भी असली सर्वर को इन्हें कभी स्वीकार नहीं करना चाहिए।

कौन-कौन से failure केस मौजूद हैं?

invalid credentials/grant, expired token (401 और WWW-Authenticate), locked account (423 और Retry-After), unverified email (403) तथा MFA required।

क्या मैं यूज़र और scopes तय कर सकता हूँ?

हाँ — ईमेल, scopes और roles दें; नाम सिंथेटिक रहता है। जल्दी जाँच के लिए डिकोड किए हुए claims रिस्पॉन्स के बग़ल में दिखाए जाते हैं।

तकनीकी नोट्स

access और id token को header.payload. के रूप में ख़ाली signature के साथ बनाया जाता है, जिसे RFC 7519 unsecured JWT कहता है, या mock HS256 हेडर माँगने पर रैंडम signature सेगमेंट के साथ। इनमें iss, sub, aud, iat, exp, nbf, jti, scope और roles होते हैं ताकि क्लाइंट-साइड expiry लॉजिक आज़माया जा सके, लेकिन इन्हें कोई असली सर्वर verify नहीं कर सकता।

संदर्भ

  • RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token UsageIETF · 2012बेयरर टोकन कैसे भेजा जाता है (Authorization: Bearer …) और रिसोर्स सर्वर कौन-सी एरर रिस्पॉन्स लौटाता है।
  • RFC 6749: The OAuth 2.0 Authorization FrameworkIETF · 2012OAuth 2.0 की भूमिकाएँ, ग्रांट टाइप और टोकन एंडपॉइंट जो एक्सेस और रिफ़्रेश टोकन जारी करते हैं।
  • RFC 9700: Best Current Practice for OAuth 2.0 SecurityIETF · 2025OAuth 2.0 के लिए वर्तमान सुरक्षा मार्गदर्शन: पब्लिक क्लाइंट के लिए PKCE, सटीक रीडायरेक्ट मिलान, सेंडर-कंस्ट्रेन्ड टोकन।
  • OpenAPI SpecificationOpenAPI InitiativeREST API के वर्णन का मानक: पाथ, ऑपरेशन, पैरामीटर, स्कीमा, रिस्पॉन्स और सिक्योरिटी स्कीम।