OAuth 2.0 وOpenID Connect (OIDC) على النظام الأساسي للهويات في Microsoft

لست بحاجة إلى تعلم OAuth أو OpenID Connect (OIDC) على مستوى البروتوكول لاستخدام النظام الأساسي للهويات في Microsoft. ومع ذلك، ستواجه هذه المصطلحات والمفاهيم البروتوكولية وغيرها أثناء استخدامك للنظام الأساسي للهوية لإضافة وظيفة المصادقة إلى تطبيقاتك.

أثناء عملك مع مدخل Microsoft Azure ووثائقنا ومكتبات المصادقة الخاصة بنا، يمكن أن تؤدي معرفة بعض الأساسيات مثل هذه إلى تسهيل مهام التكامل وتصحيح الأخطاء.

الأدوار في OAuth 2.0

عادة ما تشارك أربعة أطراف في OAuth 2.0 وOpenID Connect المصادقة وتبادل التخويل. وغالبًا ما تسمى هذه التبادلات تدفقات المصادقة أو التدفقات الخاصة بالمصادقة.

Diagram showing the OAuth 2.0 roles

  • خادم التخويل - النظام الأساسي للهويات في Microsoft نفسه هو خادم التخويل. يُطلق عليه أيضًا موفر الهوية أو IdP، وهو يتعامل بشكل آمن مع معلومات المستخدم النهائي ووصوله وعلاقات الثقة بين الأطراف في تدفق المصادقة. يصدر خادم التخويل الرموز المميزة للأمان التي تستخدمها تطبيقاتك وواجهات برمجة التطبيقات لمنح الوصول إلى الموارد (التخويل) أو رفضه أو إبطاله بعد تسجيل دخول المستخدم (المُصادق عليه).

  • العميل - العميل في تبادل OAuth هو التطبيق الذي يطلب الوصول إلى مورد محمٍ. يمكن أن يكون العميل تطبيق ويب يعمل على خادم، أو تطبيق ويب من صفحة واحدة يعمل في مستعرض الويب الخاص بالمستخدم، أو واجهة برمجة تطبيقات ويب تستدعي واجهة برمجة تطبيقات ويب أخرى. سترى غالبًا العميل المشار إليه باسم تطبيق العميل أو التطبيق أو تطبيق.

  • مالك المورد - عادةً ما يكون مالك المورد في تدفق المصادقة هو مستخدم التطبيق أو المستخدم النهائي في مصطلحات OAuth. "يمتلك" المستخدم النهائي المورد المحمي - بياناته - بحيث يصل تطبيقك نيابة عنه. يمكن لمالك المورد منح تطبيقك (العميل) حق الوصول إلى الموارد التي يمتلكها أو رفضه. على سبيل المثال، قد يتصل تطبيقك بواجهة برمجة تطبيقات نظام خارجي للحصول على عنوان البريد الإلكتروني للمستخدم من ملفه الشخصي على هذا النظام. تعد بيانات ملفه الشخصي موردًا يمتلكه المستخدم النهائي على النظام الخارجي، ويمكن للمستخدم النهائي الموافقة على طلب تطبيقك للوصول إلى بياناته أو رفضه.

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

الرموز المميزة

تستخدم الأطراف في تدفق المصادقة الرموز المميزة للمالك لضمان مدير (مستخدم أو مضيف أو خدمة) والتحقق منه والمصادقة عليه تحديد الهوية (المصادقة) ومنح الوصول إلى الموارد المحمية أو رفضه (التخويل). يتم تنسيق الرموز المميزة لحاملها في النظام الأساسي للهويات في Microsoft على أنها رموز ويب JSON مميزة (JWT).

يتم استخدام ثلاثة أنواع من الرموز المميزة لحاملها من قبل النظام الأساسي للهويات في Microsoft كرموز أمان مميزة:

  • رموز الوصول المميزة - رموز وصول مميزة يتم إصدارها من قِبل خادم التخويل إلى تطبيق العميل. يقوم العميل بتمرير رموز الوصول المميز إلى خادم المورد. تحتوي الرموز المميزة للوصول على الأذونات التي تم منحها للعميل بواسطة خادم التخويل.

  • الرموز المميزة للمعرف - يتم إصدار الرموز المميزة للمعرف بواسطة خادم التخويل لتطبيق العميل. يستخدم العملاء الرموز المميزة للمعرف عند تسجيل دخول المستخدمين والحصول على معلومات أساسية عنهم.

  • الرموز المميزة للتحديث - يستخدم العميل رمزًا مميزًا للتحديث، أو RT، لطلب رموز مميزة جديدة للوصول والمعرف من خادم التخويل. يجب أن تتعامل التعليمات البرمجية الخاصة بك مع رموز التحديث ومحتوى السلسلة الخاص بها على أنها غير شفافة، لأنها مخصصة للاستخدام فقط بواسطة خادم التخويل.

تسجيل تطبيق

يحتاج تطبيق العميل الخاص بك إلى طريقة للوثوق برموز الأمان الصادرة إليه من قِبل النظام الأساسي للهويات في Microsoft. تتمثل الخطوة الأولى في إنشاء هذه الثقة في تسجيل تطبيقك مع النظام الأساسي للهوية في Azure Active Directory (Azure AD).

عند تسجيل تطبيقك في Azure AD، يقوم النظام الأساسي للهويات في Microsoft تلقائيًا بتعيين بعض القيم له، بينما تقوم بتكوين قيم أخرى استنادًا إلى نوع التطبيق.

اثنان من إعدادات تسجيل التطبيق الأكثر شيوعًا المشار إليهما هما:

  • معرف التطبيق (العميل) - يسمى أيضًا معرف التطبيق ومعرف العميل، ويتم تعيين هذه القيمة لتطبيقك بواسطة النظام الأساسي للهويات في Microsoft. يحدد معرف العميل تطبيقك بشكل فريد في النظام الأساسي للهوية، ويتم تضمينه في رموز الأمان المميزة التي تصدرها مشكلات النظام الأساسي.
  • إعادة توجيه عنوان URI يستخدم خادم التخويل عنوان URI لإعادة التوجيه لتوجيه عامل المستخدم الخاص بمالك المورد (متصفح الويب وتطبيق الأجهزة المحمولة) إلى وجهة أخرى بعد إكمال تفاعله. على سبيل المثال، بعد مصادقة المستخدم النهائي باستخدام خادم التخويل. لا تستخدم جميع أنواع العملاء عناوين URI لإعادة التوجيه.

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

نقاط النهاية

يقدم النظام الأساسي للهويات في Microsoft خدمات المصادقة والتخويل باستخدام تطبيقات متوافقة مع المعايير لـ OAuth 2.0 وOpenID Connect (OIDC) 1.0. توفر خوادم التخويل المتوافقة مع المعايير، مثل النظام الأساسي للهويات في Microsoft مجموعة من نقاط نهاية HTTP لاستخدامها من قبل الأطراف في تدفق المصادقة لتنفيذ التدفق.

يتم إنشاء عناوين URI لنقطة النهاية لتطبيقك نيابة عنك عند تسجيل تطبيقك أو تكوينه في Azure AD. تعتمد نقاط النهاية التي تستخدمها في التعليمات البرمجية لتطبيقك على نوع التطبيق والهويات (أنواع الحسابات) التي يجب أن يدعمها.

نقطتا نهاية شائعتا الاستخدام هما نقطة نهاية التخويل ونقطة نهاية الرمز المميز. فيما يلي أمثلة على نقاط النهاية authorize وtoken:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

للعثور على نقاط النهاية لتطبيق قمت بتسجيله، انتقل في مدخل Azure إلى:

تسجيلات تطبيق Azure Active Directory>App><YOUR-APPLICATION>>Endpoints

الخطوات التالية

بعد ذلك، تعرف على تدفقات مصادقة OAuth 2.0 المستخدمة من قبل كل نوع من أنواع التطبيقات والمكتبات التي يمكنك استخدامها في تطبيقاتك لتنفيذها:

ننصح بشدة بعدم صياغة مكتبتك الخاصة أو مكالمات HTTP الخام لتنفيذ تدفقات المصادقة. مكتبة مصادقة Microsoft أكثر أماناً وأسهل بكثير. ومع ذلك، إذا كان السيناريو الخاص بك يمنعك من استخدام مكتباتنا أو كنت ترغب فقط في معرفة المزيد حول تنفيذ النظام الأساسي للهوية، فلدينا مرجع بروتوكول: