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

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

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

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

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 नहीं कर सकता।