سجل قرار البنية المعمارية: خيارات المصادقة والتفويض

المصادقة (authentication) والتفويض (authorization) في تطبيقات الويب مفهومان بالغا الأهمية لتأمين الوصول إلى التطبيقات والخدمات. وكلاهما يتعلق بهوية المستخدمين وبكيفية منح الأذونات، لكنهما يركّزان على جانبين مختلفين:

• المصادقة هي عملية التحقق من هوية مستخدم أو نظام.
• التفويض هو عملية تحديد الموارد أو الإجراءات التي يستطيع المستخدم أو النظام المصادَق عليه الوصول إليها.

والآن، لننتقل إلى البروتوكولات والتقنيات المحددة التي ذكرتها، والتي تُستخدم عادةً في تطبيقات الويب الحديثة لإدارة المصادقة والتفويض.

1. OAuth (التفويض المفتوح)

OAuth معيار مفتوح للتفويض. يتيح للمستخدم منح تطبيق تابع لطرف ثالث وصولًا محدودًا إلى موارده دون مشاركة بيانات اعتماده. والفكرة الأساسية هي الوصول المفوَّض. ويُستخدم OAuth غالبًا في الحالات التي يستطيع فيها المستخدمون تسجيل الدخول إلى خدمة طرف ثالث (مثل تسجيل الدخول باستخدام Google) دون تقديم اسم المستخدم وكلمة المرور مباشرةً إلى الطرف الثالث.

• التدفق: يتبع OAuth عادةً تدفقًا قائمًا على الرموز (token-based)، يُصدر فيه خادم التفويض رمز وصول إلى تطبيق الطرف الثالث. ويمثل هذا الرمز أذونات المستخدم، ويستخدمه التطبيق للوصول إلى بيانات المستخدم أو موارده من واجهة برمجية.
• مثال: يسجل مستخدم الدخول إلى تطبيق تابع لطرف ثالث باستخدام حسابه في Google. تتحقق Google من هوية المستخدم ثم تمنح رمزًا يتيح لتطبيق الطرف الثالث الوصول إلى بعض بيانات Google (مثل Google Calendar).

OAuth لا يتعامل مع المصادقة مباشرة؛ بل يتعلق بمنح الوصول. وللمصادقة، يُقرن OAuth غالبًا ببروتوكولات أخرى، مثل OpenID Connect.

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) طبقة هوية مبنية فوق OAuth 2.0 تضيف المصادقة إلى إمكانات التفويض في OAuth. وبعبارة جوهرية، يوسّع OpenID Connect بروتوكول OAuth ليتعامل مع مصادقة المستخدمين ويوفر طريقة معيارية للتطبيقات للتحقق من هوية المستخدم.

• التدفق: عندما يسجل المستخدم الدخول عبر OpenID Connect، يطلب تطبيق الطرف الثالث رمز هوية (ID token) (إضافةً إلى رمز الوصول في OAuth). ويحتوي رمز الهوية على معلومات عن المستخدم (مثل اسم المستخدم وبريده الإلكتروني ومطالبات أخرى). وهذا يتيح للتطبيق معرفة من هو المستخدم وهل هو مصادَق عليه.
• مثال: تسجيل الدخول إلى خدمة مثل Slack باستخدام حسابك في Google (حيث Google هي مزوّد OpenID Connect) يتضمن مصادقة عبر OpenID Connect، بينما يدير OAuth الوصول إلى مواردك في Google.

يسهّل OIDC على تطبيقات الأطراف الثالثة مصادقة المستخدمين مع الإبقاء على تحكم دقيق في الموارد التي يمكن لتلك التطبيقات الوصول إليها.

3. SAML (لغة ترميز تأكيدات الأمان)

SAML معيار أقدم قائم على XML يُستخدم لتبادل بيانات المصادقة والتفويض بين الأطراف، خصوصًا في سيناريوهات تسجيل الدخول الموحد (SSO). ويُستخدم أساسًا في بيئات المؤسسات لتمكين المستخدمين من المصادقة مرة واحدة والوصول إلى تطبيقات متعددة دون إعادة إدخال بيانات الاعتماد.

• التدفق: يصادق المستخدم أولًا لدى مزوّد الهوية (IdP). يولّد مزوّد الهوية تأكيد SAML موقّعًا يتضمن هوية المستخدم والسمات المتعلقة بها. ويُرسل التأكيد إلى مزوّد الخدمة (SP)، الذي يستخدمه لتفويض الوصول إلى التطبيق.
• مثال: يسجل موظف الدخول إلى بوابة شركته (مزوّد الهوية) فيُسجَّل دخوله تلقائيًا إلى أنظمة أخرى مثل البريد الإلكتروني وإدارة علاقات العملاء (CRM) وغيرهما دون إعادة إدخال بيانات الاعتماد. وتستند عملية المصادقة إلى تأكيد SAML الذي يرسله مزوّد الهوية.

يُستخدم SAML عادةً في حلول SSO للمؤسسات ويعمل جيدًا لتطبيقات الويب في بيئات الشركات، لكنه أقل ملاءمة للجوّال مقارنةً بـOAuth/OIDC.

4. WS-Federation (اتحاد خدمات الويب)

