मॉड्यूल 14 · API टेस्टिंग

टेस्टर्स के लिए OAuth 2.0 कॉन्सेप्ट्स

Mutqan Soft QA टीम द्वारा · · 17 मिनट · मध्यम

OAuth 2.0 (RFC 6749) किसी application को user का password देखे बिना API तक सीमित access पाने देता है। User एक भरोसेमंद server पर sign in करता है और मंज़ूर करता है कि application क्या कर सकता है; फिर application को एक access token मिलता है जिसमें सिर्फ़ वही permission होती है। RFC का अपना उदाहरण: एक printing service किसी photo-sharing site पर रखी आपकी photos पढ़ती है, वहाँ का आपका password कभी जाने बिना।

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

OAuth के defects security defects होते हैं। जो redirect URI exact match न हो, वह codes किसी attacker तक पहुँचा सकता है; state check न हो तो जाली sign-in स्वीकार हो जाता है; जिस scope को API enforce न करे, वह read access को write access बना देता है; और कभी expire न होने वाला refresh token खोए हुए phone को signed in रखता है। RFC 9700, यानी OAuth security की मौजूदा best practice, इन attacks और उनसे बचाव का वर्णन करता है।

Tester के लिए, एक sign-in browser, client, authorization server और API, चारों से होकर गुज़रता है। Roles और messages की समझ "login काम नहीं करता" को उस exact step और error में बदल देती है जहाँ गड़बड़ हुई।

चार roles और उनके बीच का लेन-देन

RFC 6749 चार roles परिभाषित करता है: resource owner (आम तौर पर user), client (वह application जिसे access चाहिए), authorization server (user को sign in कराता है, consent माँगता है, tokens जारी करता है) और resource server (API)। Confidential client, जैसे back end वाला web app, secret सुरक्षित रख सकता है; public client, जैसे single-page या mobile app, नहीं रख सकता।

  • Authorization code: कम उम्र वाला और सिर्फ़ एक बार इस्तेमाल होने वाला, browser के ज़रिए लौटता है; RFC 6749 अधिकतम 10 मिनट की सलाह देता है।
  • Access token: API को भेजा जाता है, आम तौर पर Bearer token के रूप में, जैसा API authentication वाले lesson में देखा। OAuth इसका format तय नहीं करता: यह JWT भी हो सकता है और opaque string भी।
  • Refresh token: optional और ज़्यादा लंबी उम्र वाला; नए access tokens के लिए सिर्फ़ authorization server को भेजा जाता है, API को कभी नहीं।
  • Scope: appointments.read जैसी permissions। Server माँगे गए से कम scope दे सकता है, और तब उसे दिया गया scope लौटाना ज़रूरी है।

आज़माएँ: OAuth टोकन डिकोडर आज़माएँ: Mock ऑथेंटिकेशन रिस्पॉन्स

PKCE के साथ authorization code flow

Grant वह तरीका है जिससे client tokens पाता है। जब user शामिल हो, तो PKCE (Proof Key for Code Exchange, RFC 7636) के साथ authorization code grant इस्तेमाल करें। User authorization server पर sign in करता है, इसलिए password कभी client तक नहीं पहुँचता। फिर server browser को एक code के साथ client पर वापस redirect करता है; browser से होकर जाने वाला यह हिस्सा front channel है। Client यह code सीधे token endpoint को भेजी गई request में redeem करता है, यही back channel है।

PKCE code को उसी client से बाँधता है जिसने उसे माँगा था। Client एक random code_verifier बनाता है और सिर्फ़ उसका SHA-256 hash, Base64url में encode करके, code_challenge के रूप में (method S256) भेजता है। Hash एक one-way fingerprint है: verifier से इसे कोई भी निकाल सकता है, पर hash से verifier का पता कोई नहीं लगा सकता। Code redeem करते समय client verifier खुद पेश करता है और server जाँचता है कि उसका hash challenge के बराबर है, इसलिए verifier के बिना चोरी हुआ code बेकार है। RFC 9700 public clients के लिए PKCE अनिवार्य करता है और confidential clients के लिए इसकी सलाह देता है।

