Share via

المصادقة والتخويل لواجهات برمجة التطبيقات في Azure API Management

  • مقالة

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

هذه المقالة هي مقدمة لمجموعة غنية ومرنة من الميزات في APIM التي تساعدك على تأمين وصول المستخدمين إلى واجهات برمجة التطبيقات المدارة.

تتضمن مصادقة واجهة برمجة التطبيقات وتخويلها في APIM تأمين الاتصال الشامل لتطبيقات العميل إلى بوابة APIM ومن خلال واجهات برمجة التطبيقات الخلفية. في العديد من بيئات العملاء، OAuth 2.0 هو بروتوكول تخويل واجهة برمجة التطبيقات المفضل. تدعم APIM تخويل OAuth 2.0 بين العميل وبوابة APIM، بين البوابة وواجهة برمجة التطبيقات الخلفية، أو كليهما بشكل مستقل.

رسم تخطيطي يوضح نقاط التفاعل لتأمين واجهات برمجة التطبيقات.

تدعم APIM آليات المصادقة والتخويل الأخرى من جانب العميل والخدمة التي تكمل OAuth 2.0 أو التي تكون مفيدة عندما لا يكون تخويل OAuth 2.0 لواجهات برمجة التطبيقات ممكنا. تعتمد كيفية الاختيار من بين هذه الخيارات على نضج بيئة واجهة برمجة التطبيقات لمؤسستك ومتطلبات الأمان والتوافق ونهج مؤسستك للتخفيف من تهديدات واجهة برمجة التطبيقات الشائعة.

هام

تأمين وصول المستخدمين إلى واجهات برمجة التطبيقات هو واحد من العديد من الاعتبارات لتأمين بيئة APIM الخاصة بك. لمزيد من المعلومات، راجع أساس أمان Azure لإدارة واجهة برمجة التطبيقات.

إشعار

تحتوي مكونات API Management الأخرى على آليات منفصلة لتأمين وصول المستخدم وتقييده:

  • لإدارة مثيل إدارة واجهة برمجة التطبيقات من خلال وحدة التحكم في Azure، تعتمد إدارة واجهة برمجة التطبيقات على معرف Microsoft Entra والتحكم في الوصول المستند إلى الدور (RBAC) في Azure.
  • يدعم مدخل مطور APIM العديد من الخيارات لتسهيل تسجيل المستخدم وتسجيل الدخول الآمن.

المصادقة مقابل التخويل

فيما يلي شرح موجز للمصادقة والتخويل في سياق الوصول إلى واجهات برمجة التطبيقات:

  • المصادقة - عملية التحقق من هوية مستخدم أو تطبيق يصل إلى واجهة برمجة التطبيقات. يمكن إجراء المصادقة من خلال بيانات اعتماد مثل اسم المستخدم وكلمة المرور أو الشهادة أو من خلال تسجيل الدخول الأحادي (SSO) أو أساليب أخرى.

  • التخويل - عملية تحديد ما إذا كان المستخدم أو التطبيق لديه إذن للوصول إلى واجهة برمجة تطبيقات معينة، غالبا من خلال بروتوكول يستند إلى الرمز المميز مثل OAuth 2.0.

إشعار

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

مفاهيم OAuth 2.0

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

تدفق OAuth

ماذا يحدث عندما يستدعي تطبيق عميل واجهة برمجة تطبيقات مع طلب مؤمن باستخدام TLS وOAuth 2.0؟ فيما يلي مثال مختصر على التدفق:

  • العميل (تطبيق الاتصال أو الحامل) يصادق باستخدام بيانات الاعتماد لـ موفر الهوية.

  • العميل يحصل على رمز وصول محدود الوقت (رمز ويب JSON أو JWT) من خادم تخويل موفر الهوية.

    موفر الهوية (على سبيل المثال، معرف Microsoft Entra) هو مصدر الرمز المميز، ويتضمن الرمز المميز مطالبة جماعة مستهدفة تخول الوصول إلى خادم موارد (على سبيل المثال، إلى واجهة برمجة تطبيقات خلفية أو إلى بوابة APIM نفسها).

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

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

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

اعتمادا على نوع تطبيق العميل والسيناريوهات، هناك حاجة إلى تدفقات تخويل مختلفة لطلب الرموز المميزة وإدارتها. على سبيل المثال، يتم استخدام تدفق رمز التخويل ونوع المنح بشكل شائع في التطبيقات التي تستدعي واجهات برمجة تطبيقات الويب. تعرف على المزيد حول تدفقات OAuth وسيناريوهات التطبيق في معرف Microsoft Entra.

