افهم IAM وOAuth وOpenID Connect وSAML وSSO وJWT في مقال واحد

نما مجال إدارة الهوية والوصول (IAM) بشكل أكثر تعقيدًا خلال السنوات الأخيرة. المصطلحات الرنانة مثل OAuth وOpenID Connect (OIDC) وSAML وSSO وJWT تُستخدم بشكل متكرر، لكن ماذا تعني؟ كيف يعملون معًا؟ لنستكشف هذه المفاهيم والأُطر لجعلها أكثر قابلية للفهم والتطبيق.

ما هو IAM؟#

إدارة الهوية والوصول (IAM) هو مفهوم واسع يتضمن إدارة الهويات الرقمية وتنفيذ التحكم في الوصول. الأطر والبروتوكولات المذكورة سابقًا تندرج تحت IAM، حيث يعالج كل منها تحديات محددة في هذا المجال.

في جوهره، IAM يتعلق بـ:

• الهوية: تمثيل رقمي للمستخدم أو الخدمة أو الجهاز. عادةً ما تتضمن الهوية سمات مثل الاسم والبريد الإلكتروني والأدوار وغيرها، لوصف الكيان.
• الوصول: القدرة على التفاعل مع الموارد، أو تنفيذ الإجراءات، أو استخدام الخدمات. يحدد الوصول ما يمكن فعله على الموارد المحددة.

في الرسم البياني أعلاه، يرغب المستخدم (الهوية) في تنفيذ طلب GET على واجهة برمجة التطبيقات (المورد). تصف سمات المستخدم - الاسم والبريد الإلكتروني والدور - الهوية.

التحقق من الهوية مقابل التفويض#

كثيرًا ما يظهر التحقق من الهوية والتفويض معًا في مناقشات IAM. دعونا نوضح تعريفاتهم:

• التحقق من الهوية: عملية التحقق من ملكية الهوية. يجيب على السؤال، "ما هي الهوية التي تمتلكها؟"
• التفويض: عملية تحديد ما هي الإجراءات التي يمكن تنفيذها باستخدام هوية تم التحقق منها على مورد. يجيب على السؤال، "ماذا يمكنك أن تفعل؟"

في المثال السابق:

• قبل أن يتمكن المستخدم (الهوية) من تنفيذ أي إجراءات، يجب عليه إكمال عملية التحقق من الهوية.
• بعد التحقق من الهوية، يحتاج النظام إلى تحديد ما إذا كان يمكن للمستخدم تنفيذ طلب GET (الفعل) على واجهة برمجة التطبيقات (المورد)، أي، إكمال عملية التفويض.

---

بعد فهمنا لهذه المعرفة الأساسية، دعونا نفك رموز الاختصارات والبروتوكولات الأخرى.

OAuth#

OAuth 2.0، المعروف غالبًا بـ OAuth، هو إطار التفويض الذي يمكِّن التطبيق من الوصول إلى موارد محمية في تطبيق آخر (عادةً بالنيابة عن مستخدم).

على سبيل المثال، تخيل أن لديك تطبيق ويب يسمى MyApp يريد الوصول إلى محرك أقراص Google الخاص بالمستخدم. بدلاً من طلب مشاركة بيانات اعتماد Google Drive الخاصة بالمستخدم، يمكن لـ MyApp استخدام OAuth 2.0 لطلب الإذن (التفويض) من Google للوصول إلى Drive الخاص بالمستخدم.

إليك مخطط مبسط يوضح سير عمل OAuth:

في هذا التدفق:

• MyApp هو العميل (الهوية) الذي يطلب الوصول إلى Google Drive (المورد).
• يمنح المستخدم (مالك المورد) الإذن لـ MyApp في الخطوة 6، واكتمال عملية التفويض.

عنصر مهم في OAuth 2.0 هو رمز الوصول، الذي يستخدمه العميل لإثبات تفويض المستخدم للوصول إلى الموارد. للغوص بشكل أعمق، انظر رمز الوصول.

OpenID Connect (OIDC)#

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

إذا عدنا إلى تدفق OAuth، فإن إضافة OIDC تُدخِل رمز الهوية. يحتوي هذا الرمز على معلومات حول المستخدم الذي تم التحقق من هويته ويسمح لـ MyApp بالتحقق من هوية المستخدم.

مثال سيناريو: "تسجيل الدخول باستخدام Google"#

لنغير الأمثلة. إذا أراد MyApp أن يسمح للمستخدمين بتسجيل الدخول باستخدام حساباتهم في Google، يتحول الهدف إلى التحقق من الهوية بدلاً من الوصول إلى الموارد. في هذه الحالة، يكون OIDC أكثر ملاءمة. إليك كيف يبدو تدفق OIDC:

الفرق الأساسي: بالإضافة إلى رمز الوصول، يوفر OIDC رمز الهوية، والذي يسمح لـ MyApp بالتحقق من هوية المستخدم دون الحاجة إلى طلبات إضافية.

يتشارك OIDC تعاريف المنح الخاصة بـ OAuth 2.0، مما يضمن التوافق والاتساق بين الإطارين.

SAML#

لغة تأكيد الأمن المرقمي (SAML) هي إطار عمل يعتمد على لغة XML لتبادل بيانات التحقق من الهوية والتفويض بين الأطراف. تم تقديم SAML في بدايات القرن العشرين واعتمدت بشكل واسع في بيئات الشركات.

كيف يمكن مقارنة SAML مع OIDC؟#

SAML وOIDC هما من الناحية الوظيفية متشابهان ولكن يختلفان في تفاصيل تنفيذها:

• SAML: يستخدم التأكيدات المستندة إلى XML وغالبًا ما يُعتبر أكثر تعقيدًا.
• OIDC: يستفيد من JSON وJWT، مما يجعله أخف وزنا وأكثر صداقة للمطورين.

غالبًا ما تفضل التطبيقات الحديثة OIDC لبساطته ومرونته، لكن SAML لا يزال شائعًا في الأنظمة القديمة وحالات الاستخدام المؤسساتية.

تسجيل الدخول الموحد (SSO)#

تسجيل الدخول الموحد (SSO) هو مخطط التحقق من الهوية الذي يمكّن المستخدمين من الوصول إلى تطبيقات وخدمات متعددة مع مجموعة واحدة من بيانات الاعتماد. بدلاً من تسجيل الدخول إلى كل تطبيق بشكل فردي، يسجل المستخدم الدخول مرة واحدة ويحصل على الوصول إلى جميع الأنظمة المتصلة.

كيف يعمل SSO؟#

يعتمد SSO على مزود هوية مركزي لإدارة هويات المستخدمين. يقوم مزود الهوية بالتحقق من هوية المستخدم ويقدم خدمات مثل التحقق من الهوية والتفويض للتطبيقات المتصلة.

يمكن لمزود الهوية استخدام بروتوكولات مثل OIDC أو OAuth 2.0 أو SAML أو غيرها لتقديم هذه الخدمات. يمكن لمزود هوية واحد دعم بروتوكولات متعددة لتلبية الاحتياجات المتنوعة لتطبيقات مختلفة.

مثال على SSO المستند إلى OIDC#

لنتعمق في مثال على SSO المستند إلى OIDC:

في هذا التدفق، يقوم المستخدم بتسجيل الدخول إلى IdP مرة واحدة ويتم التحقق من هويته عبر تطبيقات متعددة (AppA وAppB).

SSO المؤسساتي#

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

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

مثال: إضافة مزود SSO المؤسساتي#

إليك مثال مبسط عن دمج مزود SSO المؤسساتي (Banana) مع تطبيقك (MyApp):

JWT#

رمز الويب المرمز JSON (JWT) هو معيار مفتوح يعَرَّف في RFC 7519 الذي يمكّن من التواصل الآمن بين طرفين. وهو الشكل المعياري لرموز الهوية في OIDC ويستخدم بشكل واسع لرموز الوصول OAuth 2.0.

إليك السمات الرئيسية لـ JWT:

• مضغوط: تعد JWT كائنات JSON مرمزًا في شكل مضغوط، مما يجعلها سهلة النقل والتخزين.
• مكتف بذاته: تحتوي JWT على جميع المعلومات الضرورية حول المستخدم والرمز نفسه.
• قابلة للتَّحقُّق والتشفير: يمكن توقيع JWT وتشفيرها لضمان تكامل البيانات وسريتها.

تبدو JWT التقليدية كما يلي:

يتكون هذا الرمز JWT من ثلاثة أجزاء مفصولة بنقاط:

• الرأس: يحتوي على معلومات تعريفية حول الرمز، مثل نوع الرمز وخوارزمية التوقيع.
• الحمولة: تحتوي على معلومات حول الهوية والرمز نفسه.
• التوقيع: يثبت تكامل الرمز.

كلا الرأس والحمولة هما كائنات JSON مرمزًا بتقنية Base64. يمكن فك ترميز JWT أعلاه كما يلي:

باستخدام JWT، يمكن للعميل فك ترميز الرمز واستخراج معلومات المستخدم دون تقديم طلبات إضافية لمزود الهوية. لمزيد من المعلومات حول JWT، قم بزيارة JSON Web Token (JWT).

ملخص#

قد غطينا العديد من المفاهيم في هذا المقال. دعونا نلخص النقاط الرئيسية بمثال:

تخيل أن لديك تطبيق ويب، AppA، يتطلب حلاً لـ إدارة الهوية والوصول (IAM). تختار Logto، مزود هوية يستخدم OpenID Connect (OIDC) للتحقق من الهوية. نظرًا لأن OIDC مبني على OAuth 2.0، يدعم Logto أيضًا التفويض لتطبيقك.

لتقليل العوائق لمستخدميك، يمكنك تفعيل "التسجيل باستخدام Google" في Logto. يستخدم هذا OAuth 2.0 لتبادل بيانات التفويض ومعلومات المستخدم بين Logto وGoogle.

بعد أن يسجل المستخدم الدخول إلى AppA عبر Logto، يستلم AppA رمز هوية، وهو رمز الويب المرمز JSON (JWT) يحتوي على معلومات المستخدم.

مع نمو عملك، تطلق تطبيقًا جديدًا، AppB، الذي يحتاج أيضًا إلى التحقق من هوية المستخدم. نظرًا لأن Logto مُعّدد بالفعل، يمكنك إعادة استخدام نفس عملية التحقق للتطبيق B. يمكن الآن لمستخدميك تسجيل الدخول إلى كل من AppA وAppB باستخدام مجموعة واحدة من بيانات الاعتماد، وهي ميزة تُعرف باسم تسجيل الدخول الموحد (SSO).

لاحقًا، يطلب منك شريك الأعمال ربط نظام SSO الخاص بهم، الذي يستخدم لغة تأكيد الأمن المرقمي (SAML). تجد أن Logto يدعم وصلات SAML، لذا تقوم بإعداد اتصال بين Logto ونظام SSO الخاص بالشريك. الآن، يمكن للمستخدمين من مؤسسة الشريك تسجيل الدخول أيضًا إلى AppA وAppB باستخدام بيانات الاعتماد الحالية لديهم.

---

آمل أن يكون هذا المقال قد أوضح لك هذه المفاهيم. لمزيد من التفسيرات المتعمقة والأمثلة، تحقق من Auth Wiki. إذا كنت تبحث عن حل IAM لتطبيقك، فكر في استخدام خدمة مدارة مثل Logto لتوفير الوقت والجهد.