PKCE के साथ authorization code flow: client hash किया हुआ challenge भेजता है, browser के ज़रिए एक बार इस्तेमाल होने वाला code पाता है, उसे गुप्त verifier के साथ redeem करता है, फिर access token से API call करता है।
  • User और browser resource owner
  • Client app public client
  • Authorization server auth.example.com
  • Resource server API
  1. 1 Client app आंतरिक रूप से: Sign-in शुरू होने पर state और PKCE pair बनाता है code_challenge, code_verifier का Base64url SHA-256 है; verifier client के पास ही रहता है
  2. 2 Client app से Authorization server तक: Authorization request client_id, redirect_uri, scope, state और challenge के साथ GET /authorize?response_type=code…
  3. 3 User और browser से Authorization server तक: Sign in करके scopes approve करता है Password सिर्फ़ authorization server तक जाता है
  4. 4 Authorization server से Client app तक: एक बार इस्तेमाल होने वाले code के साथ redirect जवाब Registered redirect_uri पर, उसी state के साथ 302 /cb?code=…&state=…
  5. 5 Client app आंतरिक रूप से: state को session से मिलाता है
  6. 6 Client app से Authorization server तक: Verifier के साथ code redeem करता है Code, वही redirect_uri और code_verifier भेजता है POST /token
  7. 7 Authorization server आंतरिक रूप से: Code और PKCE pair जाँचता है Code unused और unexpired, वही redirect_uri, verifier का hash challenge के बराबर; वरना invalid_grant
  8. 8 Authorization server से Client app तक: Access token, expiry और optional refresh token जवाब openid माँगा हो तो साथ में ID token
  9. 9 Client app से Resource server तक: Access token के साथ API call करता है Authorization: Bearer …
  10. 10 Resource server आंतरिक रूप से: Token validate करता है Expiry, audience और वह scope जो इस endpoint को चाहिए
  11. 11 Resource server से Client app तक: Data, या इनकार जवाब 200; या 401 और invalid_token, 403 और insufficient_scope

परिणाम: Verifier के बिना चोरी किया code redeem नहीं हो सकता, और password कभी client या API तक नहीं पहुँचता।

क़दम 2 से 4 browser से होकर जाते हैं (front channel); क़दम 6 से 8 client की सीधी request हैं (back channel)। Error वाले रास्ते नहीं दिखाए गए हैं।

  • state: browser session से जुड़ी एक random value जो लौटने पर जाँची जाती है, ताकि जाली callback reject हो।
  • redirect_uri: registered value से exact match किया जाता है। Match न होने पर server error दिखाता है और redirect नहीं करता।
# Front channel: the browser carries the authorization request (wrapped for reading)
GET /authorize?response_type=code&client_id=booking-app
    &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb
    &scope=openid%20appointments.read&state=af0ifjsldkj
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
    &code_challenge_method=S256 HTTP/1.1
Host: auth.example.com

# Front channel: after sign-in and consent, the redirect back with the code
HTTP/1.1 302 Found
Location: https://app.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj

# Back channel: the client redeems the code with the verifier (body wrapped for reading)
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&client_id=booking-app
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

आज़माएँ: SHA-256 जनरेटर

Client credentials, refresh और expiry

जब कोई user शामिल न हो, जैसे रात में चलने वाला reporting job, तो confidential client, client credentials grant इस्तेमाल करता है: वह अपने ही credentials से authenticate करता है और अपनी ही permissions के लिए access token पाता है, आम तौर पर बिना refresh token के।

Access tokens कम उम्र के रखे जाते हैं, ताकि leak हुआ token थोड़ी ही देर काम आए। Expiry पर client grant_type=refresh_token भेजता है, और ऐसा scope नहीं पा सकता जिसे user ने कभी मंज़ूर नहीं किया। Public clients के लिए RFC 9700 ज़रूरी करता है कि refresh tokens sender-constrained हों (यानी cryptographically उसी client instance से बँधे हों, ताकि copy किया हुआ token अकेले बेकार रहे) या rotate हों: rotation में हर refresh एक नया refresh token लौटाता है और पुराने को invalid कर देता है।

# Basic credentials = Base64 of client_id:client_secret (example values from RFC 6749)
POST /token HTTP/1.1
Host: auth.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=reports.read

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"access_token":"2YotnFZFEjr1zCsicMWpAA","token_type":"Bearer",
 "expires_in":900,"scope":"reports.read"}

OpenID Connect संक्षेप में

OAuth 2.0 client को बताता है कि वह किस चीज़ तक पहुँच सकता है, यह नहीं कि user कौन है। OpenID Connect (OIDC) identity जोड़ता है: scope openid के साथ token response में एक ID token भी आता है, यानी client के लिए एक JWT जो बताता है कि किसने sign in किया। इसमें iss, sub (उस issuer पर user की id), aud (client का अपना client_id), exp और, अगर client ने भेजा हो, nonce जैसे claims होते हैं।

Client ID token को वैसे ही validate करता है जैसे JWT गाइड में बताया गया है और उसे अपने पास रखता है; API को सिर्फ़ access token जाता है।

Worked example: booking app का sign-in टेस्ट करना

एक clinic booking app public client है और PKCE व OIDC के साथ authorization code flow इस्तेमाल करता है; उसकी API को appointments की list के लिए appointments.read और booking के लिए appointments.write चाहिए। आप integration को test environment में test users और test client registration के साथ टेस्ट करते हैं, identity provider के अपने product को नहीं। Token endpoint अपनी error value JSON body में लौटाता है; API उसे WWW-Authenticate challenge में लौटाती है (RFC 6750)। ज़्यादातर conditions negative हैं:

  • Sign in करें, approve करें और appointments की list देखें → 200; दिया गया scope वही है जो user ने approve किया।
  • Callback में state बदलें → app उसे reject करता है और कोई session नहीं बनाता।
  • redirect_uri को किसी दूसरे host पर ले जाएँ → error page, कोई redirect नहीं।
  • एक code दो बार redeem करें, या गलत code_verifier भेजें → 400 और invalid_grant।
  • Consent deny करें → app error=access_denied को साफ़ message के साथ handle करता है।
  • Read-only token से booking करें → 403 और insufficient_scope।
  • Expired access token या ID token से API call करें → 401 और invalid_token।
  • Rotation चालू होने पर पुराना refresh token दोबारा इस्तेमाल करें → 400 और invalid_grant, और RFC 9700 के अनुसार सबसे नया refresh token भी revoke हो जाना चाहिए।

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

आम गलतियाँ

  • Access token को इस बात का सबूत मानना कि user कौन है। Identity validate किए गए OIDC ID token से आती है।
  • सिर्फ़ browser में happy path टेस्ट करना, और token endpoint को कभी reused code, गलत verifier या बदले हुए redirect_uri के साथ call न करना।
  • यह जाँचना कि API valid tokens स्वीकार करती है, पर यह नहीं कि वह expired tokens, किसी दूसरी API के लिए जारी tokens या ज़रूरी scope के बिना वाले tokens reject करती है।
  • असली tokens या client secrets को tickets, chats या screenshots में redact किए बिना paste करना।
  • अपने integration की बजाय किसी third-party identity provider पर बिना लिखित अनुमति के security testing करना।

QA का नज़रिया

शुरुआत design review से करें। हर client के लिए पूछें: कौन-सा grant, public या confidential, क्या PKCE enforce होता है, कौन-से redirect URIs registered हैं, किस endpoint को कौन-सा scope चाहिए, tokens कितनी देर valid रहते हैं, और क्या refresh tokens rotate होते हैं। ये जवाब आपका test basis हैं; जिस सवाल का जवाब न मिले, वह खुद एक finding है।

कई expected results code नहीं, configuration होते हैं, इसलिए developers और authorization server के administrator के साथ काम करें। client_id, grant, माँगे गए और दिए गए scopes, endpoint, status, OAuth की error value और request id record करें, और हर token व secret redact करें।

अभ्यास

PKCE pair और token response जाँचें

आपका काम

Test environment में booking app ने नीचे दिए PKCE pair के साथ scope=openid appointments.read माँगा और उसके नीचे वाला token response पाया। Pair verify करें, response review करें और token endpoint के लिए चार negative test conditions लिखें।

सामग्री
code_verifier:  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge: E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM   (method S256)

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ...",
  "token_type": "Bearer",
  "expires_in": 900,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "scope": "openid appointments.read appointments.write profile"
}
चरण
  1. SHA-256 जनरेटर में Base64url output के साथ code_verifier का hash निकालें और उसे code_challenge से मिलाएँ।
  2. दिए गए scope की तुलना माँगे गए scope से करें।
  3. देखें कि openid माँगने पर OpenID Connect response में क्या ज़रूरी करता है।
  4. Token endpoint के लिए चार conditions लिखें, हर एक के expected status और error value के साथ।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Hash challenge के बराबर है, इसलिए pair valid है (यह RFC 7636, Appendix B का उदाहरण है)।

