الهوية الموحّدة: SAML وOAuth وOpenID Connect
تعلّم كيف تتيح SSO وتأكيدات SAML وتدفقات OAuth 2.0 ورموز OpenID Connect للمستخدمين المصادقة مرة واحدة بأمان عبر العديد من التطبيقات.
الهوية الموحّدة: SAML وOAuth وOpenID Connect درس مجاني في Security+ Academy على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Security+ Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Security+ Academy 4 دروس في المجموع.
مشكلة الهوية عبر النطاقات
في المؤسسات الحديثة، يحتاج الموظفون إلى الوصول إلى عشرات التطبيقات — مثل التطبيقات السحابية وأدوات SaaS وبوابات الشركاء والأنظمة الداخلية — وقد تكون كلٌّ منها مُدارة من مؤسسة مختلفة. ويُعد إنشاء حسابات منفصلة لكل تطبيق وإدارتها أمرًا غير آمن (بسبب تكاثر بيانات الاعتماد) وغير فعّال. تحلّ الهوية المُوحّدة هذه المشكلة بالسماح لـموفّر الهوية (IdP) — وهو مصدر موثوق ومرجعي للهوية — بمصادقة المستخدمين ومشاركة هويتهم التي تم التحقق منها مع موفّري الخدمة (SPs) عبر حدود المؤسسات. وبذلك يصادق المستخدمون مرة واحدة ويحصلون على الوصول إلى أنظمة متعددة من دون إعادة إدخال بيانات الاعتماد.
أساسيات الدخول الموحّد (SSO)
يتيح الدخول الموحّد (SSO) للمستخدمين المصادقة مرة واحدة والوصول إلى تطبيقات متعددة خلال جلسة واحدة من دون إعادة المصادقة. يسجّل المستخدم الدخول إلى موفّر الهوية (مثل Active Directory المؤسسي أو Okta أو Azure AD)، ويحصل على رمز جلسة أو تأكيد، ثم يقدّم هذا الرمز إلى كل موفّر خدمة يزوره. يحسّن الدخول الموحّد الأمان من خلال تقليل عدد كلمات المرور التي يجب على المستخدمين إدارتها (مما يقلل إعادة استخدامها)، وتمكين فرض سياسات المصادقة مركزيًا، والسماح بإلغاء الوصول فورًا من جميع التطبيقات المتكاملة عند تعطيل الحساب على مستوى IdP.
SAML 2.0: الاتحاد القائم على XML
يُعدّ SAML (Security Assertion Markup Language) 2.0 معيارًا مفتوحًا قائمًا على XML لتبادل بيانات المصادقة والتفويض بين موفّري الهوية وموفّري الخدمة. يجري تدفق SAML كما يلي: (1) يصل المستخدم إلى موفّر خدمة (مثل Salesforce)، (2) يعيد موفّر الخدمة توجيهه إلى موفّر الهوية (مثل Okta)، (3) يصادق المستخدم لدى IdP، (4) يُصدر IdP تأكيد SAML بصيغة XML وموقّعًا، ويحتوي على هوية المستخدم وسماته، (5) يُعاد التأكيد إلى موفّر الخدمة، (6) يتحقق موفّر الخدمة من توقيع التأكيد باستخدام المفتاح العام الخاص بـ IdP ثم يمنح الوصول. ويُستخدم SAML على نطاق واسع في الدخول الموحّد المؤسسي لتطبيقات الويب.
<!-- Simplified SAML Assertion structure -->
<saml:Assertion xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
IssueInstant='2026-06-21T10:00:00Z'
ID='_abc123'>
<saml:Issuer>https://idp.company.com</saml:Issuer>
<saml:Subject>
<saml:NameID>alice@company.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore='2026-06-21T10:00:00Z'
NotOnOrAfter='2026-06-21T10:05:00Z'/>
<saml:AttributeStatement>
<saml:Attribute Name='groups'>
<saml:AttributeValue>Sales</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<!-- Signature verifies IdP signed this assertion -->
</saml:Assertion>أدوار SAML: IdP وSP والكيان الرئيسي
تشارك ثلاثة أطراف في اتحاد SAML. الكيان الرئيسي هو المستخدم (أو النظام) الذي يطلب الوصول، وهو الذي يبدأ عملية المصادقة. أما موفّر الهوية (IdP) فهو مصدر الهوية المرجعي الذي يصادق على الكيان الرئيسي ويصدر التأكيدات — ومن أمثلته Microsoft Azure AD وOkta وPing Identity وADFS. وموفّر الخدمة (SP) يستهلك التأكيد ويمنح الوصول استنادًا إليه — ومن أمثلته Salesforce وGoogle Workspace وAWS وأي تطبيق يدعم SAML. وينشئ موفّر الخدمة وIdP الثقة مسبقًا من خلال تبادل بيانات وصفية تتضمن عناوين URL لنقاط النهاية وشهادات التوقيع الخاصة بكل منهما.
OAuth 2.0: إطار التفويض
يُعدّ OAuth 2.0 إطارًا لـالتفويض (وليس بروتوكولًا للمصادقة)، إذ يتيح لتطبيق تابع لجهة خارجية الوصول إلى الموارد نيابةً عن المستخدم من دون كشف بيانات اعتماد المستخدم. ومن حالات الاستخدام الشائعة: «السماح لتطبيق تحرير الصور هذا بالوصول إلى صور Google الخاصة بك». ويعرّف OAuth 2.0 أربعة أدوار: مالك المورد (المستخدم)، والعميل (التطبيق التابع لجهة خارجية)، وخادم التفويض (يُصدر الرموز)، وخادم المورد (يستضيف المورد المحمي). ويفوّض المستخدم العميل، فيحصل العميل على رمز وصول يقدّمه إلى خادم المورد، من دون الحاجة إلى كلمة مرور المستخدم الفعلية.
تدفق رمز التفويض في OAuth 2.0
يُعدّ تدفق رمز التفويض التدفق الأكثر أمانًا في OAuth 2.0 لتطبيقات الويب. ويجري التدفق كما يلي: (1) يعيد العميل توجيه المستخدم إلى خادم التفويض مع النطاقات المطلوبة؛ (2) يصادق المستخدم ويمنح موافقته لدى خادم التفويض؛ (3) يعيد خادم التفويض التوجيهَ إلى العميل مرفقًا برمز تفويض قصير الأجل؛ (4) يستبدل العميل الرمزَ بـرمز وصول (ورمز تحديث اختياري) عبر استدعاء من خادم إلى خادم باستخدام بيانات اعتماد العميل؛ (5) يستخدم العميل رمز الوصول لاستدعاء خادم المورد. ويحدث تبادل الرمز من جهة الخادم، مما يمنع كشف رمز الوصول في سجل المتصفح أو السجلات.
# OAuth 2.0 Authorization Code Flow (step 3-4)
# Step 3: User is redirected back to client with auth code
# GET https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
# Step 4: Client exchanges code for access token (server-to-server)
curl -X POST https://auth.example.com/oauth2/token \
-d 'grant_type=authorization_code' \
-d 'code=SplxlOBeZQQYbYS6WxSbIA' \
-d 'redirect_uri=https://app.example.com/callback' \
-d 'client_id=client_abc' \
-d 'client_secret=secret_xyz'
# Response: {'access_token': 'MTQ0Nj...', 'token_type': 'Bearer', 'expires_in': 3600}OpenID Connect: إضافة المصادقة إلى OAuth
يُعدّ OpenID Connect (OIDC) طبقة مصادقة مبنية فوق OAuth 2.0. يوفّر OAuth التفويض فقط (أي رموز وصول تثبت ما يستطيع العميل فعله)، بينما يضيف OIDC المصادقة (أي رمز هوية يثبت هوية المستخدم). ويضيف OIDC نطاق openid إلى تدفق OAuth، ويعيد رمز هوية JWT (JSON Web Token) موقّعًا إلى جانب رمز الوصول. ويحتوي رمز الهوية على مطالبات (الاسم والبريد الإلكتروني وsub [معرّف الموضوع]) تحدد هوية المستخدم. ويُعدّ OIDC حاليًا البروتوكول المهيمن للدخول الموحّد الموجّه إلى المستهلكين — فأزرار «تسجيل الدخول باستخدام Google/Apple/Microsoft» تستخدم جميعها OIDC.
# OIDC ID Token is a JWT with three base64url-encoded parts:
# header.payload.signature
# Decoded payload example:
# {
# 'iss': 'https://accounts.google.com',
# 'sub': '110169484474386276334',
# 'aud': 'client_id_abc123',
# 'exp': 1750000000,
# 'iat': 1749996400,
# 'email': 'alice@gmail.com',
# 'name': 'Alice Smith',
# 'email_verified': true
# }
# The signature is verified with the IdP's public key (from JWKS endpoint)JWT: الرموز في المصادقة الحديثة
تُعدّ JSON Web Tokens (JWT) صيغة مضغوطة وآمنة للاستخدام في عناوين URL لتمثيل المطالبات بين الأطراف. يتكوّن JWT من ثلاثة أجزاء مشفّرة بترميز base64url تفصل بينها نقاط: الرأس (الخوارزمية ونوع الرمز)، والحمولة (المطالبات: iss وsub وaud وexp وiat والمطالبات المخصّصة)، والتوقيع (توقيع تشفيري يتحقق من سلامة الرمز). وتكون JWTs مكتفية ذاتيًا — إذ يستطيع خادم المورد التحقق منها من دون الاتصال مجددًا بخادم التفويض، مما يحسّن الأداء ويدعم البنى عديمة الحالة. ومتطلب الأمان الحاسم هو: التحقق دائمًا من توقيع JWT وفحص مطالبتَي exp (انتهاء الصلاحية) وaud (الجمهور).
# Decode a JWT (header and payload are just base64 encoded)
import base64, json
jwt = 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNzUwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
parts = jwt.split('.')
print('Header:', json.loads(base64.b64decode(parts[0] + '==')))
print('Payload:', json.loads(base64.b64decode(parts[1] + '==')))
# Signature (parts[2]) must be verified with IdP public key!SAML مقابل OAuth مقابل OIDC: متى تستخدم كلًّا منها
يُعدّ فهم الحالات التي ينطبق فيها كل معيار أمرًا حاسمًا لامتحان Security+. SAML 2.0: الدخول الموحّد المؤسسي لتطبيقات الويب، وتدفقات تعتمد على المتصفح، وتأكيدات XML. وهو قديم لكنه منتشر على نطاق واسع في المؤسسات. OAuth 2.0: تفويض واجهات API — أي منح التطبيقات التابعة لجهات خارجية وصولًا محدودًا إلى الموارد. ولا يصادق على المستخدمين مباشرةً. OIDC: مصادقة المستهلكين والمؤسسات الحديثة (الدخول الموحّد)، وهو مبني على OAuth 2.0. ويعيد رموز هوية JWT تحدد هوية المستخدم. عمليًا: تستخدم البيئات المؤسسية غالبًا SAML للدخول الموحّد إلى التطبيقات وOIDC للمصادقة على واجهات API وتطبيقات الأجهزة المحمولة. أما البيئات السحابية الحديثة فتميل إلى تفضيل OIDC على SAML بسبب تنسيق JSON/JWT ودعمه الأفضل للأجهزة المحمولة.
نواقل الهجوم على الاتحاد
تُدخل أنظمة الهوية المُوحّدة نواقل هجوم محددة. هجمات إعادة تشغيل التأكيدات: يعترض المهاجم تأكيد SAML ويعيد تشغيله للحصول على الوصول. ويُحدّ من ذلك باستخدام مدد صلاحية قصيرة للتأكيدات ومعرّفات تأكيدات تُستخدم مرة واحدة. التفاف توقيع XML (XSW): يستطيع المهاجمون في SAML أحيانًا التلاعب بـ XML الموقّع لتغيير المطالبات مع إبقاء التوقيع صالحًا للمحتوى الأصلي. الخلط بين خوارزميات JWT: إذا قبل الخادم خوارزميتي RS256 (غير المتماثلة) وHS256 (المتماثلة)، فيمكن للمهاجم تزوير JWTs باستخدام المفتاح العام للخادم باعتباره سر HMAC لخوارزمية HS256. تحقّق دائمًا من تطابق خوارزمية الرأس مع الخوارزمية المتوقعة. عمليات إعادة التوجيه المفتوحة: يجب مطابقة عناوين URI لإعادة التوجيه في OAuth مطابقة تامة لمنع سرقة الرموز عبر إعادة التوجيه إلى مواقع يتحكم فيها المهاجم.
اتحاد الدليل وSCIM
يتطلب اتحاد الهوية المؤسسي غالبًا مزامنة بيانات هوية المستخدم بين الأنظمة. ويُعدّ SCIM (System for Cross-domain Identity Management) معيارًا لواجهة REST API لأتمتة إنشاء حسابات المستخدمين وإلغاء توفيرها بين موفّر الهوية وموفّري الخدمة المتصلين. فعند إضافة موظف جديد إلى Azure AD (IdP)، ينشئ SCIM حسابه تلقائيًا في Salesforce وSlack وGitHub وغيرها من التطبيقات المتوافقة مع SCIM. وعند إنهاء خدمة الموظف، يعطّل SCIM جميع حساباته في الوقت نفسه، مما يغلق النافذة التي يمكن خلالها استغلال الحسابات اليتيمة. ويكمّل SCIM بروتوكولات الدخول الموحّد (SAML/OIDC) من خلال إدارة دورة حياة الهوية، وهي وظيفة لا تعالجها بروتوكولات الدخول الموحّد.
تحقق سريع
اختبر مدى فهمك لمفاهيم CompTIA Security+ (SY0-701) التي تناولها هذا الدرس.
مراجعة الدرس
لقد تعلمت في هذا الدرس أن: يستخدم SAML 2.0 تأكيدات XML للدخول الموحّد المؤسسي القائم على المتصفح؛ وأن OAuth 2.0 إطار تفويض لتفويض الوصول إلى واجهات API؛ وأن OpenID Connect يضيف المصادقة (رموز هوية JWT) إلى OAuth؛ وأن SCIM يؤتمت إدارة دورة حياة الهوية عبر الأنظمة المُوحّدة. وبذلك يكتمل مقرر المصادقة والتفويض — وننتقل بعد ذلك إلى أساسيات أمن الشبكات.
الأسئلة الشائعة
هل درس «الهوية الموحّدة: SAML وOAuth وOpenID Connect» مجاني؟
نعم — نص درس «الهوية الموحّدة: SAML وOAuth وOpenID Connect» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Security+ Academy، انتقل إلى CoddyKit PRO. تتضمن دورة Security+ Academy 4 دروس في المجموع.
ماذا ستتعلم في «الهوية الموحّدة: SAML وOAuth وOpenID Connect»؟
تعلّم كيف تتيح SSO وتأكيدات SAML وتدفقات OAuth 2.0 ورموز OpenID Connect للمستخدمين المصادقة مرة واحدة بأمان عبر العديد من التطبيقات. تتمرن على Security+ Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.
هل أحتاج إلى خبرة سابقة لأبدأ Security+ Academy؟
لا تُشترط خبرة سابقة. Security+ Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.
كم من الوقت يستغرق درس «الهوية الموحّدة: SAML وOAuth وOpenID Connect»؟
معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.
هل يمكنني كتابة وتشغيل أكواد في درس Security+ Academy هذا؟
نعم. كل درس في Security+ Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.
جميع الدروس في هذه الدورة
- سياسات كلمات المرور والمصادقة متعددة العوامل
- المقاييس الحيوية والمصادقة القائمة على الرموز
- نماذج التفويض: RBAC وMAC وDAC
- الهوية الموحّدة: SAML وOAuth وOpenID Connect