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 એ leak થયેલ token છે.

## Authentication વિકલ્પો

**API keys** — header માં એક static secret. સરળ; server-to-server માટે અને user નહીં પણ *application* ને ઓળખવા સારું. પોતાની રીતે નબળા (કોઈ expiry નહીં, કોઈ scope નહીં) સિવાય કે વધુ સાથે જોડાય.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — **delegated** access માટેનું standard ("App X ને મારા password વગર મારો data વાંચવા દો"). App એક flow (દા.ત. Authorization Code) દ્વારા **access token** મેળવે છે અને તેને bearer token તરીકે મોકલે છે. "Sign in with Google" અને third-party integrations આ રીતે કામ કરે છે.

**JWT (JSON Web Token)** — tokens માટેનું સામાન્ય *format*: signed, self-contained 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
કોઈ/અમાન્ય token         → 401 Unauthorized
માન્ય token, કોઈ scope નહીં → 403 Forbidden
```

## અન્ય આવશ્યકતાઓ

```text
✓ Short-lived access tokens + refresh tokens (leak થાય તો blast radius મર્યાદિત કરો)
✓ Rate limiting (429) brute-force અને દુરુપયોગ ને બુઠ્ઠું કરવા
✓ બધા input ને validate/sanitize કરો; ક્યારેય client પર વિશ્વાસ ન કરો
✓ scopes પર least privilege નો સિદ્ધાંત
```

## આ શા માટે મહત્વનું છે

Security એ છે જ્યાં નાની ભૂલ breach બની જાય છે, તેથી interviewers આનો ઉપયોગ એ જોવા કરે છે કે તમે buzzwords ગોખવાને બદલે તેના વિશે માળખાગત રીતે તર્ક કરો છો કે નહીં. તેઓ જે સંકેત શોધે છે તે એ છે કે તમે **ત્રણ layers ને અલગ કરો** — transport (HTTPS, હંમેશા), authentication (ઓળખ સાબિત કરવી, statelessly, bearer tokens/JWT/OAuth દ્વારા), અને authorization (scopes અને least privilege) — અને તમે તેમને ભેળવતા નથી, દા.ત. "authenticated નથી" માટે `401` વિરુદ્ધ "authenticated પણ પરવાનગી નથી" માટે `403` નો સાચો ઉપયોગ. મજબૂત જવાબો વ્યવહારુ trade-offs ની જાગૃતિ દર્શાવે છે: JWTs સગવડભર્યા અને stateless છે પણ expire થાય તે પહેલાં revoke કરવા અઘરા (તેથી ટૂંકા 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

અન્ય આવશ્યકતાઓ

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો