API ऑथेंटिकेशन

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · मध्यम

API authentication वह तरीका है जिससे API तय करता है कि request किसने भेजी। Client और API के बीच कोई login screen नहीं होती, इसलिए client हर request के साथ एक credential जोड़ता है — API key, user-id और password (Basic) या token (Bearer) — और server सबसे पहले उसे जाँचता है। GET /v1/orders/9021 call करने वाला mobile app Authorization: Bearer mF_9.B5f-4.1JqM भेजता है; valid token पर API 200 देता है और missing या invalid token पर 401।

यह पाठ बताता है कि तीन आम schemes क्या भेजती हैं, credential कहाँ जा सकता है, और कैसे टेस्ट करें कि API बाकी सब reject करता है। कोई जाना-पहचाना caller क्या कर सकता है — यानी authorization — वह इस module में आगे आता है।

यह क्यों ज़रूरी है

जो endpoint credential check छोड़ देता है, वह अपना data और actions हर उस व्यक्ति को सौंप देता है जो उस तक पहुँच सके। Normal use में यह कमी नहीं दिखती, क्योंकि असली clients हमेशा valid token भेजते हैं; इसे सिर्फ़ वही test पकड़ता है जो जानबूझकर missing, गलत या expired credential भेजे। OWASP API Security Top 10 (2023) में Broken Authentication API2 के रूप में दर्ज है।

Credentials चुपचाप भी leak होते हैं: URL में रखी key access logs में पहुँचती है, screenshot में दिखा Basic header पढ़ा जा सकने वाला password है, और logout के बाद भी चलने वाला token उसे copy करने वाले के काम आता रहता है। हर scheme को समझना test team को खुद leak का ज़रिया बनने से बचाता है।

API key, Basic और Bearer: हर एक क्या भेजता है

ज़्यादातर APIs तीन schemes में से एक इस्तेमाल करते हैं, और contract बताता है कि कौन-सी। OpenAPI document में securitySchemes या तो type: apiKey दिखाता है, साथ में वह header (या query parameter) जिसमें key जाती है, या scheme: basic या scheme: bearer के साथ type: http, जो standard Authorization header इस्तेमाल करते हैं।

तीनों request header में जाते हैं और कोई भी खुद को सुरक्षित नहीं रखता: जो header copy कर ले, वह request दोबारा भेज सकता है, इसलिए हर scheme HTTPS पर निर्भर है।

API key: client application को दी गई लंबी random string, जो API के चुने हुए header में जाती है, जैसे X-API-Key। इसका कोई एक standard नहीं है। Key किसी व्यक्ति को नहीं, call करने वाली application को पहचानती है — OWASP कहता है कि API keys API clients के authentication के लिए हैं, users के लिए नहीं — और आम तौर पर rotate (नई key से बदलना) या revoke होने तक valid रहती है।
Basic authentication (RFC 7617): client user-id और password को colon से जोड़ता है, नतीजे को Base64 में encode करता है और Basic के बाद भेजता है। Base64 encoding है, encryption नहीं: नीचे की value decode होकर qa.tester:S4mple-pass बनती है। Password हर request के साथ जाता है और बदले जाने तक काम करता है; RFC TLS के बिना इस scheme को सुरक्षित नहीं मानता।
Bearer token (RFC 6750): client पहले token हासिल करता है, जैसे login endpoint या OAuth 2.0 authorization server से, और उसे Bearer के बाद भेजता है। Bearer token जिसके भी पास हो, वह उसे इस्तेमाल कर सकता है, इसलिए RFC short-lived tokens (एक घंटा या कम) की सलाह देता है जो उसी API तक सीमित हों जिसके लिए बने हैं। कई bearer tokens JWT होते हैं, जिन्हें इस module में आगे समझाया गया है।

API key, Basic और Bearer तीनों request header में जाते हैं, पर copy की गई key revoke होने तक चलती है, Basic value decode होकर password बन जाती है, और bearer token expire होने तक चलता है।

API keyकोई एक standard नहीं

Client application को दी गई लंबी random string, API के बताए header में

X-API-Key: demo_7Hq2LmZ9pR4tKx

किसे पहचानता है:: Call करने वाली application, व्यक्ति नहीं
अगर कोई इसे copy कर ले:: Key rotate या revoke होने तक उसके लिए काम करती है
401 के साथ challenge:: कोई standard challenge नहीं: contract तय करता है
पहले negative tests:: Missing, revoked, query string में भेजी गई

Basic authenticationRFC 7617

user-id:password, Base64 में encoded, Basic के बाद

Authorization: Basic cWEudGVzdGVyOlM0bXBsZS1wYXNz

