मॉड्यूल 13 · HTTP और वेब के मूल सिद्धांत

ऑथेंटिकेशन और ऑथराइज़ेशन

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

Authentication और authorization दो अलग checks हैं जो system किसी request पर काम करने से पहले करता है। Authentication पूछता है "आप कौन हैं?": यह किसी claimed identity को verify करता है, जैसे sign-in पर password और one-time code। Authorization पूछता है "आप क्या कर सकते हैं?": यह तय करता है कि यह identity इस resource पर यह action कर सकती है या नहीं। जब Sara किसी expense app में sign in करती है, तो authentication साबित करता है कि वह Sara है; authorization उसे अपने claims खोलने देता है, लेकिन किसी colleague के नहीं, और न ही वह approval जो उसकी manager का काम है।

Authentication आम तौर पर sign-in पर एक बार होता है और एक proof छोड़ जाता है, जैसे cookies और sessions वाले पाठ की session cookie या कोई token, जो हर अगली request के साथ जाता है; हर request पर server जाँचता है कि यह proof अब भी valid है। Authorization उनमें से हर request पर फिर से चलता है।

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

Access control के defects उन सबसे गंभीर defects में हैं जो tester ढूँढता है। OWASP Top 10:2025 में Broken Access Control पहले नंबर (A01) पर है, और OWASP API Security Top 10 (2023) की शुरुआत Broken Object Level Authorization (API1) से होती है: request में एक id बदलिए और आपको किसी और का data मिल जाता है। Normal इस्तेमाल में ये defects नहीं दिखते, क्योंकि असली users अपने role के लिए बनी screens ही इस्तेमाल करते हैं। इन्हें सिर्फ़ वही test पकड़ता है जो जानबूझकर वह माँगे जो current user को नहीं मिलना चाहिए।

दोनों checks का फ़र्क समझना triage भी तेज़ करता है: 401 और 403 code के अलग हिस्सों और अलग fixes की ओर इशारा करते हैं।

दो checks, हमेशा इसी क्रम में

पहले authentication आता है: user, या कोई calling program, credentials देता है और server उन्हें verify करता है। Authentication factors तीन तरह के होते हैं: कुछ जो आप जानते हैं (password), कुछ जो आपके पास है (one-time code पाने वाला phone, security key) और कुछ जो आप हैं (fingerprint)। Multi-factor authentication (MFA) कम से कम दो अलग तरह के factors जोड़ता है; password के साथ security question अब भी एक ही तरह का factor है। नतीजा एक identity होती है जिस पर server भरोसा करता है, और जो session या token में रखी जाती है।

Authorization दूसरे नंबर पर आता है और उसी identity पर काम करता है। Server कौन पूछ रहा है, कौन-सा action और किस resource पर, इसे एक policy से मिलाता है: role ("managers claims approve करते हैं"), ownership ("employees सिर्फ़ अपने claims पढ़ते हैं") या team या account status जैसे attributes। Public page भी authorization से गुज़रता है; बस उसकी policy anonymous visitors को अनुमति देती है।

  • Deny by default: जिस चीज़ की अनुमति policy साफ़ तौर पर नहीं देती, वह refuse होती है।
  • Least privilege: हर role को सिर्फ़ उतनी permissions मिलती हैं जितनी उसके काम के लिए ज़रूरी हैं।
  • हर request server पर check करें। Button छिपाना access control नहीं है: screen के बिना भी कोई भी request भेज सकता है।
Authentication जाँचता है कि कौन पूछ रहा है और 401 से मना करता है; फिर authorization हर request पर जाँचता है कि यह identity इस resource पर यह action कर सकती है या नहीं, और 403 से मना करता है।

Authenticationपहला check

यह request कौन भेज रहा है?

  1. 1Credentials दिए जाते हैंPassword, one-time code, security key
  2. 2Server उन्हें verify करता है
  3. 3Identity तय होती हैSession cookie या token में रखी जाती है
कब चलता है:
Sign-in पर; बाद की हर request एक proof ले जाती है जिसे server फिर जाँचता है
किस पर आधारित:
Factors: कुछ जो आप जानते हैं, जो आपके पास है या जो आप हैं; MFA दो तरह जोड़ता है
जब मना करता है:
401 Unauthorized, WWW-Authenticate challenge के साथ
आम defect:
बिना valid credential वाली request पूरी हो जाती है
कैसे टेस्ट करें:
कोई credential न भेजकर, और गलत, expired और revoked credentials भेजकर

Authorizationदूसरा check

क्या यह identity इस resource पर यह action कर सकती है?

  1. 1Request identity के साथ आती है
  2. 2Policy जाँची जाती हैRole, ownership, दूसरे attributes
  3. 3Allow या refuseDeny by default
कब चलता है:
हर request पर, server पर
किस पर आधारित:
Policy, जिसमें हर role को least privilege मिले
जब मना करता है:
403 Forbidden, या 404 अगर contract resource छिपाता है
आम defect:
User एक id बदलकर दूसरे user का data पढ़ या बदल लेता है
कैसे टेस्ट करें:
वही request अलग-अलग users और roles से भेजकर

Button छिपाना authorization नहीं है: server को request खुद refuse करनी होगी।

401 या 403: किस check ने मना किया

RFC 9110 हर check को उसका अपना status code देता है। 401 Unauthorized का मतलब है कि request में valid authentication credentials नहीं हैं: भेजे ही नहीं गए, या गलत, expired या revoked हैं। Server को (MUST) WWW-Authenticate header भेजना होता है जिसमें कम से कम एक challenge हो जो बताए कि authenticate कैसे करना है। नाम के बावजूद 401 authentication के बारे में है, और उतना ही उलझाने वाला यह भी है कि credentials ले जाने वाले request header का नाम Authorization है।

403 Forbidden का मतलब है कि server ने request समझी और मना कर दिया। अगर credentials भेजे गए थे, तो server उन्हें काफ़ी नहीं मानता, इसलिए उन्हीं से request दोहराने से कुछ नहीं बदलेगा। RFC 9110 server को यह भी अनुमति देता है कि resource का होना ज़ाहिर न करने के लिए वह उसकी जगह 404 Not Found लौटाए। Contract में लिखा हो तो यह सही है, लेकिन तब छिपे हुए और मौजूद न होने वाले resource को एक जैसा जवाब मिलना चाहिए, वरना यही फ़र्क बता देता है कि कौन-सी ids मौजूद हैं।

# 1. No credentials: authentication fails
GET /api/claims/5531 HTTP/1.1
Host: api.expenses.test

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="expenses"

# 2. Omar's valid token, but claim 5531 is Sara's: authorization fails
GET /api/claims/5531 HTTP/1.1
Host: api.expenses.test
Authorization: Bearer <valid token of Omar>

HTTP/1.1 403 Forbidden

आज़माएँ: HTTP स्टेटस कोड लुकअप आज़माएँ: HTTP हेडर पार्सर

आम schemes एक नज़र में

Scheme वह तरीका है जिससे credential या identity का proof request के साथ जाता है। API testing module हर एक को विस्तार से समझाता है; scheme कोई भी हो, दो सवाल वही रहते हैं: क्या proof valid है (नहीं तो 401), और क्या इस identity को यह करने की अनुमति है (नहीं तो 403)?

  • Session cookie: login form के बाद server session अपने पास रखता है और उसकी id एक cookie में भेजता है, जिसे browser हर request के साथ लौटाता है।
  • Basic authentication (RFC 7617): user-id और password, colon से जुड़े और Base64 में encoded, हर request के Authorization header में। Base64 encryption नहीं है, इसलिए Basic सिर्फ़ HTTPS पर स्वीकार्य है।
  • Bearer token (RFC 6750): एक बार मिला token, जैसे login पर, जो Authorization: Bearer के बाद लिखकर भेजा जाता है। जिसके पास भी हो, वह expire या revoke होने तक उसे इस्तेमाल कर सकता है। कई bearer tokens JSON Web Tokens (JWT, RFC 7519) होते हैं, जिनके readable claims user का नाम और अक्सर उसके roles या scopes बताते हैं।
  • API key: एक लंबी random string जो किसी व्यक्ति को नहीं, calling application को पहचानती है, और API के तय किए header में जाती है। इसका कोई एक standard नहीं है।
  • OAuth 2.0 (RFC 6749) और OpenID Connect: OAuth 2.0 एक authorization framework है जो application को user का password दिखाए बिना सीमित permissions (scopes) वाला access token देता है। OpenID Connect उसके ऊपर identity layer जोड़ता है; "Sign in with…" buttons आम तौर पर इसी पर चलते हैं।

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

Worked example: claim कौन पढ़ और approve कर सकता है

Requirement: "Employees expense claims submit करते हैं और सिर्फ़ अपने claims देखते हैं। Managers अपनी team के claims देखते और approve करते हैं, लेकिन अपने खुद के कभी नहीं। Valid token के बिना API 401 लौटाता है, और जब user को action की अनुमति न हो तो 403।" Test users: Sara (employee, claim 5531 की owner), Omar (employee, दूसरी team) और Lina (Sara की manager, claim 5540 की owner)।

Rows 1 और 2 authentication टेस्ट करती हैं; rows 3 से 8 authorization टेस्ट करती हैं। Row 4 classic object-level test है: row 3 ही, बस दूसरे user के token के साथ; role claims पढ़ सकता है, पर यह claim नहीं। Row 6 function-level test है: employees कोई भी claim approve कर ही नहीं सकते (OWASP API5:2023, Broken Function Level Authorization)। हर refused write के बाद पक्का करें कि कुछ नहीं बदला: row 6 के बाद claim 5531 अब भी "submitted" है, और row 7 के बाद claim 5540 approve नहीं हुआ।

#  Caller               Request                        Expected  What it checks
1  no token             GET  /api/claims/5531          401       authentication
2  Sara, expired token  GET  /api/claims/5531          401       authentication
3  Sara                 GET  /api/claims/5531          200       owner may read
4  Omar                 GET  /api/claims/5531          403       not the owner
5  Lina                 GET  /api/claims/5531          200       manager of the team
6  Sara                 POST /api/claims/5531/approve  403       employees cannot approve
7  Lina                 POST /api/claims/5540/approve  403       never your own claim
8  Lina                 POST /api/claims/5531/approve  200       manager approves

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

आम गलतियाँ

  • हर role को सिर्फ़ उसकी अपनी screens से टेस्ट करना, बजाय वे requests भेजने के जो screens नहीं देतीं, जैसे Omar का Sara का claim माँगना।
  • किसी भी 4xx को स्वीकार कर लेना: token न होने पर WWW-Authenticate के साथ 401 चाहिए, forbidden action पर 403 (या 404 अगर contract resources छिपाता है), और refused write के बाद data बिना बदलाव के रहना चाहिए।
  • यह जाँचना कि button छिपा या disabled है, पर उसके पीछे वाली request कभी न भेजना।
  • एक admin account से टेस्ट करना, जो हर authorization check pass कर लेता है और इसलिए उनमें से किसी को टेस्ट नहीं करता।
  • यह भूल जाना कि rights बदलते हैं: team से हटाए गए या deactivate हुए user का session अब भी खुला हो सकता है।

QA का नज़रिया

