ASP.NET Core / المتوسط: البيانات والهوية والعمل غير المتزامن / الدرس 9

مخططات المصادقة وحدود الثقة

تحقق من الهوية عبر مخطط مهيأ، مع الفصل بين إنشاء الادعاءات، وحماية نقاط النهاية، وأمن المتصفح.

وقت القراءة التقريبي: 5 دقيقةتاريخ مراجعة المحتوى 2026-10-26

في هذه الصفحة

أهداف الدرس

اشرح معالجات المصادقة ومخططاتها وإنشاء كائن الفاعل الأمني.
ميّز ملفات الارتباط والرموز الحاملة وطلب المصادقة ورفض الوصول.
تجنب الثقة بحقول الهوية التي يرسلها العميل.

تحتاج الادعاءات إلى مسار إنشاء موثوق

تثبت المصادقة الهوية عبر معالج ومخطط مهيأين. كائن ClaimsPrincipal هو النتيجة التي يستهلكها التحقق اللاحق من الصلاحيات، وليس مجرد وجوده دليلا على صحة الهوية. إن أنشأت ادعاءات من ترويسة أو جسم طلب عشوائيين، فسيمكن العميل من اختراع السلطة، ما لم تثبتها عملية تحقق موثوقة.

يحدد المخطط المعالج والخيارات المستخدمة للأفعال المتعلقة بالمصادقة. يحتاج تعدد المخططات إلى سياسة مقصودة للاختيار والقيم الافتراضية. لا يعني تسجيل المصادقة وحده اشتراط حماية كل نقطة نهاية؛ فبيانات الصلاحيات الوصفية والبرمجيات الوسيطة أو السياسة الاحتياطية هي التي تحدد متطلبات الوصول. افصل التحقق من الهوية عن قرارات الصلاحية.

يختبر الفاعل الأمني في الذاكرة التمثيل، لا الثقة بالرمز

ينشئ البرنامج الكامل هوية مصادقا عليها اصطناعية على نحو صريح، ثم يقرأ ادعاء منها. يوضح سلوك ClaimsIdentity ويوفر بيانات مفيدة لاختبارات السياسات. لا يتحقق من JWT، أو ملف ارتباط، أو جهة إصدار، أو توقيع، أو انتهاء صلاحية، أو جمهور، ولا يصادق على مستخدم فعلي. يجب ألا يعاد استخدام تجهيز الاختبار للتحقق من اعتمادات الإنتاج.

اضبط نوع المصادقة عن قصد في الهوية الاصطناعية حتى لا تعتمد الاختبارات عرضا على القيم الافتراضية لـIsAuthenticated. اختبر الادعاءات وربط ادعاءات الدور والاسم عندما تعتمد الصلاحيات عليها. لا تساوي سلسلة اسمها admin في حمولة غير موثوقة ادعاء دور جاء عبر مسار موثوق.

csharp فحص فاعل أمني اصطناعي عن قصد

using System;
using System.Security.Claims;

var identity = new ClaimsIdentity(new[] { new Claim("scope", "reports.read") }, authenticationType: "synthetic");
var principal = new ClaimsPrincipal(identity);
Console.WriteLine($"authenticated={principal.Identity?.IsAuthenticated} scope={principal.FindFirst("scope")?.Value}");

الناتج المتوقع

authenticated=True scope=reports.read

يجعل نوع المصادقة المعيّن هوية الاختبار مصادقا عليها؛ ولا يُتحقق من أي اعتماد.

يحتاج إعداد الرمز الحامل إلى خيارات ثقة مكتملة

يوضح المقتطف غير القابل للتشغيل مخططا مسمى للرمز الحامل، بجهة إصدار وجمهور مختلقين. يحتاج إلى الحزمة المناسبة، وإعداد المضيف، وسياسة جهة الإصدار، واختبارات التكامل؛ ولا تُجلب هنا حزمة أو بيانات وصفية بعيدة. يجب أن يفحص تحقق الرمز متطلبات الثقة ومدة الصلاحية الموثقة، لا أن يكتفي بفك حمولة JSON داخل الرمز.

تمثل ملفات الارتباط تفاعلا مختلفا مع العميل، وتحتاج إلى حماية ونقل ومدة صلاحية ومفاتيح توقيع أو تشفير وتعامل مناسب من المتصفح. في ASP.NET Core 10، تعيد نقاط API المعروفة التي تستخدم مصادقة ملفات الارتباط 401 أو 403، بدلا من التحويل التلقائي إلى صفحة تسجيل الدخول أو رفض الوصول، وفقا للسلوك الموثق. وتبقى للصفحات التفاعلية عقودها الخاصة.

csharp تسجيل توضيحي لمخطط الرمز الحامل

builder.Services.AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options =>
    {
        options.Authority = "https://issuer.example.invalid";
        options.Audience = "example-api";
    });

لا يُنفّذ هذا المقتطف؛ ولا تُجلب حزمة أو بيانات جهة إصدار، ولا يُستخدم رمز أو يُتصل بخدمة هوية بعيدة.

يعبّر طلب المصادقة ورفض الوصول عن فشلين مختلفين

يدعو طلب المصادقة، أو challenge، المستدعي الذي لم تثبت هويته إلى المصادقة وفقا للمخطط المختار. أما رفض الوصول، أو forbid، فيعالج حالة مستدع ثبتت هويته لكنه يفتقد الصلاحية. يعتمد سلوك HTTP الناتج على المخطط ونقطة النهاية. لا تستبدل الحالتين بجسم نجاح عام، ولا تعتمد على تحويل الصفحة دليلا على حماية API.

CORS سياسة للمتصفح تحدد إتاحة الاستجابات عبر الأصول، وليست مصادقة أو تحققا من الصلاحيات. تحتاج الطلبات القائمة على ملفات الارتباط أيضا إلى تصميم لمنع CSRF أو تزوير الطلبات حيث ينطبق، لأن المتصفح قد يرفق الاعتمادات تلقائيا. ولواجهات الرموز الحاملة مخاطر مختلفة تتعلق بالعميل وتخزين الرمز. اختر الآلية المدعومة انطلاقا من العميل الفعلي ونموذج التهديد.

اختبر حد الثقة عبر تكامل مدعوم

اختبر الاعتمادات الغائبة والمشوهة والمنتهية وذات جهة الإصدار أو الجمهور الخاطئين، وكذلك الصحيحة، باستخدام تجهيز هوية معزول ومعتمد، لا حسابات فعلية. اختبر اختيار المخطط، وربط الادعاءات، وchallenge وforbid، وسلوك ملفات الارتباط مع API، وحجب الحساس من السجلات. يفيد تجهيز ClaimsPrincipal المباشر لاختبارات وحدات الصلاحيات، لكنه لا يستبدل فحوص المصادقة هذه.

أبعد مواد التوقيع والتشفير والرموز الفعلية عن المصدر والصور والروابط والسجلات والأمثلة. وثّق تدوير المفاتيح، والإلغاء ومدة الصلاحية، وافتراضات الوكيل وTLS والنشر. لا تنفذ الدورة تسجيل دخول أو اتصال هوية خارجيا أو إصدار رمز أو مسار مصادقة مهيأ؛ ويظل الإعداد غير المنفذ موسوما بأنه غير قابل للتشغيل.

الأخطاء الشائعة وإصلاحها

تُعامل حمولة رمز مفكوكة كهوية ثبتت مصادقتها.

لماذا يحدث؟: اختلط التحليل بالتحقق من التوقيع والثقة ومدة الصلاحية.
كيف تصلحه؟: استخدم معالج المصادقة المدعوم والمهيأ وسياسة الثقة المحددة.
كيف تتجنب تكراره؟: اختبر جهة إصدار وجمهورا وتوقيعا وانتهاء صلاحية غير صالحين.

يُفترض أن تسجيل المصادقة يحمي كل نقطة نهاية.

لماذا يحدث؟: اختلط إثبات الهوية بمتطلبات الصلاحية.
كيف تصلحه؟: طبّق سياسة صلاحية صريحة على نقطة النهاية أو سياسة احتياطية.
كيف تتجنب تكراره؟: اختبر نقطة نهاية لا يُقصد السماح فيها بالوصول المجهول.

تُستخدم CORS آلية للتحكم في الوصول إلى API.

لماذا يحدث؟: اعتُبرت سياسة استجابة المتصفح نظاما للصلاحيات.
كيف تصلحه؟: افرض التحقق من الهوية والصلاحيات على الخادم.
كيف تتجنب تكراره؟: اختبر، من حيث التصميم، مستدعين لا يخضعون لسلوك CORS في المتصفح.

اختبر فهمك

1. لماذا لا يثبت تجهيز ClaimsPrincipal الذي يحمل IsAuthenticated=True أن رمزا فعليا صالح؟

اعرض الحل المشروح

أنشأت شيفرة الاختبار هذا التجهيز، وهو لا يتضمن دليلا تشفيريا أو دليلا على جهة الإصدار أو مدة الصلاحية. يمكنه التحقق من تعامل نظام الصلاحيات مع ادعاءات معلومة، لكن المصادقة تحتاج إلى المعالج المهيأ وخيارات الثقة ضمن اختبار تكامل معزول. أبق هذا النطاق واضحا، ولا تنشئ هوية إنتاج مباشرة من ادعاءات يرسلها العميل دون تحقق.

2. يستطيع متصفح استدعاء API من أصل مسموح. ما أسئلة الهوية والأمن التي تبقى؟