WS-Federation بروتوكول آخر يُستخدم في تسجيل الدخول الموحد (SSO)، خصوصًا في بيئات المؤسسات القائمة على Microsoft. وهو جزء من عائلة مواصفات WS- (خدمات الويب)* ويتيح اتحاد الهويات عبر نطاقات أمان مختلفة (مثل بين مؤسسات مختلفة أو بين خدمات مختلفة).

• التدفق: يتيح WS-Federation لـمزوّد هوية (IdP) موثوق مصادقة المستخدمين وإصدار رموز يستطيع مزوّد الخدمة استخدامها في التفويض. وهو يشبه SAML لكنه يُستخدم غالبًا في سيناريوهات تعتمد بقوة على تقنيات Microsoft.
• مثال: يسجل مستخدم الدخول إلى تطبيق مؤسسي تستضيفه Microsoft Azure Active Directory (AD)، ويمكن استخدام هويته للوصول إلى خدمات اتحادية أخرى، منها تطبيقات يستضيفها موردون من أطراف ثالثة.

ورغم أن WS-Federation حلّت محله إلى حد كبير بروتوكولات أحدث مثل OAuth 2.0 وOpenID Connect في كثير من بيئات الويب الحديثة، فإنه لا يزال مستخدمًا في الأنظمة القديمة، خصوصًا في المؤسسات المتمحورة حول Microsoft.

5. LDAP (بروتوكول الوصول الخفيف إلى الأدلة)

LDAP بروتوكول يُستخدم للوصول إلى خدمات الأدلة (directory services) وإدارتها، ويُستخدم عادةً في تخزين بيانات اعتماد المستخدمين وإدارة التحكم في الوصول في دليل مركزي (يسمى غالبًا خدمة الدليل). وLDAP ليس معنيًا تحديدًا بالمصادقة أو التفويض، بل يُستخدم لتخزين بيانات الهوية واسترجاعها، التي تُستخدم بدورها في تلك العمليات.

• المصادقة: يتيح LDAP لتطبيق ما مصادقة المستخدمين بالاستعلام من خدمة الدليل عن بيانات الاعتماد (مثل كلمات المرور).
• التفويض: يدير أيضًا أدوار المستخدمين وأذوناتهم، مما يساعد على تحديد ما إذا كان للمستخدم حق الوصول إلى موارد معينة.
• مثال: تستخدم مؤسسات كثيرة أدلة قائمة على LDAP (مثل Active Directory) للمصادقة والتفويض، خصوصًا في بيئات Windows.

LDAP أساسي للمؤسسات لإدارة وصول المستخدمين عبر الأنظمة الداخلية، لكن في سياق الويب الحديث كثيرًا ما يُدمج LDAP مع بروتوكولات أخرى مثل SAML أو OAuth لإدارة هوية أكثر اكتمالًا.

6. مزودو SSO الاجتماعي

يتيح مزودو تسجيل الدخول الموحد (SSO) الاجتماعي مثل Facebook وGoogle وTwitter وGitHub وغيرهم للمستخدمين المصادقة في تطبيقات الأطراف الثالثة باستخدام بيانات اعتماد وسائل التواصل الاجتماعي. وهذا نوع من المصادقة القائمة على OAuth تكون فيه خدمة الطرف الثالث (مثل Google) هي مزوّد الهوية.

• التدفق: ينقر المستخدم «تسجيل الدخول باستخدام Google» (مثلًا). يعيد التطبيق التوجيه إلى Google، حيث يسجل المستخدم الدخول (إن لم يكن مسجلًا). ثم تقدم Google رمز وصول أو رمز هوية إلى تطبيق الطرف الثالث، ويمكن استخدامه لمصادقة المستخدم وربما الوصول إلى بياناته.
• مثال: تتيح لك تطبيقات كثيرة تسجيل الدخول باستخدام بيانات اعتمادك في Google أو Facebook. وسيستخدم التطبيق OAuth أو OpenID Connect خلف الكواليس للتحقق من هويتك، وفي بعض الحالات للوصول إلى بيانات معينة من وسائل التواصل الاجتماعي.

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

---

ملخص الفروق:

• OAuth: يُستخدم للتفويض، ويتيح لتطبيقات الأطراف الثالثة الوصول إلى بيانات المستخدم دون كشف بيانات اعتماده.
• OpenID Connect: يوسّع OAuth لتوفير المصادقة، مما يتيح للتطبيقات التحقق من هوية المستخدم.
• SAML: بروتوكول قائم على XML يُستخدم للـSSO، غالبًا في بيئات المؤسسات.
• WS-Federation: بروتوكول خاص بـMicrosoft لاتحاد الهويات، يُستخدم في الأنظمة القديمة.
• LDAP: بروتوكول للاستعلام من خدمات الأدلة لمصادقة المستخدمين وإدارة التفويض.
• مزودو SSO الاجتماعي: أنظمة قائمة على OAuth (مثل Google وFacebook) تتيح لتطبيقات الأطراف الثالثة مصادقة المستخدمين باستخدام بيانات اعتماد وسائل التواصل الاجتماعي.

لكل من هذه التقنيات نقاط قوتها وحالات استخدامها، وفي التطبيقات الحديثة قد ترى استخدام مزيج منها لجوانب أمنية مختلفة (مثل OAuth/OIDC للوصول إلى الواجهات البرمجية، وSAML للـSSO المؤسسي).