ஒரு 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 ("என் password இல்லாமல் App X என் data-ஐப் படிக்க அனுமதி"). App ஒரு flow (உ.ம். Authorization Code) வழியாக ஒரு **access token**-ஐப் பெற்று அதை ஒரு bearer token-ஆக அனுப்புகிறது. "Sign in with Google" மற்றும் third-party integrations இப்படித்தான் வேலை செய்கின்றன.

**JWT (JSON Web Token)** — tokens-க்கான ஒரு பொதுவான *format*: claims (user id, roles, expiry) சுமக்கும் ஒரு signed, self-contained token. Server signature-ஐ verify செய்கிறது — database lookup தேவையில்லை, இது stateless REST-க்குப் பொருந்துகிறது.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## Authorization: scopes மற்றும் roles

Authentication identity-ஐ நிரூபிக்கிறது; **authorization** access-ஐ முடிவு செய்கிறது. Tokens **scopes** (`orders:read`, `orders:write`) அல்லது roles-ஐச் சுமக்கின்றன; server அவற்றை ஒவ்வொரு endpoint-லும் சரிபார்த்து அவை போதவில்லை என்றால் `403 Forbidden`-ஐத் திருப்புகிறது (missing/invalid 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 ஆகும் இடம், எனவே நீங்கள் buzzwords-ஐ ஒப்பிப்பதற்குப் பதிலாக அதைப் பற்றி கட்டமைப்பு ரீதியாகச் சிந்திக்கிறீர்களா என்று பார்க்க interviewers இதைப் பயன்படுத்துகிறார்கள். அவர்கள் தேடும் சமிக்ஞை நீங்கள் **மூன்று அடுக்குகளைப் பிரிக்கிறீர்கள்** — transport (HTTPS, எப்போதும்), authentication (identity-ஐ, stateless-ஆக, bearer tokens/JWT/OAuth வழியாக நிரூபித்தல்), மற்றும் authorization (scopes மற்றும் least privilege) — மேலும் அவற்றைக் குழப்பாதது, உ.ம். "authenticate செய்யப்படவில்லை"-க்கு `401`-ஐயும் "authenticate செய்யப்பட்டது ஆனால் அனுமதிக்கப்படவில்லை"-க்கு `403`-ஐயும் சரியாகப் பயன்படுத்துதல். வலுவான பதில்கள் நடைமுறை trade-offs பற்றிய விழிப்புணர்வைக் காட்டுகின்றன: JWTs வசதியானவை மற்றும் stateless ஆனால் expire ஆகும் முன் revoke செய்வது கடினம் (எனவே குறுகிய lifetimes கூடிய refresh tokens), API keys users-ஐ அல்ல apps-ஐ அடையாளம் காண்கின்றன, மற்றும் users தங்கள் password-ஐ third parties-க்குக் கொடுக்காதிருக்கவே OAuth உள்ளது. அதை REST-இன் statelessness-உடன் இணைப்பது — ஒவ்வொரு request-லும் credentials, server session இல்லை — API security ஏன் இப்படி இருக்கிறது என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள் என்பதைக் காட்டுகிறது.

Transport: எப்போதும் HTTPS

Authentication தேர்வுகள்

Authorization: scopes மற்றும் roles

மற்ற அத்தியாவசியங்கள்

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்