आप एक REST API को कैसे सुरक्षित करते हैं (authentication, authorization, transport)?

Question

IT Interview Practice · Accepted Answer

एक REST API को सुरक्षित करने का मतलब है हर request पर तीन सवालों का जवाब देना: **तुम कौन हो** (authentication), **तुम्हें क्या करने की अनुमति है** (authorization), और **क्या channel निजी है** (transport)। चूँकि REST **stateless** है, credentials को एक server session में रहने के बजाय हर request के साथ यात्रा करनी चाहिए।

## Transport: हमेशा HTTPS

नीचे की हर चीज़ **TLS/HTTPS** मानती है। इसके बिना, tokens और API keys plaintext में यात्रा करते हैं और sniff किए जा सकते हैं। यह गैर-परक्राम्य है — HTTP पर एक bearer token एक लीक हुआ token है।

## Authentication विकल्प

**API keys** — एक header में एक static secret। सरल; server-to-server के लिए और एक *application* की पहचान के लिए अच्छा, एक user की नहीं। अकेले कमज़ोर (कोई expiry नहीं, कोई scope नहीं) जब तक कि और के साथ न जोड़ा जाए।
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — **delegated** access के लिए standard ("App X को मेरा data मेरे password के बिना पढ़ने दो")। App एक flow (उदा. Authorization Code) के ज़रिए एक **access token** प्राप्त करता है और उसे एक bearer token के रूप में भेजता है। "Sign in with Google" और third-party integrations इसी तरह काम करते हैं।

**JWT (JSON Web Token)** — tokens के लिए एक आम *format*: एक signed, स्व-निहित token जो claims (user id, roles, expiry) ले जाता है। Server signature verify करता है — किसी database lookup की ज़रूरत नहीं, जो stateless REST में फिट होता है।
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scopes और roles

Authentication पहचान साबित करता है; **authorization** access तय करता है। Tokens **scopes** (`orders:read`, `orders:write`) या roles ले जाते हैं; server उन्हें प्रति endpoint जाँचता है और अपर्याप्त होने पर `403 Forbidden` लौटाता है (बनाम गायब/अमान्य auth के लिए `401`)।

```text
No/invalid token         → 401 Unauthorized
Valid token, no scope    → 403 Forbidden
```

## अन्य आवश्यकताएँ

```text
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
```

## यह क्यों महत्वपूर्ण है

Security वह जगह है जहाँ एक छोटी गलती एक breach बन जाती है, इसलिए interviewers इसका उपयोग यह देखने के लिए करते हैं कि आप buzzwords दोहराने के बजाय इसके बारे में संरचनात्मक रूप से तर्क करते हैं या नहीं। वे जो संकेत खोजते हैं वह यह है कि आप **तीन परतों को अलग करते हैं** — transport (HTTPS, हमेशा), authentication (पहचान साबित करना, statelessly, bearer tokens/JWT/OAuth के ज़रिए), और authorization (scopes और least privilege) — और आप उन्हें घालमेल नहीं करते, उदा. "authenticated नहीं" के लिए `401` बनाम "authenticated पर अनुमति नहीं" के लिए `403` का सही उपयोग करना। मज़बूत जवाब व्यावहारिक trade-offs की जागरूकता दिखाते हैं: JWTs सुविधाजनक और stateless हैं पर expire होने से पहले revoke करना कठिन (इसलिए short lifetimes साथ refresh tokens), API keys apps की पहचान करती हैं users की नहीं, और OAuth विशेष रूप से इसलिए मौजूद है ताकि users अपना password third parties को न सौंपें। इसे REST की statelessness से जोड़ना — हर request पर credentials, कोई server session नहीं — दिखाता है कि आप समझते हैं कि API security जैसी दिखती है *वैसी क्यों* दिखती है।

Transport: हमेशा HTTPS

Authentication विकल्प

Authorization: scopes और roles

अन्य आवश्यकताएँ

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न