سيناريوهات تخويل OAuth 2.0 في APIM

السيناريو 1 - يخول تطبيق العميل الواجهة الخلفية مباشرة

سيناريو التخويل الشائع هو عندما يطلب تطبيق الاستدعاء الوصول إلى واجهة برمجة التطبيقات الخلفية مباشرة ويقدم رمز OAuth 2.0 المميز في عنوان التخويل إلى البوابة. ثم تعمل Azure API Management كوكيل "شفاف" بين المتصل وواجهة برمجة التطبيقات الخلفية، وتمرر الرمز المميز من خلال دون تغيير إلى الخلفية. نطاق الرمز المميز للوصول بين تطبيق الاستدعاء وواجهة برمجة التطبيقات الخلفية.

تعرض الصورة التالية مثالا حيث معرف Microsoft Entra هو موفر التخويل. قد يكون تطبيق العميل تطبيقا من صفحة واحدة (SPA).

مخطط يعرض اتصال OAuth حيث يكون الجهور هو الخلفية.

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

إشعار

إذا قمت بتأمين واجهة برمجة تطبيقات مكشوفة من خلال Azure API Management باستخدام OAuth 2.0 بهذه الطريقة، يمكنك تكوين إدارة واجهة برمجة التطبيقات لإنشاء رمز مميز صالح لأغراض الاختبار نيابة عن مدخل Microsoft Azure أو مستخدم وحدة تحكم اختبار مدخل المطور. تحتاج إلى إضافة خادم OAuth 2.0 إلى مثيل APIM وتمكين إعدادات تخويل OAuth 2.0 في واجهة برمجة التطبيقات. لمزيد من المعلومات، راجع كيفية تخويل وحدة تحكم الاختبار لمدخل المطور عن طريق تكوين تخويل مستخدم OAuth 2.0.

مثال:

تلميح

في الحالة الخاصة عندما يكون الوصول إلى واجهة برمجة التطبيقات محميا باستخدام معرف Microsoft Entra، يمكنك تكوين نهج validate-azure-ad-token للتحقق من صحة الرمز المميز.

السيناريو 2 - يخول تطبيق العميل إدارة واجهة برمجة التطبيقات

في هذا السيناريو، تعمل خدمة APIM نيابة عن واجهة برمجة التطبيقات، ويطلب تطبيق الاستدعاء الوصول إلى مثيل APIM. نطاق الرمز المميز للوصول بين تطبيق الاستدعاء وبوابة APIM. في APIM، قم بتكوين نهج (validate-jwt أو validate-azure-ad-token) للتحقق من صحة الرمز المميز قبل أن تمرر البوابة الطلب إلى الخلفية. عادة ما تؤمن آلية منفصلة الاتصال بين البوابة وواجهة برمجة التطبيقات الخلفية.

في المثال التالي، معرف Microsoft Entra هو مرة أخرى موفر التخويل، وتؤمن مصادقة TLS المتبادلة (mTLS) الاتصال بين البوابة والواجهة الخلفية.

مخطط يعرض اتصال OAuth حيث يكون الجهور هو بوابة APIM.

هناك أسباب مختلفة للقيام بذلك. على سبيل المثال:

  • الخلفية هي واجهة برمجة تطبيقات قديمة لا يمكن تحديثها لدعم OAuth

    يجب أولاً تكوين APIM للتحقق من صحة الرمز المميز (التحقق من مطالبات المصدر والجمهور كحد أدنى). بعد التحقق من الصحة، استخدم أحد الخيارات المتعددة المتاحة لتأمين الاتصالات اللاحقة من APIM، مثل مصادقة TLS (mTLS) المتبادلة. راجع خيارات جانب الخدمة، لاحقا في هذه المقالة.

  • لا يمكن إنشاء السياق المطلوب من قبل الخلفية من المتصل

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

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

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

  • تريد المنظمة اعتماد نهج تخويل موحد

    بغض النظر عن آليات المصادقة والتخويل على واجهات API الخلفية الخاصة بها، قد تختار المؤسسات التقارب على OAuth 2.0 لنهج تخويل موحد على الواجهة الأمامية. يمكن لبوابة APIM تمكين تكوين تخويل متسق وتجربة شائعة لمستهلكي واجهة برمجة التطبيقات مع تطور الخلفيات للمؤسسة.

السيناريو 3: تخول APIM الواجهة الخلفية

باستخدام الاتصالات المدارة (التي كانت تسمى سابقا التخويلات)، يمكنك استخدام مدير بيانات الاعتماد في APIM لتخويل الوصول إلى واحدة أو أكثر من خدمات الواجهة الخلفية أو SaaS، مثل LinkedIn أو GitHub أو الواجهات الخلفية الأخرى المتوافقة مع OAuth 2.0. في هذا السيناريو، يقدم مستخدم أو تطبيق عميل طلبا إلى بوابة APIM، مع التحكم في الوصول إلى البوابة باستخدام موفر هوية أو خيارات جانب العميل الأخرى. ثم، من خلال تكوين النهج، يقوم تطبيق المستخدم أو العميل بتفويض المصادقة الخلفية والتخويل إلى APIM.

في المثال التالي، يتم استخدام مفتاح اشتراك بين العميل والبوابة، وGitHub هو موفر بيانات الاعتماد لواجهة برمجة التطبيقات الخلفية.

رسم تخطيطي يوضح التخويل لخدمة SaaS الخلفية باستخدام اتصال مدار في إدارة بيانات الاعتماد.

من خلال الاتصال بموفر بيانات الاعتماد، تحصل APIM على الرموز المميزة للوصول إلى واجهة برمجة التطبيقات في تدفق OAuth 2.0 وحدثها. تبسط الاتصال إدارة الرمز المميز في سيناريوهات متعددة، مثل:

  • قد يحتاج تطبيق العميل إلى تخويل واجهات SaaS الخلفية المتعددة لحل حقول متعددة باستخدام محللات GraphQL.
  • يقوم المستخدمون بالمصادقة على API Management بواسطة SSO من موفر الهوية الخاص بهم، ولكن يصرحون لموفر SaaS الخلفية (مثل LinkedIn) باستخدام حساب تنظيمي مشترك.
  • يحتاج تطبيق العميل (أو الروبوت) إلى الوصول إلى الموارد عبر الإنترنت المؤمنة الخلفية نيابة عن مستخدم مصادق عليه (على سبيل المثال، التحقق من رسائل البريد الإلكتروني أو تقديم طلب).

أمثلة:

خيارات أخرى لتأمين واجهات برمجة التطبيقات

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

خيارات جانب العميل

آلِيَّة ‏‏الوصف الاعتبارات
mTLS التحقق من صحة الشهادة المقدمة من قبل العميل المتصل والتحقق من خصائص الشهادة مقابل شهادة مدارة في APIM قد يتم تخزين الشهادة في مخزن مفاتيح.
Restrict caller IPs تصفية المكالمات (السماح/الرفض) من عناوين IP أو نطاقات عناوين محددة. يستخدم لتقييد الوصول إلى مستخدمين أو مؤسسات معينة، أو لحركة المرور من الخدمات الأولية.
مفتاح الاشتراك تقييد الوصول إلى واحد أو أكثر من واجهات برمجة التطبيقات استنادا إلى اشتراك APIM نوصي باستخدام مفتاح اشتراك (API) بالإضافة إلى طريقة أخرى للمصادقة أو التخويل. من تلقاء نفسه، لا يعد مفتاح الاشتراك شكلا قويا من أشكال المصادقة، ولكن قد يكون استخدام مفتاح الاشتراك مفيدا في سيناريوهات معينة، على سبيل المثال، تعقب استخدام واجهة برمجة التطبيقات للعملاء الفرديين أو منح حق الوصول إلى منتجات واجهة برمجة تطبيقات معينة.

تلميح

للدفاع في العمق، يوصى بشدة بنشر جدار حماية تطبيق ويب في المصدر لمثيل APIM. على سبيل المثال، استخدم بوابة تطبيق Azure أو Azure Front Door.

خيارات جانب الخدمة

آلِيَّة ‏‏الوصف الاعتبارات
استخدام مُصادقة الهوية المدارة المصادقة على واجهة برمجة التطبيقات الخلفية باستخدام هوية مدارة يعينها النظام أو يعينها المستخدم. يوصى به للوصول المحدد النطاق إلى مورد خلفية محمي عن طريق الحصول على رمز مميز من معرف Microsoft Entra.
مصادقة الشهادة المصادقة على واجهة برمجة التطبيقات الخلفية باستخدام شهادة عميل. قد يتم تخزين الشهادة في مخزن المفاتيح.
المصادقة الأساسية المصادقة على واجهة برمجة التطبيقات الخلفية باستخدام اسم المستخدم وكلمة المرور التي يتم تمريرها من خلال عنوان التخويل. لا ينصح إذا توفرت خيارات أفضل.

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