Authorization के सवाल refinement के दौरान ही पूछें: कौन-से roles हैं, हर तरह के record का owner कौन है, हर role क्या कर सकता है, और refusal पर कौन-सा status लौटता है। कई teams इसे permission matrix में रखती हैं: rows में roles, columns में actions और हर cell में allow या deny; हर cell एक positive या negative test case बनता है। हर role के test accounts पर जल्दी सहमति बना लें, दूसरी team के user समेत, क्योंकि authorization tests को हमेशा कम से कम दो users चाहिए।

Bug report में check और दोनों identities लिखें: "Omar (employee, team B) को GET /api/claims/5531 पर 200 और Sara का claim मिलता है; expected 403।" Tokens और passwords mask करें। Access control defects की severity अक्सर critical या major रखी जाती है, क्योंकि वे ऐसा data खोलते या बदलते हैं जिस तक user की पहुँच नहीं होनी चाहिए। सिर्फ़ उन्हीं systems को टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की लिखित अनुमति आपके पास है, test accounts से, असली users के credentials से कभी नहीं।

अभ्यास

Classify करें और अनुमान लगाएँ: clinic booking portal

आपका काम

एक clinic portal के तीन roles हैं। Patients सिर्फ़ अपने appointments देखते हैं। Receptionists अपनी clinic के सारे appointments देखते और reschedule करते हैं। Doctors अपने साथ book हुए appointments देखते हैं और उनमें notes जोड़ते हैं। Valid session के बिना API 401 लौटाता है, और जब user को action की अनुमति न हो तो 403।

नीचे की हर request का status code अनुमान लगाएँ और बताएँ कि उसे authentication तय करता है या authorization। फिर दो छूटे हुए test cases जोड़ें।

सामग्री
Setup: appointment 812 = patient Huda, Dr. Faris, North clinic
       Noor = receptionist, North clinic; Rami = receptionist, South clinic
       Ali = another patient

#  Caller                  Request
1  no session              GET   /api/appointments/812
2  Huda                    GET   /api/appointments/812
3  Huda, session expired   GET   /api/appointments/812
4  Ali                     GET   /api/appointments/812
5  Noor                    PATCH /api/appointments/812        (new time)
6  Rami                    PATCH /api/appointments/812        (new time)
7  Dr. Faris               POST  /api/appointments/812/notes
8  Huda                    POST  /api/appointments/812/notes
चरण
  1. Setup lines पढ़ें: appointment 812 का patient कौन है, और वह किस doctor और किस clinic का है?
  2. हर row के लिए पहले पूछें कि caller authenticated है या नहीं, फिर यह कि policy इस resource पर यह action allow करती है या नहीं।
  3. उन roles, actions या states के लिए दो cases जोड़ें जिन्हें list cover नहीं करती।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Rows 1 और 3: 401, authentication (कोई credentials नहीं; expired session)। RFC 9110 हर 401 पर WWW-Authenticate ज़रूरी करता है; अगर यह न हो, तो इसे team के फ़ैसले के लिए deviation के रूप में उठाएँ।

Row 2: 200, authorization अनुमति देता है क्योंकि Huda ही patient है। Row 4: 403, object level पर authorization: Ali authenticated है, पर appointment 812 का patient नहीं।

Row 5: 2xx (आम तौर पर 200, या 204 अगर response में body न हो), authorization अनुमति देता है: Noor उसी clinic में काम करती है। Row 6: 403, object level पर authorization: receptionists reschedule कर सकते हैं, पर Rami दूसरी clinic का receptionist है; इसके बाद पक्का करें कि appointment 812 का time नहीं बदला।

Row 7: 2xx (अगर note resource बनता है तो 201 Created), authorization अनुमति देता है क्योंकि Dr. Faris इस appointment के doctor हैं। Row 8: 403, function level पर authorization: patients notes जोड़ ही नहीं सकते।

छूटे हुए cases, उदाहरण के लिए: कोई दूसरा doctor appointment 812 में note जोड़ता है → 403; session खुला रहते deactivate हुई receptionist request भेजती है → contract के अनुसार 401 या 403; Huda appointment 99999 माँगती है, जो मौजूद नहीं है → 404। ध्यान दें कि मौजूद appointment पर 403 और गायब appointment पर 404 caller को बता देते हैं कि कौन-सी ids मौजूद हैं, इसलिए पूछें कि contract इसे स्वीकार करता है या नहीं।

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

OAuth 2.0 authentication है या authorization?

OAuth 2.0 एक authorization framework है: यह application को सीमित permissions वाला access token देता है। अपने आप यह application को नहीं बताता कि user कौन है। OpenID Connect यह identity layer OAuth 2.0 के ऊपर ID token के ज़रिए जोड़ता है, इसीलिए "Sign in with…" features OpenID Connect इस्तेमाल करते हैं।

जब 401 authentication के बारे में है तो उसका नाम "Unauthorized" क्यों है?

यह नाम HTTP के शुरुआती versions से चला आ रहा है, और RFC 9110 ने इसे बनाए रखा है। असल बात definition है: 401 का मतलब है कि request में valid authentication credentials नहीं हैं, और server को WWW-Authenticate भेजना होता है। 403 का मतलब है कि server ने request समझी और मना कर दिया। नाम पर नहीं, definition पर चलें।

Forbidden resource पर 403 लौटे या 404?

दोनों सही हो सकते हैं। 403 सीधा जवाब है। RFC 9110 server को अनुमति देता है कि resource का होना छिपाने के लिए वह उसकी जगह 404 लौटाए, जैसे दूसरे customers की order ids के लिए। Contract जो कहता है वह टेस्ट करें, और जाँचें कि छिपे हुए और मौजूद न होने वाले resource को बिल्कुल एक जैसा response मिले।

Web app 401 की जगह login page क्यों दिखाता है?

Web app अपना login form दिखाना चाहता है, इसलिए वह anonymous visitor को आम तौर पर 401 लौटाने की जगह login page पर redirect करता है, और बिना rights वाले user को एक friendly "access नहीं है" page दिखाता है। Requirement में लिखा हो तो यह ठीक है। Browser के developer tools से पक्का करें कि ऐसे page के पीछे वाले response में protected data नहीं है।

संदर्भ

  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • OWASP Top 10:2025OWASP Foundation · 2025वेब एप्लिकेशन की दस सबसे गंभीर सुरक्षा जोखिम, हर एक की जाँच और रोकथाम के साथ।
  • OWASP Cheat Sheet Series: AuthorizationOWASP Foundationसही access control: least privilege, deny by default, हर request पर permission जाँच, attribute- या relationship-आधारित मॉडल को प्राथमिकता, और authorization logic का टेस्ट।
  • OWASP API Security Top 10 (2023)OWASP Foundation · 2023API की दस सबसे आम कमज़ोरियाँ: ऑब्जेक्ट-लेवल ऑथराइज़ेशन का टूटना, ऑथेंटिकेशन का टूटना, अनियंत्रित रिसोर्स खपत और अन्य।
टूल्स

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

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

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

API टेस्टिंग

HTTP स्टेटस कोड लुकअप

किसी भी HTTP स्टेटस कोड का अर्थ, RFC संदर्भ और उसे कब इस्तेमाल करना है — सब एक जगह देखें।

वेब

HTTP हेडर पार्सर

कच्चे HTTP रिक्वेस्ट/रिस्पॉन्स हेडर को व्याख्या सहित एक संरचित तालिका में बदलें।

वेब

JWT डिकोडर

JWT का हेडर और पेलोड डिकोड करें, क्लेम जाँचें और एक्सपायरी देखें — पूरी तरह आपके ब्राउज़र में।

सुरक्षा

Base64 डिकोडर

Base64 या Base64url स्ट्रिंग को टेक्स्ट में डिकोड करें, पैडिंग अपने आप ठीक होने के साथ।

एन्कोडिंग

और गहराई से

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

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

इस topic से पहले