API ऑथेंटिकेशन टेस्टर

सर्वर सहायता API टेस्टिंग

एक ही रिक्वेस्ट क्रेडेंशियल के साथ और बिना (या छेड़छाड़ किए टोकन के साथ) भेजें ताकि पुष्टि हो सके कि API प्रमाणीकरण ठीक से लागू करता है, सही 401/403 कोड लौटाता है और सुरक्षित error बॉडी देता है।

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

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

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

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

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

मैट्रिक्स 401 की दोनों शाखाएँ और मान्य रास्ता जाँचता है; मान्य पर बिना अनुमति वाले कॉलर को 403 मिलता है या नहीं, यह दूसरे यूज़र या रोल के टोकन से अलग से जाँचना होगा।
प्रश्न 1: क्या क्रेडेंशियल वहीं और उसी तरह भेजा गया जैसा API अपेक्षित करता है?सही हेडर या query पैरामीटर, सही scheme, और वैल्यू ख़ाली नहीं

  • उत्तर: नहीं

    परिणाम: 401पंक्तियाँ: No credentials, Empty token, Empty key, Wrong scheme, Key in the wrong place

  • उत्तर: हाँ

    प्रश्न 2: क्या वह मान्य है?सिग्नेचर, एक्सपायरी और ऑडियंस, या key या पासवर्ड का lookup

    • उत्तर: नहीं

      परिणाम: 401पंक्तियाँ: Tampered token, Tampered key, Wrong password, Empty password

    • उत्तर: हाँ

      प्रश्न 3: क्या इस कॉलर को इसकी अनुमति है?स्कोप, और हर ऑब्जेक्ट id की कॉलर के विरुद्ध जाँच

      • उत्तर: नहीं

        परिणाम: 403दूसरे यूज़र या रोल के टोकन से अलग से जाँचें; टूल "Valid credentials" को FAIL दिखाएगामैट्रिक्स में नहीं

      • उत्तर: हाँ

        परिणाम: 2xxपंक्ति: Valid credentials

पंक्तियों के नाम टूल जैसे छापता है वैसे ही हैं; हर रन पाँच पंक्तियाँ भेजता है। "Valid credentials" के सिवा हर पंक्ति 401 या 403 पर PASS, 2xx या 5xx पर FAIL होती है; WWW‑Authenticate के बिना 401 या लीक करती error बॉडी पर warning।

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

  1. endpoint और method डालें, फिर मान्य क्रेडेंशियल।
  2. चाहें तो अतिरिक्त हेडर या रिक्वेस्ट बॉडी जोड़ें।
  3. मैट्रिक्स चलाएँ और तालिका देखें: PASS का मतलब है कि उस वेरिएंट पर API ने सही व्यवहार किया।
  4. पूरा रिस्पॉन्स देखने के लिए पंक्ति खोलें, और Markdown सारांश अपने निष्कर्षों में कॉपी करें।

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

  • एक ही रिक्वेस्ट मान्य, ग़ायब, छेड़छाड़ किए, ख़ाली और ग़लत जगह रखे क्रेडेंशियल के साथ भेजता है
  • हेडर या query पैरामीटर में Bearer टोकन, Basic auth और API key सपोर्ट करता है
  • हर वेरिएंट के लिए फ़ैसला — अपेक्षित बनाम असली स्टेटस, साथ में WWW-Authenticate और जानकारी लीक करती error बॉडी की जाँच
  • हर वेरिएंट का पूरा रिस्पॉन्स खोलकर देखा जा सकता है
  • रिपोर्ट के लिए Markdown सारांश; क्रेडेंशियल कभी स्टोर नहीं होते

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

Bearer से सुरक्षित endpoint

इनपुट:

GET https://httpbin.org/bearer
Bearer token: demo-token-1234567890

आउटपुट:

Valid credentials  200  PASS Accepted (200).
No credentials     401  PASS Rejected with 401.
Tampered token     200  FAIL accepted — authentication is NOT enforced for this case.
Empty token        401  PASS
Wrong scheme       401  PASS

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

मैट्रिक्स क्या-क्या भेजता है?

वही रिक्वेस्ट (1) आपके मान्य क्रेडेंशियल के साथ, (2) बिना क्रेडेंशियल, (3) छेड़छाड़ किए क्रेडेंशियल के साथ, (4) ख़ाली क्रेडेंशियल के साथ और (5) ग़लत scheme या ग़लत जगह रखे क्रेडेंशियल के साथ। हर रिस्पॉन्स की तुलना अपेक्षित 2xx/401/403 से की जाती है।

FAIL का क्या मतलब है?

मान्य क्रेडेंशियल के बिना कोई वेरिएंट स्वीकार कर लिया गया (2xx), मान्य क्रेडेंशियल ठुकरा दिए गए, या ख़राब बने क्रेडेंशियल से 5xx आया। warning ऐसी बातें उजागर करती हैं जैसे WWW-Authenticate हेडर का न होना या बहुत विस्तृत error बॉडी।

क्या मेरे क्रेडेंशियल स्टोर होते हैं?

नहीं। वे सिर्फ़ इसी रन के लिए इस्तेमाल होते हैं और आपकी भेजी गई रिक्वेस्ट के अंदर के अलावा पेज से बाहर कभी नहीं जाते।

क्या मैं query string में API key टेस्ट कर सकता हूँ?

हाँ — API key चुनें और "Add to: Query parameter" सेट करें। मैट्रिक्स key को दूसरी जगह भेजकर भी देखता है।

तकनीकी नोट्स

छेड़छाड़ में secret के आख़िर के पास का एक अक्षर बदल दिया जाता है ताकि signature और lookup फ़ेल हों पर फ़ॉर्मैट भरोसेमंद दिखता रहे। 401/403 रिस्पॉन्स की बॉडी में stack-trace जैसे पैटर्न और असामान्य साइज़ खोजे जाते हैं, जो अक्सर जानकारी लीक होने का संकेत होते हैं।

संदर्भ

  • 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, सटीक रीडायरेक्ट मिलान, सेंडर-कंस्ट्रेन्ड टोकन।