19 أبريل 2025·8 دقيقة
كيف تتعامل الأطر الحديثة مع المصادقة والتفويض
تعرف كيف تتعامل الأطر الحديثة مع المصادقة والتفويض: الجلسات، الرموز، OAuth/OIDC، middleware/حراس، الأدوار والسياسات، ومخاطر الأمن الشائعة.
تعرف كيف تتعامل الأطر الحديثة مع المصادقة والتفويض: الجلسات، الرموز، OAuth/OIDC، middleware/حراس، الأدوار والسياسات، ومخاطر الأمن الشائعة.
المصادقة تجيب على «من أنت؟» التفويض يجيب على «ما الذي يحق لك فعله؟» تتعامل الأطر الحديثة معهما كمخاوف مترابطة لكن منفصلة، وهذه الفصلية تساعد في الحفاظ على ثبات الأمان مع نمو التطبيق.
المصادقة تدور حول إثبات أن مستخدمًا (أو خدمة) هو من يدّعي أنه. الأطر عادة لا تقيدك بطريقة واحدة؛ بل توفر نقاط توسع لخيارات شائعة مثل تسجيل الدخول بكلمة المرور، تسجيل الدخول عبر شبكات التواصل/الخدمات، SSO، مفاتيح واجهة برمجة التطبيقات، وبيانات اعتماد للخدمات.
ناتج المصادقة هو هوية: معرف مستخدم، حالة الحساب، وأحيانًا سمات أساسية (مثل ما إذا كان البريد مُؤكَّدًا). والأهم: المصادقة لا تقرر ما إذا كانت العملية مسموحة—فقط تُحدِّد مَن يقوم بالطلب.
التفويض يستخدم الهوية المثبتة بالإضافة إلى سياق الطلب (المسار، مالك المورد، القِطاع، النطاقات، البيئة، إلخ) ليقرر ما إذا كانت العملية مسموحة. هنا توجد الأدوار، الأذونات، السياسات، وقواعد الموارد.
تفصل الأطر قواعد التفويض عن المصادقة حتى تتمكن من:
تطبّق معظم الأطر القواعد عبر نقاط مركزية في دورة حياة الطلب:
حتى لو اختلفت المسميات، فالمكوّنات الأساسية مألوفة: مخزن الهوية (المستخدمون وبيانات الاعتماد)، جلسة أو رمز يحمل الهوية بين الطلبات، وmiddleware/guards التي تطبّق المصادقة والتفويض بشكل متسق.
الأمثلة هنا مفهومية حتى تتمكن من مطابقتها مع الإطار الذي تختاره.
قبل أن يتمكن الإطار من «تسجيل الدخول»، يحتاج إلى مكانين: مكان للبحث عن بيانات الهوية (مخزن الهوية) وطريقة متسقة لتمثيل تلك الهوية في الكود (نموذج المستخدم). كثير من ميزات المصادقة في الأطر الحديثة هي تجريدات حول هذين الجزئين.
تدعم الأطر عادةً عدة خلفيات، مدمجة أو عبر إضافات:
الفرق الأساسي هو من هو مصدر الحقيقة. مع مستخدمي قاعدة البيانات، يملك تطبيقك بيانات الاعتماد وبيانات الملف الشخصي. مع IdP أو دليل، غالبًا ما يخزن تطبيقك «مستخدمًا ظليًا محليًا» يربط بالهوية الخارجية.
حتى عندما يُولِّد الإطار نموذجًا افتراضيًا للمستخدم، توحِّد الفرق عادةً بضعة حقول:
is_verified, is_active, is_locked, deleted_at.تهم هذه العلامات لأن المصادقة ليست مجرد «هل كلمة المرور صحيحة؟»—بل أيضًا «هل مسموح لهذا الحساب بتسجيل الدخول الآن؟»
مخزن الهوية العملي يدعم أحداث دورة الحياة الشائعة: التسجيل، التحقق من البريد/الهاتف، إعادة تعيين كلمة المرور، إبطال الجلسات بعد تغييرات حساسة، والتعطيل أو الحذف الناعم. الأطر توفر غالبًا بدائل (رموز، طوابع زمنية، نقاط تمديد)، لكن عليك تحديد القواعد: نوافذ الانتهاء، حدود المعدّل، وماذا يحدث للجلسات الحالية عند تعطيل الحساب.
توفر معظم الأطر نقاط امتداد مثل user providers, adapters, أو repositories. هذه المكونات تحول «بمعطى معرف تسجيل دخول، احضر المستخدم» و«بمعطى معرف مستخدم، حمِّل المستخدم الحالي» إلى مخزنك المختار—سواء كان استعلام SQL، استدعاء إلى IdP، أو بحث في دليل مؤسسي.
المصادقة القائمة على الجلسة هي النهج «الكلاسيكي» الذي تظل العديد من أطر الويب تعتمد عليه—خاصة لتطبيقات SSR. الفكرة بسيطة: الخادم يتذكر من أنت، والمتصفح يحمل مؤشر صغير لذاك التذكر.
بعد تسجيل دخول ناجح، ينشئ الإطار سجل جلسة على الخادم (غالبًا معرف جلسة عشوائي مرتبط بمستخدم). يتلقى المتصفح كوكي يحتوي هذا المعرف. في كل طلب، يرسل المتصفح الكوكي تلقائيًا، ويستخدم الخادم هذا المعرف لتحميل المستخدم المسجل.
نظرًا لأن الكوكي مجرد معرف (وليس بيانات المستخدم نفسها)، يبقى المحتوى الحساس على الخادم.
تحاول الأطر الحديثة جعل كوكيات الجلسة أصعب للسرقة أو سوء الاستخدام من خلال افتراضات أمنة:
ستجد هذه الإعدادات غالبًا تحت "إعدادات كوكي الجلسة" أو "رؤوس الأمان".
تتيح الأطر عادةً اختيار مخزن الجلسة:
عموما، المقايضة بين السرعة مقابل الديمومة مقابل تعقيد التشغيل.
تسجيل الخروج قد يعني شيئين:
تُنفذ الأطر غالبًا "تسجيل الخروج في كل مكان" عبر تتبع "نسخة الجلسة" للمستخدم أو عبر تخزين عدة معرفات جلسات لكل مستخدم وإبطالها. إذا احتجت تحكمًا أقوى (إبطال فوري)، فالمصادقة القائمة على الجلسة أسهل لأن الخادم يمكنه ببساطة نسيان الجلسة فورًا.
المصادقة بالرموز تستبدل بحث الجلسة الخادمي بسلسلة يقدمها العميل في كل طلب. توصي الأطر عادةً بالرموز عندما يكون الخادم API يُستخدم من عملاء متعددة، أو عندما لديك تطبيقات موبايل، أو SPA يتحدث إلى backend منفصل، أو عندما تحتاج خدمات لاستدعاء بعضها البعض بدون جلسات المتصفح.
الرمز هو سند وصول يُصدر بعد تسجيل الدخول (أو بعد تدفق OAuth). يرسله العميل لاحقًا حتى يستطيع الخادم المصادقة على المتصل ثم تفويض الإجراء. تتعامل معظم الأطر مع ذلك كنمط أساسي: نقطة نهاية "إصدار رمز"، middleware للتحقق من الرمز، وحراس/سياسات تعمل بعد تحديد الهوية.
الرموز المظلمة هي سلاسل عشوائية بلا معنى للعميل (مثال: tX9...). يتحقق الخادم منها عبر بحث في قاعدة بيانات أو ذاكرة مؤقتة، مما يجعل الإبطال مباشرًا ويُبقي محتوى الرمز خاصًا.
JWTs (JSON Web Tokens) هي مُهيكلة وموقعة. عادةً تحتوي على مطالبات مثل معرف المستخدم (sub)، المصدر (iss)، الجمهور (aud)، أوقات الإصدار/الانتهاء (iat, exp)، وأحيانًا أدوار/نطاقات. هام: JWTs مُرمَّزة وليست مُشفّرة افتراضيًا—أي من يحمل الرمز يمكنه قراءة مطالبه، حتى لو لم يستطع تزويره.
إرشادات الأطر عادةً توصي بإفتراضيين آمنين:
Authorization: Bearer <token> لواجهات الـ API. هذا يقلل مخاطر CSRF لأن الكوكيز لا تُرسل تلقائيًا، لكنه يرفع متطلبات الدفاع ضد XSS لأن جافاسكربت يمكنه قراءة وإرفاق الرموز.HttpOnly, Secure, وSameSite، وعندما تكون مستعدًا للتعامل مع CSRF بشكل صحيح (عادةً مصاحَبًا برموز CSRF منفصلة).تُحفظ رموز الوصول قصيرة العمر. ولتجنب إجبار المستخدمين على إعادة تسجيل الدخول باستمرار، تدعم العديد من الأطر refresh tokens: سند طويل العمر يُستخدم فقط لصكّ رموز وصول جديدة.
هيكلة شائعة:
POST /auth/login → يعيد access token (و refresh token)POST /auth/refresh → يدور refresh token ويعيد access token جديدPOST /auth/logout → يبطل refresh tokens على الخادمالتدوير (إصدار refresh جديد كل مرة) يحد من الضرر إذا سُرق refresh token، وتوفر الأطر غالبًا نقاط وصل لتخزين معرفات الرموز، اكتشاف إعادة الاستخدام، وإبطال الجلسات بسرعة.
يُذكر OAuth 2.0 وOpenID Connect (OIDC) معًا غالبًا، لكن الأطر تتعامل مع كلٍ منهما بشكل مختلف لأن كلًّا منهما يحلّ مشكلة مختلفة.
استخدم OAuth 2.0 عندما تحتاج وصولًا مفوضًا: تطبيقك يحصل إذنًا لاستدعاء API نيابة عن المستخدم (مثل قراءة تقويم أو النشر على مستودع) دون التعامل مع كلمة مرور المستخدم.
استخدم OpenID Connect عندما تحتاج تسجيل دخول/هوية: تطبيقك يريد معرفة من هو المستخدم ويتلقى ID token مع مطالبات هوية. عمليًا، "تسجيل الدخول عبر X" عادةً يكون OIDC فوق OAuth 2.0.
تركز معظم الأطر ومكتبات المصادقة فيها على تدفقين:
توفر تكاملات الأطر عادةً مسار رد نداء (callback) وmiddleware مساعد، لكن لا تزال تحتاج إلى تكوين الأساسيات بشكل صحيح:
تقوم الأطر عادةً بتطبيع بيانات المزود إلى نموذج مستخدم محلي. القرار التصميمي الأساسي هو ما الذي يقود التفويض فعليًا:
نمط شائع: اربط معرفًا ثابتًا (مثل sub) بمستخدم محلي، ثم ترجم الأدوار/المجموعات/المطالبات من المزود إلى أدوار محلية أو سياسات يتحكم بها تطبيقك.
ما زالت كلمات المرور الطريقة الافتراضية لتسجيل الدخول في العديد من التطبيقات، لذلك تميل الأطر إلى شحن أنماط تخزين أكثر أمانًا وواجهات للممارسات الشائعة. القاعدة الأساسية ثابتة: لا تخزن كلمة المرور بنص واضح (أو حتى تجزئة بسيطة) في قاعدة البيانات.
تفترض الأطر الحديثة ومكتبات المصادقة فيها استخدام مجزئات كلمات مرور مخصصة مثل bcrypt, Argon2, أو scrypt. هذه الخوارزميات بطيئة متعمدة وتضيف salt، مما يساعد على منع هجمات الجداول المحسوبة ويجعل كسرها مكلفًا على نطاق واسع.
تجزئة سريعة مثل SHA-256 غير مناسبة لكلمات المرور لأنها مصممة لتكون سريعة؛ إذا سُرقت قاعدة البيانات، تتيح التجزئات السريعة للمهاجمين تجربة مليارات التخمينات بسرعة. المجزئات المخصصة تضيف معاملات تكلفة (work factors) لتتمكن من ضبط الأمان مع تحسن الأجهزة.
توفر الأطر عادة نقاط إضافة لفرض قواعد معقولة دون ترميزها في كل نقطة نهاية:
تدعم معظم المنظومات إضافة المصادقة متعددة العوامل كخطوة ثانية بعد التحقق من كلمة المرور:
إعادة تعيين كلمة المرور طريق هجوم شائع، لذا تشجع الأطر أنماطًا مثل:
قاعدة جيدة: سهل الاسترداد للمستخدمين الشرعيين، لكن مكلف للهجوم الآلي.
تتعامل معظم الأطر الحديثة مع الأمان كجزء من خط معالجة الطلب: سلسلة خطوات تعمل قبل (وأحيانًا بعد) المتحكم/المدير. تختلف المسميات—middleware, filters, guards, interceptors—لكن الفكرة متسقة: كل خطوة يمكنها قراءة الطلب، إضافة سياق، أو إيقاف المعالجة.
تدفق نموذجي:
/account/settings).تشجع الأطر على إبقاء فحوصات الأمان خارج منطق الأعمال، حتى تظل المتحكمات مركزة على "ماذا تفعل" بدلًا من "من يمكنه فعلها".
المصادقة هي الخطوة التي يثبت فيها الإطار سياق المستخدم من الكوكيز، معرفات الجلسة، مفاتيح API، أو رموز Bearer. إذا نجحت، تخلق هوية نطاق الطلب—غالبًا معروضة ككائن user, principal, أو context.auth.
هذا الإرفاق مهم لأن المراحل التالية (وكود التطبيق) لا ينبغي أن تعيد تحليل الرؤوس أو التحقق من الرموز. يجب أن يقرأوا كائن المستخدم المُزود، والذي عادةً يتضمن:
يُنفَّذ التفويض عادةً كـ:
النوع الثاني يشرح لماذا غالبًا ما تجلس خطافات التفويض قرب المتحكمات والخدمات: قد تحتاج إلى معرّفات المسار أو كائنات محملة من قاعدة البيانات لاتخاذ قرار صحيح.
تفصل الأطر بين حالتين شائعتين:
تجنَّب تسريب التفاصيل في ردود 403؛ ارفض الوصول دون شرح أي قاعدة فشلت.
يجيب التفويض على سؤال أضيق من تسجيل الدخول: "هل يمكن لهذا المستخدم المسجل فعل هذا الشيء تحديدًا الآن؟" تدعم الأطر الحديثة عادةً عدة نماذج، وكثير من الفرق تجمع بينها.
RBAC يعيّن للمستخدم أدوارًا (مثل admin, support, member) ويقيد الميزات بناءً على هذه الأدوار.
سهل الفهم والتطبيق، خاصة عندما توفر الأطر مساعدات مثل requireRole('admin'). لكن التسلسلات الهرمية للأدوار قد تُخفي امتيازًا: تغيير صغير في دور أب قد يمنح وصولًا واسعًا ضمن التطبيق.
RBAC يعمل بشكل جيد للتمييزات العامة والثابتة.
التحقق القائم على الأذونات يقارن فعلًا ضد مورد، عادةً على الشكل:
read, create, update, delete, inviteinvoice, project, user، أحيانًا مع ID أو حالة الملكيةهذا النموذج أكثر دقة من RBAC؛ على سبيل المثال، "يمكنه تحديث المشاريع" يختلف عن "يمكنه تحديث المشاريع التي يملكها"—الأخير يتطلّب فحصًا لملكية البيانات.
تنفّذ الأطر هذا غالبًا عبر دالة مركزية "can?" تُستدعى من المتحكمات، الـ resolvers، العمال، أو القوالب.
السياسات تجمع منطق التفويض إلى مُقَيِّمين قابلين لإعادة الاستخدام: "يمكن للمستخدم حذف تعليق إذا كان هو كاتبه أو كان مشرفًا." تقبل السياسات سياقًا (user, resource, request)، مما يجعلها مثالية ل:
عندما تدمج الأطر السياسات في التوجيه وmiddleware، يمكنك فرض القواعد باستمرار عبر نقاط النهاية.
التعليقات (annotations) مثل @RequireRole('admin') تبقي النية قريبة من المعالج، لكنها قد تتفكك عندما تصبح القواعد معقدة.
الفحوصات البرمجية الصريحة أكثر تفصيلاً وغالبًا أسهل للاختبار وإعادة البناء. حل وسط شائع هو التعليقات للبوابات العامة والسياسات للمنطق التفصيلي.
لا تساعدك الأطر على تسجيل المستخدمين فقط—بل تأتي أيضًا بدفاعات ضد أكثر الهجمات شيوعًا حول المصادقة.
إذا كان تطبيقك يستخدم كوكيات الجلسة، فالمتصفح يرفقها تلقائيًا بالطلبات—أحيانًا حتى عند تفعيل الطلب من موقع آخر. حماية CSRF في الأطر تضيف عادة رمز CSRF لكل جلسة (أو لكل طلب) يجب إرساله مع الطلبات التي تغيّر الحالة.
أنماط شائعة:
زادِم CSRF مع كوكيات SameSite (غالبًا Lax افتراضيًا) لتقليل الخطر، وتأكد من أن كوكي الجلسة HttpOnly وSecure حيث يلزم.
CORS ليس آلية مصادقة؛ إنه نظام أذونات عبر المتصفح. توفر الأطر عادة middleware/إعدادًا للسماح للأصول الموثوقة باستدعاء API الخاص بك.
تكوينات خاطئة لتجنبها:
Access-Control-Allow-Origin: * مع Access-Control-Allow-Credentials: true (سيرفضها المتصفح وتدل على لبس)Origin دون قائمة سماح صارمةAuthorization) أو الطرق المطلوبة، مما يجعل الطلبات تعمل عبر curl لكن تفشل في المتصفحيمكن لمعظم الأطر تعيين قيم افتراضية آمنة أو تسهيل إضافة رؤوس مثل:
X-Frame-Options أو Content-Security-Policy: frame-ancestors لمنع clickjackingContent-Security-Policy للتحكم بالأصول والسكريبتاتReferrer-Policy وX-Content-Type-Options: nosniffالتحقق يضمن صحة البيانات؛ التفويض يضمن أن المستخدم مخول بالعمل. سيكون الطلب صالحًا لكن قد يُرفض بسبب عدم وجود إذن—تعمل الأطر بشكل أفضل عندما تطبق كلا الأمرين: تحقق المدخلات مبكرًا، ثم أقررش الأذونات على المورد المستهدف.
النمط الصحيح للمصادقة يعتمد كثيرًا على مكان تشغيل الكود وكيفية وصول الطلبات إلى الـ backend. قد تدعم الأطر خيارات متعددة، لكن الافتراضات التي تبدو طبيعية في نوع تطبيق قد تكون غير مناسبة أو محفوفة بالمخاطر في آخر.
تتناسب تطبيقات SSR عادةً مع الجلسات المعتمدة على الكوكي. يرسل المتصفح الكوكي تلقائيًا، يتحقق الخادم من الجلسة، ويمكن للصفحات العرض مع سياق المستخدم دون كود عميل إضافي.
قاعدة عملية: اجعل كوكيات الجلسة HttpOnly, Secure وبإعداد SameSite معقول، واعتمد فحوصات التفويض على الخادم لكل طلب يعرض بيانات خاصة.
تستدعي SPAs واجهات برمجة تطبيقات عبر جافاسكربت، مما يجعل خيارات الرموز أكثر حساسية. يفضل العديد من الفرق تدفق OAuth/OIDC الذي يمنح رموز وصول قصيرة العمر.
تجنّب تخزين الرموز طويلة العمر في localStorage إن أمكن؛ فهو يزيد مجال تأثير XSS. بديل شائع هو نمط backend-for-frontend (BFF): تتحدث الـ SPA إلى خادمك الخاص مع كوكي جلسة، والخادم يتبادل/يحتفظ بالرموز للنداءات إلى APIs الخارجية.
لا تعتمد تطبيقات الموبايل على قواعد الكوكي في المتصفحات بنفس الطريقة. تستخدم عادة OAuth/OIDC مع PKCE، وتخزن رموز التجديد في مخزن آمن للمنصة (Keychain/Keystore).
خطط لاسترداد "الجهاز المفقود": إبطال الرموز، تدوير بيانات الاعتماد، وتسهيل إعادة المصادقة—خاصة عند تمكين MFA.
مع تعدد الخدمات، عليك الاختيار بين هوية مركزية وتنفيذ على مستوى الخدمة:
للمصادقة خدمة-إلى-خدمة، تندمج الأطر عادةً مع mTLS (هوية قناة قوية) أو OAuth client credentials (حسابات خدمة). المهم أن تتحقق من المتصل وتفوض ما يمكنه فعله.
ميزات "انتحال المستخدم" الإدارية قوية وخطيرة. فضِّل جلسات انتحال صريحة، اطلب إعادة مصادقة/MFA للمسؤولين، وسجِّل دائمًا (من انتحل مَن، متى، وما الإجراءات التي اتُخذت).
ميزات الأمان تساعد فقط إذا استمرت في العمل عند تغيير الشيفرة. تسهّل الأطر الحديثة اختبار المصادقة والتفويض، لكنك ما زلت بحاجة لاختبارات تعكس سلوك المستخدم الحقيقي—وسلوك المهاجم.
ابدأ بفصل ما تختبره:
توفر معظم الأطر مساعدة للاختبار حتى لا تضطر لبناء جلسات أو رموز يدويًا في كل مرة. أنماط شائعة تشمل:
قاعدة عملية: لكل اختبار "المسار السعيد" أضف اختبارًا "يُرفَض" يبرهن أن فحص التفويض يعمل فعلاً.
عندما يخطئ شيء، تريد إجابات بسرعة وبثقة.
سجّل و/أو دوّن أحداثًا رئيسية:
أضف مقاييس خفيفة أيضًا: معدل استجابات 401/403، زيادات في فشل تسجيل الدخول، وأنماط غير عادية في تجديد الرموز.
عامل أخطاء المصادقة كتصرّف قابل للاختبار: إذا يمكن أن يتراجع، فله أن يملك اختباراً.
المصادقة تثبت الهوية (من يرسل الطلب). التفويض يقرر ما الذي يُسمح لتلك الهوية بفعله باستخدام سياق الطلب مثل المسار، ملكية المورد، النطاقات، أو القِطاع.
الأطر تفصل بينهما حتى تتمكن من تغيير طرق تسجيل الدخول دون إعادة كتابة منطق الصلاحيات.
تطبق معظم الأطر الفحوصات الأمنية ضمن خط معالجة الطلب، عادةً عبر:
user/principalمخزن الهوية هو مصدر الحقيقة للمستخدمين وبيانات الاعتماد (أو روابط لهويات خارجية). نموذج المستخدم هو تمثيل الهوية في الكود.
باختصار: المخزن يجيب عن “أين نبحث عن هذه الهوية؟” ونموذج المستخدم يجيب عن “كيف نمثل هذه الهوية في التطبيق؟”.
مصادر الهوية الشائعة:
عند استخدام IdP أو دليل، غالبًا ما يحتفظ التطبيق بمستخدم ظلي محلي يربط معرفًا خارجيًا ثابتًا (مثل sub في OIDC) ببيانات وأدوار داخل التطبيق.
الجلسات تحتفظ بالهوية على الخادم وتستخدم كوكي كمؤشر (معرّف الجلسة). هذا مناسب لتطبيقات SSR ويسهّل إبطال الجلسات فورًا.
الرموز (JWT/opaque) تُرسل مع كل طلب عبر عادةً Authorization: Bearer <token> وتناسب واجهات برمجة التطبيقات، تطبيقات SPA، الموبايل، وخدمات بينية.
عادةً تُقوّي الأطر كوكيات الجلسة بهذه العلامات الأمنية:
HttpOnly (يمنع جافاسكربت من قراءة الكوكي)Secure (يرسل فقط عبر HTTPS)SameSite (يحدد إرسال الكوكي عبر المواقع؛ مؤثر في CSRF وتدفقات المصادقة عبر مواقع متعددة)اختَر القيم المناسبة لتدفقات تطبيقك (مثل مقابل ).
الرموز المظلمة (opaque) هي سلاسل عشوائية تتحقق منها الخوادم عبر بحث في قاعدة/ذاكرة مؤقتة (سهولة الإبطال وخصوصية المحتوى).
الـ JWTs موقعة ومحتوياتها قابلة للقراءة (claims مثل sub, exp, aud). ملائمة للأنظمة الموزعة، لكن إبطالها أصعب ما لم تُستخدم صلاحيات قصيرة أو قوائم حظر على الخادم.
اجعل رموز الوصول قصيرة العمر، واستخدم رموز تجديد (refresh tokens) فقط لطلب رموز وصول جديدة.
نموذج شائع:
POST /auth/login → access + refreshPOST /auth/refresh → تدوير refresh وإصدار access جديدPOST /auth/logout → إبطال refresh tokensالتدوير واكتشاف إعادة الاستخدام يقللان الضرر عند تسريب refresh token.
OAuth 2.0 مخصّص للوصول المفوض إلى واجهات برمجة تطبيقات (تفويض صلاحية لتطبيق للقيام بعمليات نيابة عن المستخدم).
OpenID Connect مخصص لتسجيل الدخول/الهوية ويضيف ID token وclaims معيارية. عادةً تكون عملية "تسجيل الدخول عبر X" هي OIDC مبني على OAuth 2.0.
الأدوار (RBAC) مفيدة للأبواب العريضة (مثلاً: admin مقابل member). السياسات/الأذونات تناسب القواعد الدقيقة (مثلاً: تحرير المستندات التي تملكها فقط).
نمط شائع:
LaxNone