ما هو التفويض (Authorization)؟
خلاصة: التفويض (Authorization) يجيب على السؤال “ما الذي يمكنك القيام به؟”
التفويض (Authorization) هو عملية صنع القرار التي تحدد ما إذا كانت هوية معينة (مستخدم، خدمة أو جهاز) لديها التصاريح اللازمة لأداء إجراء محدد على مورد. دعونا ننظر إلى بعض الأمثلة:
- في محرر مستندات على الإنترنت، يمكن للمستخدم مشاركة مستند مع الآخرين.
- في خدمة تخزين سحابية، يمكن للخدمة قراءة وكتابة الملفات في مجلد محدد.
- في نظام منزل ذكي، يمكن للجهاز تشغيل الأضواء في غرفة المعيشة.
كل هذه الأمثلة تتضمن هوية (الموضوع) تقوم بإجراء على مورد. بالطبع، يمكن أن يفشل التفويض (Authorization) أيضًا، مثل عندما يحاول المستخدم حذف ملف لا يملك إذن الوصول إليه.
النموذج الأساسي للتفويض (Authorization) بسيط: إذا كانت الهوية تقوم بـ الإجراء على المورد، إذن يُقبَل أو يُرفَض.
الفرق بين المصادقة (Authentication) والتفويض (Authorization)
غالبًا ما يتم الخلط بين المصادقة (Authentication) والتفويض (Authorization)، لكنهما مختلفان بشكل أساسي: مصادقة (Authentication) يجيب على السؤال “أي هوية تمتلكها؟”. بالإضافة إلى ذلك، في معظم الحالات، يحدث التفويض (Authorization) بعد المصادقة (Authentication) لأن النظام يحتاج إلى معرفة الهوية قبل اتخاذ قرارات الوصول.
الفرق بين التفويض (Authorization) والتحكم في الوصول (Access Control)
التفويض (Authorization) هو جزء من التحكم في الوصول (Access Control). التحكم في الوصول هو المفهوم الأوسع الذي يشمل التفويض (Authorization) وحدود أخرى على إدارة الوصول. بعبارة أخرى، التحكم في الوصول هو مصطلح عام يصف الحد الانتقائي للوصول إلى الموارد، بينما التفويض (Authorization) يتعلق بشكل محدد بعملية صنع القرار.
كيف يعمل التفويض (Authorization)؟
يتم تنفيذ التفويض (Authorization) عادةً باستخدام نماذج التحكم في الوصول (Access control Models) . وتحدد كيفية تعيين وتنفيذ التصاريح في نظام ما.
أطر عمل التفويض (Protocols)
في حين أن OAuth 2.0 هو إطار عمل شائع جدًا للتفويض (Authorization)، فإنه يستحق الذكر أن OAuth 2.0 لا يحدد أي نموذج من نماذج التحكم في الوصول (Access Control) يجب استخدامه. بدلاً من ذلك، يركز على تفويض التفويض وإصدار رموز الوصول (Access Tokens).
ومع ذلك، يعد OAuth 2.0 مناسبًا لسيناريوهات تفويض الطرف الثالث حيث يمنح المستخدم إذنًا لعميل للوصول إلى موارده. على سبيل المثال، عندما تقوم بتسجيل الدخول إلى موقع باستخدام حساب Google الخاص بك، فإنك تفوض الموقع للوصول إلى ملفك الشخصي في Google.
إذا كنت تتعامل مع التفويض (Authorization) من النوع الأول (مثل داخل تطبيقك أو مؤسستك)، فقد تحتاج إلى تنفيذ نموذج للتحكم في الوصول (Access Control) مثل التحكم في الوصول بناءً على الأدوار (Role-based access control, RBAC) أو التحكم في الوصول المستند إلى السمة (Attribute-based Access Control, ABAC) . يمكن للدمج بين OpenID Connect (OIDC) ونماذج التحكم في الوصول (Access Control) أن يوفر أساسًا قويًا لكل من المصادقة (Authentication) والتفويض (Authorization).
بدلاً من بناء نظام تفويض (Authorization) خاص بك، يُوصى باستخدام مزود الهوية (Identity provider, IdP) يوفر قدرات المصادقة (Authentication) والتفويض (Authorization). سيتولى موفر الهوية الجيد التعامل مع تعقيدات التحكم في الوصول ويقدم حلاً آمنًا وقابلاً للتوسع لتطبيقاتك.