appointments.write और profile दिए गए, जबकि न वे माँगे गए थे न approve हुए थे: यह least privilege का defect है, जब तक कोई documented server policy इसे न समझाए।

openid माँगने के बावजूद id_token नहीं लौटा, इसलिए client नहीं जान सकता कि किसने sign in किया; OpenID Connect इस response में इसे ज़रूरी करता है। expires_in (15 मिनट) और Cache-Control: no-store अपेक्षा के अनुसार हैं।

हर condition में 400, invalid_grant और कोई token न मिलना अपेक्षित है: एक code दो बार redeem करना (फिर जाँचें कि पहले exchange के tokens revoke हुए, जहाँ server यह support करता हो); गलत code_verifier; authorization request से अलग redirect_uri; expired code।

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

क्या OAuth 2.0 एक authentication protocol है?

नहीं। OAuth 2.0 delegated authorization का framework है: यह client को API के लिए access token पाने देता है। यह तय नहीं करता कि client user की पहचान कैसे जाने। OpenID Connect यह काम ID token के ज़रिए जोड़ता है, इसीलिए sign-in features सिर्फ़ OAuth 2.0 पर नहीं, OIDC पर बनने चाहिए।

जब client के पास पहले से client secret है, तो PKCE क्यों?

Secret client को authenticate करता है, पर किसी खास authorization code को उस request से नहीं बाँधता जिससे वह बना। PKCE यह करता है, जिससे attacker चोरी किया हुआ code inject भी नहीं कर पाता। इसलिए RFC 9700 public clients के लिए PKCE अनिवार्य करता है और confidential clients के लिए भी इसकी सलाह देता है।

क्या implicit और password grants अब भी स्वीकार्य हैं?

RFC 9700 कहता है कि implicit grant इस्तेमाल नहीं किया जाना चाहिए और resource owner password credentials grant बिल्कुल इस्तेमाल नहीं किया जाना चाहिए। अगर आपका product अब भी इनमें से किसी पर निर्भर है, तो इसे risk के रूप में record करें और team से PKCE वाले authorization code grant पर migration का plan माँगें।

क्या मैं ये tests किसी public identity provider पर practice कर सकता हूँ?

सिर्फ़ उतना ही जितना वह provider developers को करने देता है, और attack जैसे या भारी volume वाले tests कभी नहीं। Negative और security tests अपने test environment में, test users और test client registration के साथ, या उन systems पर चलाएँ जिन्हें टेस्ट करने की आपके पास लिखित अनुमति है।

संदर्भ

  • 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, सटीक रीडायरेक्ट मिलान, सेंडर-कंस्ट्रेन्ड टोकन।
  • RFC 7636: Proof Key for Code Exchange by OAuth Public ClientsIETF · 2015PKCE: code_verifier और code_challenge (S256) जो OAuth authorization code को उसे माँगने वाले client से बाँधते हैं, ताकि code interception नाकाम हो।
  • OpenID Connect Core 1.0 incorporating errata set 2OpenID Foundation · 2023OAuth 2.0 के ऊपर identity layer: ID Token और उसका validation, authentication flows, standard claims और UserInfo endpoint।
टूल्स

Mutqan tools से अभ्यास करें

OAuth टोकन डिकोडर

OAuth 2.0 / OpenID Connect एक्सेस और ID टोकन डिकोड करें और स्कोप, audience तथा लाइफ़टाइम समझें।

सुरक्षा

SHA-256 जनरेटर

टेक्स्ट का SHA-256 हैश बनाएँ — अखंडता जाँच और सिग्नेचर का मानक।

सुरक्षा

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

किसी endpoint पर Bearer, Basic, API-key और कस्टम-हेडर प्रमाणीकरण टेस्ट करें और अधिकृत बनाम अनधिकृत रिस्पॉन्स की तुलना करें।

API टेस्टिंग

JWT एक्सपायरेशन चेकर

जाँचें कि कोई JWT एक्सपायर हो चुका है, अभी वैध नहीं है, या एक्सपायरी में कितना समय बचा है।

सुरक्षा

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा