كيف تُؤمّن REST API (المصادقة، الترخيص، النقل)؟

Question

IT Interview Practice · Accepted Answer

تأمين REST API يعني الإجابة عن ثلاثة أسئلة في كل طلب: **من أنت** (authentication)، و**ما المسموح لك بفعله** (authorization)، و**هل القناة خاصة** (transport). ولأن REST **stateless**، يجب أن تسافر الاعتمادات (credentials) مع كل طلب لا أن تعيش في session خادم.

## النقل: HTTPS دائمًا

كل ما يلي يفترض **TLS/HTTPS**. فبدونه، تسافر الـ tokens والـ API keys بنص صريح ويمكن تنصّتها. هذا غير قابل للتفاوض — bearer token عبر HTTP هو token مُسرَّب.

## خيارات المصادقة

**API keys** — سرّ ثابت في header. بسيط؛ جيّد لـ server-to-server ولتعريف *تطبيق*، لا مستخدم. ضعيف بمفرده (بلا انتهاء، بلا scope) ما لم يُقرَن بأكثر.
```http
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
```

**OAuth 2.0** — المعيار للوصول **المفوَّض (delegated)** ("دع التطبيق X يقرأ بياناتي دون كلمة مروري"). يحصل التطبيق على **access token** عبر تدفّق (مثل Authorization Code) ويرسله كـ bearer token. هكذا تعمل "Sign in with Google" وتكاملات الطرف الثالث.

**JWT (JSON Web Token)** — *صيغة* شائعة للـ tokens: token موقّع مكتفٍ ذاتيًّا يحمل ادّعاءات (claims) (user id، roles، انتهاء). يتحقّق الخادم من التوقيع — دون الحاجة لبحث في قاعدة بيانات، ما يلائم REST الـ stateless.
```text
header.payload.signature   (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
```

## الترخيص: scopes وroles

المصادقة تثبت الهوية؛ و**الترخيص (authorization)** يقرّر الوصول. تحمل الـ tokens **scopes** (`orders:read`، `orders:write`) أو roles؛ يفحصها الخادم لكل endpoint ويُرجع `403 Forbidden` حين لا تكفي (مقابل `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
```

## لماذا يهم

الأمن هو حيث يصير خطأ صغير اختراقًا، لذا يستخدم المُقابِلون هذا ليروا إن كنت تعلّل حوله بنيويًّا لا تُردّد كلماتٍ طنّانة. الإشارة التي يبحثون عنها أنك **تفصل الطبقات الثلاث** — النقل (HTTPS دائمًا)، والمصادقة (إثبات الهوية، بلا حالة، عبر bearer tokens/JWT/OAuth)، والترخيص (scopes وleast privilege) — وألّا تخلطها، مثل استخدام `401` بشكل صحيح لـ "غير موثَّق" مقابل `403` لـ "موثَّق لكن غير مسموح له". الإجابات القوية تُظهر وعيًا بالمفاضلات العملية: الـ JWTs مريحة وبلا حالة لكن يصعب إبطالها قبل انتهائها (ومن هنا الأعمار القصيرة إضافةً إلى refresh tokens)، والـ API keys تعرّف تطبيقات لا مستخدمين، وOAuth موجود تحديدًا لئلّا يسلّم المستخدمون كلمة مرورهم لطرف ثالث. وربطه بـ statelessness في REST — اعتمادات في كل طلب، بلا session خادم — يُظهر أنك تفهم *لماذا* يبدو أمن الـ API على ما هو عليه.

النقل: HTTPS دائمًا

خيارات المصادقة

الترخيص: scopes وroles

أساسيات أخرى

لماذا يهم

أسئلة ذات صلة