مفاهيم OAuth 2.0 للمختبِرين

لماذا يهم

عيوب OAuth عيوب أمنية. فعنوان إعادة التوجيه (redirect URI) الذي لا يُطابَق بدقة قد يوصل رموز التفويض إلى مهاجم، وغياب فحص state يقبل تسجيل دخول مزوّراً، والنطاق الذي لا تفرضه واجهة API يحوّل صلاحية القراءة إلى صلاحية كتابة، ورمز التحديث الذي لا تنتهي صلاحيته يُبقي هاتفاً مفقوداً مسجَّل الدخول. ويصف RFC 9700، وهو أفضل الممارسات الحالية لأمان OAuth، هذه الهجمات وطرق التصدي لها.

وبالنسبة إلى المختبِر، يعبر تسجيل الدخول الواحد المتصفحَ والعميلَ وخادمَ التفويض وواجهةَ API. ومعرفة الأدوار والرسائل تحوّل بلاغ «تسجيل الدخول لا يعمل» إلى الخطوة الدقيقة التي فشلت والخطأ الذي أعادته.

الأدوار الأربعة وما تتبادله

يعرّف RFC 6749 أربعة أدوار: مالك المورد (Resource Owner) وهو المستخدم عادةً، والعميل (Client) وهو التطبيق الذي يريد الوصول، وخادم التفويض (Authorization Server) الذي يسجّل دخول المستخدم ويطلب موافقته ويُصدر الرموز، وخادم الموارد (Resource Server) وهو واجهة API. والعميل السري (confidential client)، مثل تطبيق ويب له خادم خلفي، يستطيع الاحتفاظ بسرّ؛ أما العميل العام (public client)، مثل تطبيق الصفحة الواحدة أو تطبيق الجوال، فلا يستطيع.

• رمز التفويض (authorization code): قصير العمر ويُستخدم مرة واحدة، ويعود عبر المتصفح؛ ويوصي RFC 6749 بألا يتجاوز عمره ⁦10⁩ دقائق.
• رمز الوصول (access token): يُرسل إلى واجهة API، وغالباً بوصفه رمز حامل (Bearer) كما في درس مصادقة واجهات API. ولا يحدد OAuth صيغته: قد يكون JWT أو سلسلة نصية معتمة (opaque).
• رمز التحديث (refresh token): اختياري وأطول عمراً؛ لا يُرسل إلا إلى خادم التفويض للحصول على رموز وصول جديدة، ولا يذهب أبداً إلى واجهة API.
• النطاق (scope): صلاحيات مثل appointments.read. وقد يمنح الخادم أقل مما طُلب، وعندها يجب أن يعيد النطاق الممنوح.

جرّبها: مفكّك ترميز رموز OAuth جرّبها: استجابة مصادقة وهمية

تدفق رمز التفويض مع PKCE

المنحة (grant) هي الطريقة التي يحصل بها العميل على الرموز. وعند وجود مستخدم، استخدم منحة رمز التفويض مع PKCE (مفتاح الإثبات لتبادل الرمز، Proof Key for Code Exchange، المعرَّف في RFC 7636). يسجّل المستخدم دخوله لدى خادم التفويض، فلا تصل كلمة المرور إلى العميل أبداً. ثم يعيد الخادم توجيه المتصفح إلى العميل ومعه رمز تفويض؛ وهذا الجزء الذي يمر عبر المتصفح هو القناة الأمامية (front channel). ثم يقدّم العميل الرمز في طلب مباشر إلى نقطة نهاية الرموز (token endpoint) ليستبدله برموز، وهذه هي القناة الخلفية (back channel).

تربط PKCE الرمز بالعميل الذي طلبه. ينشئ العميل قيمة عشوائية اسمها code_verifier (قيمة التحقق)، ولا يرسل إلا تجزئتها (hash) بخوارزمية SHA-256 مرمّزةً بـ Base64url بوصفها code_challenge (قيمة التحدي، بالطريقة S256). والتجزئة بصمة باتجاه واحد: يستطيع أي أحد حسابها من قيمة التحقق، لكن لا يستطيع أحد استنتاج قيمة التحقق منها. وعند استبدال الرمز يقدّم العميل قيمة التحقق نفسها، فيتأكد الخادم من أن تجزئتها تساوي قيمة التحدي، فيصبح الرمز المسروق بلا فائدة من دونها. ويشترط RFC 9700 استخدام PKCE للعملاء العامين ويوصي به للعملاء السريين.

• state: قيمة عشوائية مرتبطة بجلسة المتصفح تُفحص عند العودة، فيُرفض أي رد مزوّر إلى عنوان العودة (callback).
• redirect_uri: يُطابَق تطابقاً تاماً مع قيمة مسجّلة مسبقاً. وعند عدم التطابق يعرض الخادم خطأً ولا يعيد التوجيه.

# Front channel: the browser carries the authorization request (wrapped for reading)
GET /authorize?response_type=code&client_id=booking-app
    &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb
    &scope=openid%20appointments.read&state=af0ifjsldkj
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
    &code_challenge_method=S256 HTTP/1.1
Host: auth.example.com

# Front channel: after sign-in and consent, the redirect back with the code
HTTP/1.1 302 Found
Location: https://app.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj

# Back channel: the client redeems the code with the verifier (body wrapped for reading)
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&client_id=booking-app
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

جرّبها: مولّد SHA-256

بيانات اعتماد العميل والتحديث وانتهاء الصلاحية

عند غياب المستخدم، كمهمة تقارير ليلية، يستخدم العميل السري منحة بيانات اعتماد العميل (Client Credentials): يُثبت هويته ببيانات اعتماده الخاصة ويتلقى رمز وصول لصلاحياته هو، ودون رمز تحديث في العادة.

تكون رموز الوصول قصيرة العمر حتى لا يفيد الرمز المسرَّب إلا لوقت قصير. وعند انتهاء صلاحيته يرسل العميل grant_type=refresh_token، ولا يستطيع الحصول على نطاق لم يوافق عليه المستخدم. وللعملاء العامين يشترط RFC 9700 أن تكون رموز التحديث مقيّدة بالمرسِل (sender-constrained)، أي مربوطة تشفيرياً بنسخة العميل تلك فلا تنفع نسخة مسروقة منها وحدها، أو مُدوَّرة: ومع التدوير (rotation) يعيد كل تحديث رمز تحديث جديداً ويُبطل القديم.

# Basic credentials = Base64 of client_id:client_secret (example values from RFC 6749)
POST /token HTTP/1.1
Host: auth.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=reports.read

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"access_token":"2YotnFZFEjr1zCsicMWpAA","token_type":"Bearer",
 "expires_in":900,"scope":"reports.read"}

OpenID Connect باختصار

يخبر OAuth 2.0 العميلَ بما يحق له الوصول إليه، لا بهوية المستخدم. ويضيف OpenID Connect (اختصاراً OIDC) طبقة الهوية: مع النطاق openid تحمل استجابة الرموز أيضاً رمز هوية (ID Token)، وهو JWT موجّه إلى العميل يذكر من سجّل الدخول، بمطالبات مثل iss وsub (معرّف المستخدم لدى تلك الجهة المُصدِرة) وaud (معرّف العميل نفسه client_id) وexp، وnonce إن أرسله العميل.

يتحقق العميل من رمز الهوية كما يشرح دليل JWT ويحتفظ به لنفسه؛ ولا يذهب إلى واجهة API إلا رمز الوصول.

مثال تطبيقي: اختبار تسجيل الدخول في تطبيق حجز

تطبيق لحجز مواعيد عيادة هو عميل عام يستخدم تدفق رمز التفويض مع PKCE وOIDC؛ وتتطلب واجهته البرمجية appointments.read لعرض المواعيد وappointments.write للحجز. أنت تختبر التكامل في بيئة الاختبار بمستخدمي اختبار وبتسجيل العميل الخاص بالاختبار، لا منتجَ مزوّد الهوية نفسه. وتعيد نقطة نهاية الرموز قيمة error في جسم JSON، بينما تعيدها واجهة API في تحدي WWW-Authenticate كما يحدد RFC 6750. ومعظم شروط الاختبار سلبية:

• سجّل الدخول ووافق واعرض المواعيد ← 200، والنطاق الممنوح scope يساوي ما وافق عليه المستخدم.
• عدّل state في عنوان العودة ← يرفضه التطبيق ولا ينشئ جلسة.
• وجّه redirect_uri إلى مضيف آخر ← صفحة خطأ ولا إعادة توجيه.
• استخدم رمز التفويض نفسه مرتين، أو أرسل code_verifier خاطئاً ← 400 مع invalid_grant.
• ارفض الموافقة ← يعالج التطبيق error=access_denied برسالة واضحة.
• احجز برمز للقراءة فقط ← 403 مع insufficient_scope.
• استدعِ واجهة API برمز وصول منتهي الصلاحية أو برمز الهوية ← 401 مع invalid_token.
• مع تفعيل التدوير، أعد استخدام رمز تحديث قديم ← 400 مع invalid_grant، ويتوقع RFC 9700 أن يُبطَل أحدث رمز تحديث أيضاً.

جرّبها: مختبِر مصادقة API جرّبها: فاحص انتهاء صلاحية JWT

أسئلة شائعة

المراجع

• RFC 6749: The OAuth 2.0 Authorization FrameworkIETF · 2012أدوار OAuth 2.0 وأنواع المنح ونقاط نهاية الرموز التي تُصدر رموز الوصول والتحديث.
• RFC 9700: Best Current Practice for OAuth 2.0 SecurityIETF · 2025إرشادات الأمان الحالية لـ OAuth 2.0: استخدام PKCE للعملاء العامين ومطابقة عناوين إعادة التوجيه بدقة وتقييد الرموز بالمرسل.
• RFC 7636: Proof Key for Code Exchange by OAuth Public ClientsIETF · 2015آلية PKCE: قيمتا code_verifier وcode_challenge (بطريقة S256) اللتان تربطان رمز التفويض في OAuth بالعميل الذي طلبه، فتُحبطان اعتراض الرمز.
• OpenID Connect Core 1.0 incorporating errata set 2OpenID Foundation · 2023طبقة الهوية فوق OAuth 2.0: رمز الهوية (ID Token) وكيفية التحقق منه، وتدفقات المصادقة، والمطالبات القياسية، ونقطة UserInfo.