किसे पहचानता है:: वह user जिसका user-id और password इसमें है
अगर कोई इसे copy कर ले:: Decode करने पर password मिलता है, जो बदलने तक काम करता है
401 के साथ challenge:: WWW-Authenticate: Basic realm="api"
पहले negative tests:: गलत password, अनजान user, दोनों पर एक ही error message

Bearer tokenRFC 6750

पहले हासिल किया token, Bearer के बाद; जिसके भी पास हो, वह इस्तेमाल कर सकता है

Authorization: Bearer mF_9.B5f-4.1JqM

किसे पहचानता है:: वह user या client जिसे यह जारी हुआ
अगर कोई इसे copy कर ले:: Expire या revoke होने तक उसके लिए काम करता है
401 के साथ challenge:: WWW-Authenticate: Bearer realm="orders"
पहले negative tests:: Missing, एक character बदला हुआ, expired, logout के बाद इस्तेमाल

उदाहरण की values इस पाठ के लिए गढ़ी गई हैं। Request देखने वाला कोई भी इन तीनों में से किसी को दोबारा भेज सकता है, इसलिए हर एक को HTTPS चाहिए।

पाठ संस्करण

API key:  X-API-Key: demo_7Hq2LmZ9pR4tKx
Basic:    Authorization: Basic cWEudGVzdGVyOlM0bXBsZS1wYXNz
Bearer:   Authorization: Bearer mF_9.B5f-4.1JqM

आज़माएँ: Base64 डिकोडर आज़माएँ: Base64 एन्कोडर

Credentials कहाँ जाते हैं: header में, URL में कभी नहीं

URL में रखा credential ऐसी जगहों पर copy हो जाता है जिन्हें कोई सुरक्षित नहीं रखता: server और proxy के access logs, monitoring tools, browser history, और हर ticket जहाँ कोई link paste कर दे। RFC 9110 चेतावनी देता है कि कई servers, proxies और browsers target URI को log या display करते हैं, इसलिए उसमें संवेदनशील जानकारी नहीं होनी चाहिए, और sender को http व https URLs में user:password@ डालने से मना करता है; RFC 6750 कहता है कि bearer token query parameter में नहीं भेजा जाना चाहिए (SHOULD NOT), जब तक कोई और रास्ता न हो; और OWASP URL में tokens और passwords को broken authentication मानता है।

Tester के लिए नियम: credential header में, HTTPS पर जाता है, और न error message में वापस आता है, न log में लिखा जाता है। अगर API उसे query string में भी स्वीकार करता है, तो उसे risk के रूप में report करें, भले ही वह "काम करता" हो।

# Leaks: the key is part of the URL and is written to access logs
GET /v1/products?api_key=demo_7Hq2LmZ9pR4tKx HTTP/1.1
Host: api.shop.test

# Expected: the key travels in a header, over HTTPS
GET /v1/products HTTP/1.1
Host: api.shop.test
X-API-Key: demo_7Hq2LmZ9pR4tKx

आज़माएँ: API हेडर बिल्डर आज़माएँ: cURL जनरेटर

हर protected endpoint पर क्या टेस्ट करें

जैसा "ऑथेंटिकेशन और ऑथराइज़ेशन" वाले पाठ में देखा, RFC 9110 में valid credentials के बिना आई request को WWW-Authenticate challenge के साथ 401 मिलता है, और जिस request को server समझकर मना करता है उसे 403। API में यह challenge इस्तेमाल होने वाली scheme बताता है, जैसे WWW-Authenticate: Basic realm="api" या WWW-Authenticate: Bearer realm="orders", जहाँ realm protected क्षेत्र का नाम है। API keys का कोई standard challenge नहीं है, इसलिए contract तय करता है। जाने-पहचाने caller के लिए 403 authorization का फ़ैसला है, जिसका अपना पाठ है; नीचे के cases सिर्फ़ authentication जाँचते हैं।

Missing: कोई credential नहीं → challenge के साथ 401।
Malformed या गलत scheme: खाली value, बिना token के Bearer, Bearer-only API को भेजा गया Basic → 401, 500 कभी नहीं। RFC 6750 को मानने वाला contract malformed Bearer header पर इसकी जगह error="invalid_request" के साथ 400 भी दे सकता है।
Invalid: गलत password, अनजान user, एक character बदली हुई key या token → 401।
Expired या revoked: expiry के बाद का token, revoke की गई key, logout के बाद इस्तेमाल हुआ token जब contract कहता है कि logout उसे revoke करता है → 401।
गलत जगह: query string में या किसी दूसरे header नाम के तहत credential → reject।
हर endpoint और method: protected GET उसी path के DELETE के बारे में कुछ साबित नहीं करता, न अभी भी deployed पुराने API versions के बारे में।
सुरक्षित errors: अनजान user और गलत password के लिए एक ही message, कोई stack trace नहीं, और credential response में कभी वापस नहीं।

आज़माएँ: API ऑथेंटिकेशन टेस्टर

Worked example: Bearer tokens वाला orders endpoint

Contract: "GET और DELETE /v1/orders/{id} के लिए Authorization: Bearer <token> ज़रूरी है। Token जारी होने के 30 मिनट बाद expire होता है और logout पर revoke होता है। Missing या invalid token पर 401 लौटता है।" Test user A के साथ, कुछ भी भेजने से पहले हर case और उसका expected जवाब लिखें:

Rows 5 और 6 के लिए timing और logout चाहिए। Row 5 token की 30 मिनट की lifetime पर 2-value boundary value analysis लागू करती है: 30 मिनट पहली expired value है, और 29 मिनट पुराना token, यानी आख़िरी valid value, अब भी 200 लौटाना चाहिए। अगर server घड़ियों के फ़र्क़ के लिए कोई grace period देता है, तो contract में वह लिखा होना चाहिए। Row 9 state भी जाँचती है: 401 देकर भी order delete कर देना defect है। User B का token A के order पर authorization test है, जो आगे के एक पाठ में आता है। Fail हुई row की bug report में exact request, मिला status और headers, और expected जवाब लिखें, credential को mask करके।

#  Request to /v1/orders/9021 (A's order)    Expected
1  GET, valid token of user A                200, order JSON
2  GET, no Authorization header              401, WWW-Authenticate: Bearer realm="orders"
3  GET, Authorization: Bearer (empty value)  401
4  GET, token with last character changed    401, error="invalid_token" in the challenge
5  GET, token issued 30 minutes ago          401, error="invalid_token" in the challenge
6  GET, token of A after A logged out        401
7  GET, Authorization: Basic (A's password)  401, challenge names Bearer
8  GET, valid token in ?access_token=        401; if accepted, report it as a risk
9  DELETE, no Authorization header           401, and order 9021 still exists

आज़माएँ: API ऑथेंटिकेशन टेस्टर आज़माएँ: cURL जनरेटर

आम गलतियाँ

सिर्फ़ valid token के साथ happy path टेस्ट करना और मान लेना कि endpoint protected है।
Base64 को सुरक्षा समझना: log या screenshot में दिखा Basic header पढ़ा जा सकने वाला password है।
कोई भी 4xx स्वीकार कर लेना: 401 और 403 के मतलब अलग हैं, और 401 के साथ WWW-Authenticate होना चाहिए।
सिर्फ़ GET जाँचना, और write methods व पुराने API versions भूल जाना।
असली tokens, keys या passwords को mask किए बिना bug reports, chat या shared collections में paste करना।
Expiry और revocation कभी टेस्ट न करना, जिससे logout के बाद भी चलने वाला token नज़र से छूट जाता है।

QA का नज़रिया

Authentication के सवाल contract review में आते हैं: कौन-सी scheme, कौन-सा header, token कितनी देर चलता है, logout क्या करता है, 401 कैसा दिखता है। जब OpenAPI document इनमें से कुछ भी खुला छोड़ दे तो developer से पूछें, और तय करें कि हर environment में कौन-से test accounts और keys QA के पास हैं।

हर test में credential का type और इस्तेमाल हुआ account लिखें, secret कभी नहीं, और test keys को team के secret store या environment variables में रखें। जो endpoint valid credential के बिना request स्वीकार करे, उसे security defect के रूप में report करें, आम तौर पर Critical या Blocker severity के साथ। Authentication tests सिर्फ़ उन systems पर चलाएँ जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है।

अभ्यास

Authentication test log की समीक्षा करें

आपका काम

एक साथी ने worked example वाले orders API पर उसी contract के साथ authentication tests चलाए और नीचे का log सेव किया।

हर row के लिए तय करें कि API ने सही व्यवहार किया या नहीं, और हर defect के लिए बताएँ कि क्या expected था और वह कितना गंभीर है।

सामग्री

Orders API, test environment, endpoint /v1/orders/9021
#  Method and credential                   Status  Observed
1  GET, valid token of user A              200     order JSON
2  GET, no Authorization header            401     WWW-Authenticate: Bearer realm="orders"
3  GET, token with last character changed  200     order JSON
4  GET, token of A after A logged out      200     order JSON
5  GET, Authorization: Basic               500     stack trace in the body
      cWEubGVhZDpXaW50ZXItVGVhLTQy
6  GET, ?access_token=<valid token of A>   200     order JSON
7  DELETE, no Authorization header         204     empty body
8  GET, token issued 35 minutes ago        401     no WWW-Authenticate header

चरण

Contract और RFC 9110 से हर row का expected result लिखें।
हर row को सही या defect के रूप में चिह्नित करें।
Row 5 की value को Base64 decoder से decode करें और लिखें कि खुद log के लिए इसका क्या मतलब है।
Defects को severity के क्रम में लगाएँ और सबसे गंभीर defect के लिए bug title लिखें।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

Rows 1 और 2 सही हैं।

Row 3, Critical: expected था error="invalid_token" के साथ 401, पर बदला हुआ token स्वीकार हुआ, यानी tokens validate नहीं होते और कोई भी गढ़ा हुआ token चल सकता है। Row 4, Major: expected 401 था, पर logout token को revoke नहीं करता, जो contract के ख़िलाफ़ है।

Row 5, Major: expected है WWW-Authenticate: Bearer के साथ 401, न कि stack trace leak करने वाला 500। Value decode होकर qa.lead:Winter-Tea-42 बनती है, यानी log खुद एक test password उजागर करता है: logs और reports में credentials mask करें, और यह password बदलवाएँ।

Row 6, Major: expected 401 था, पर token URL में स्वीकार हुआ, जहाँ access logs उसे रख लेते हैं। Contract सिर्फ़ header बताता है और RFC 6750 SHOULD NOT कहता है, इसलिए इसे security defect या team के फ़ैसले के लिए risk के रूप में report करें।

Row 7 सबसे गंभीर है, Blocker या Critical: बिना पहचान वाली DELETE सफल हो गई। पुष्टि करें कि order 9021 हट गया है, फिर यह title report करें: "DELETE /v1/orders/{id} बिना Authorization header के order delete कर देता है और 401 की जगह 204 लौटाता है"।

Row 8: reject करना सही है, लेकिन RFC 9110 हर 401 के साथ WWW-Authenticate माँगता है, इसलिए यह Minor defect है। सुझाया गया क्रम: 7, 3, 4, 6, 5, 8।

अक्सर पूछे जाने वाले सवाल

क्या APIs के लिए Basic authentication अब भी ठीक है?

सिर्फ़ HTTPS पर, और ज़्यादातर server-to-server calls या internal tools के लिए। Password हर request के साथ जाता है और सिर्फ़ Base64 में encoded होता है, इसलिए एक leaked request या एक log line उसे उजागर कर देती है। कई teams ऐसे tokens या keys पसंद करती हैं जिन्हें किसी व्यक्ति का password बदले बिना revoke किया जा सके।

Credential न होने पर 401 लौटे या 403?

401, जैसा "ऑथेंटिकेशन और ऑथराइज़ेशन" वाला पाठ समझाता है। Bearer API के लिए RFC 6750 दोनों तरह के 401 को अलग भी करता है: जिस request में कोई credential नहीं भेजा गया, उसके challenge में error code नहीं होना चाहिए, और जिस request का token expired, revoked या invalid है, उसके challenge में error="invalid_token" होना चाहिए। इसलिए expired token का test सिर्फ़ status नहीं, challenge भी जाँचता है।

क्या user data बचाने के लिए API key काफ़ी है?

आम तौर पर अकेले नहीं। Key call करने वाली application को पहचानती है, उसे इस्तेमाल करने वाले व्यक्ति को नहीं, और वह लंबे समय तक चलती है। OWASP API Security Top 10 (2023) कहता है कि API keys API clients के authentication के लिए हैं, users के लिए नहीं; user data के लिए user authentication चाहिए, आम तौर पर token के ज़रिए।

Bearer token और JWT में क्या फ़र्क़ है?

"Bearer" बताता है कि token कैसे इस्तेमाल होता है: जिसके पास है, वह उसे पेश कर सकता है। JWT token के content का एक format है। Bearer token JWT भी हो सकता है और ऐसी random string भी जिसे सिर्फ़ server अपने records में देखकर पहचानता है। JWT guide यह format समझाती है।

संदर्भ

RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token UsageIETF · 2012बेयरर टोकन कैसे भेजा जाता है (Authorization: Bearer …) और रिसोर्स सर्वर कौन-सी एरर रिस्पॉन्स लौटाता है।
RFC 7617: The 'Basic' HTTP Authentication SchemeIETF · 2015Basic ऑथेंटिकेशन Authorization हेडर में user-id:password कैसे एन्कोड करता है, और उसे TLS की ज़रूरत क्यों है।
RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।