مشاركة عبر

طريقة إنشاء وحدة تحكم الاختبار لمدخل المطور من خلال تكوين إنشاء مستخدم OAuth 2.0

  • مقالة

ينطبق على: المطور | أساسي | الإصدار 2 الأساسي | قياسي | الإصدار 2 القياسي | بريميوم

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

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

المتطلبات الأساسية

توضح لك هذه المقالة كيفية تكوين مثيل خدمة APIM لاستخدام تفويض OAuth 2.0 في وحدة التحكم التجريبية لبوابة المطورين، ولكنها لا توضح لك كيفية تكوين موفر OAuth 2.0.

إذا لم تُنشئ بعد مثيل خدمة APIM، انظرإنشاء مثيل خدمة APIM.

نظرة عامة على السيناريو

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

فيما يلي خطوات التكوين عالية المستوى:

  1. تسجيل تطبيق (تطبيق خلفي) في معرف Microsoft Entra لتمثيل واجهة برمجة التطبيقات.

  2. تسجيل تطبيق آخر (تطبيق العميل) في معرف Microsoft Entra لتمثيل تطبيق عميل يحتاج إلى استدعاء واجهة برمجة التطبيقات - في هذه الحالة، وحدة تحكم الاختبار لمدخل المطور.

    في Microsoft Entra ID، امنح أذونات للسماح لتطبيق العميل باستدعاء التطبيق الخلفي.

  3. تكوين وحدة تحكم الاختبار في بوابة المطور لاستدعاء API باستخدام ترخيص مستخدم OAuth 2.0.

  4. تهيئة API لاستخدام ترخيص مستخدم OAuth 2.0.

  5. إضافة نهج لتخويل رمز OAuth 2.0 المميز مسبقا لكل طلب وارد. يمكنك استخدام النهج validate-jwt لأي موفر OAuth 2.0.

يدعم هذا التكوين تدفق OAuth التالي:

رسم نظرة عامة لوضع تصور مرئي للتدفق التالي.

  1. يطلب مدخل المطور رمزا مميزا من معرف Microsoft Entra باستخدام بيانات اعتماد تطبيق العميل.

  2. بعد التحقق من الصحة بنجاح، يصدر معرف Microsoft Entra الرمز المميز للوصول/التحديث.

  3. يقوم المطور (مستخدم مدخل المطور) بإجراء استدعاء واجهة برمجة التطبيقات مع عنوان التخويل.

  4. يتم التحقق من صحة الرمز المميز باستخدام النهج validate-jwt في APIM بواسطة معرف Microsoft Entra.

  5. بناء على نتيجة التحقق من الصحة، سيتلقى المطور الاستجابة في مدخل المطور.

منحة التخويل

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

فيما يلي ملخص ذو مستوى عالي. للحصول على مزيد من المعلومات بشأن أنواع المنح، راجع نوعيمنحة OAuth 2.0 Authorization FrameworkوOAuth.

نوع المنحة ‏‏الوصف السيناريوهات
التعليمة البرمجية للتخويل تبديل رمز التخويل بالرمز المميز التطبيقات من جانب الخادم على سبيل المثال تطبيقات الويب
رمز التخويل + PKCE تحسين تدفق التعليمات البرمجية للتخويل الذي ينشئ تحدي تعليمة برمجية يتم إرساله مع طلب التخويل عملاء الجوال والعامة الذين لا يمكنهم حماية سر أو رمز مميز
ضمني (مهمل) إعادة الرمز المميز للوصول على الفور دون خطوة تبادل تخويل تعليمة برمجية إضافية العملاء الذين لا يمكنهم حماية البيانات السرية أو الرمز المميز مثل تطبيقات الأجهزة المحمولة وتطبيقات الصفحة الواحدة

لا يوصى به بشكل عام بسبب المخاطر الموجودة في إعادة الرمز المميز للوصول في إعادة توجيه HTTP دون تأكيد استلامه من قِبل العميل
كلمة مرور مالك المورد عادةً يطلب بيانات اعتماد المستخدم (اسم المستخدم وكلمة المرور)، باستخدام نموذج تفاعلي للاستخدام مع التطبيقات الموثوق بها بدرجة كبيرة

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

اعتبارات الأمان

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

عند تكوين تخويل المستخدم OAuth 2.0 في وحدة تحكم الاختبار لمدخل المطور:

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

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

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

تتبع المعلومات الأساسية

يُطلب منك خلال هذا البرنامج التعليمي تسجيل المعلومات الأساسية للرجوع إليها لاحقاً:

  • معرف تطبيق الخلفية (العميل):المعرف الفريد العمومي للتطبيق الذي يمثل API الخلفية
  • نطاقات تطبيق الخلفية: نطاق واحد أو أكثر قد تنشئه للوصول إلى واجهة برمجة التطبيقات. يعد تنسيق النطاقapi://<Backend Application (client) ID>/<Scope Name>(على سبيل المثال، api://1764e900-1827-4a0b-9182-b2c1841864c2/Read)
  • معرف تطبيق الخلفية (العميل):المعرف الفريد العمومي للتطبيق الذي يمثل مدخل المطور
  • Client Application Secret Value: المعرف الفريد العمومي (GUID) الذي يعمل كسر للتفاعل مع تطبيق العميل في Microsoft Entra ID

تسجيل التطبيقات باستخدام خادم OAuth

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

فيما يلي أمثلة على الخطوات باستخدام معرف Microsoft Entra كموفر OAuth 2.0. للحصول على تفاصيل حول تسجيل التطبيق، راجع التشغيل السريع: تكوين تطبيق لعرض واجهة برمجة تطبيقات الويب.

تسجيل تطبيق في معرف Microsoft Entra لتمثيل واجهة برمجة التطبيقات

  1. في مدخل Microsoft Azure، ابحث عن App registrations وحددها.

  2. حدد تسجيل جديد.

  3. عندما تظهر صفحة تسجيل تطبيق، أدخل معلومات تسجيل التطبيق الخاص بك:

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

  4. اترك قسم Redirect URI فارغا. ستضيف لاحقاً عنوان URI لإعادة التوجيه تم إنشاؤه في تكوين OAuth 2.0 في APIM.

  5. حدد Register لإنشاء التطبيق.

  6. في صفحة نظرة عامة على التطبيق، ابحث عن قيمة معرف التطبيق (العميل) وسجلها لاحقا.

  7. ضمن قسم إدارة من القائمة الجانبية، حدد كشف واجهة برمجة التطبيقات وقم بتعيين معرف التطبيق URI بالقيمة الافتراضية. سجل هذه القيمة في وقت لاحق.

  8. حدد الزر Add a scope لعرض صفحة Add a scope:

    1. أدخل اسم نطاق لنطاق معتمد من قبل واجهة برمجة التطبيقات (على سبيل المثال، Files.Read).
    2. في روبوت Who يمكن الموافقة؟، قم بتحديد السيناريو الخاص بك، مثل مسؤول والمستخدمين. حدد مسؤول فقط للسيناريوهات ذات الامتيازات الأعلى.
    3. أدخل اسم عرض الموافقة مسؤول ووصف الموافقة مسؤول.
    4. تأكد من تحديد حالة النطاق الممكن .

  9. حدد الزر Add scope لإنشاء النطاق.

  10. تكرار الخطوتين السابقتين لإضافة كافة النطاقات التي يدعمها API الخاصة بك.

  11. بمجرد إنشاء النطاقات، قم بتدوينها لاستخدامها في خطوة لاحقة.

تسجيل تطبيق آخر في معرف Microsoft Entra لتمثيل تطبيق عميل

تسجيل كل تطبيق عميل يستدعي واجهة برمجة التطبيقات كتطبيق في معرف Microsoft Entra.

  1. في مدخل Microsoft Azure، ابحث عن App registrations وحددها.

  2. حدد تسجيل جديد.

  3. عندما تظهر صفحة تسجيل تطبيق، أدخل معلومات تسجيل التطبيق الخاص بك:

    • في قسم Name ، أدخل اسم تطبيق ذا معنى سيتم عرضه لمستخدمي التطبيق، مثل client-app.
    • في قسم أنواع الحسابات المدعومة، حدد خيارا يناسب السيناريو الخاص بك.

  4. في قسم Redirect URI ، حدد Web واترك حقل URL فارغا في الوقت الحالي.

  5. حدد Register لإنشاء التطبيق.

  6. في صفحة نظرة عامة على التطبيق، ابحث عن قيمة معرف التطبيق (العميل) وسجلها لاحقا.

  7. قم بإنشاء سر عميل لهذا التطبيق لاستخدامه في خطوة لاحقة.

    1. ضمن قسمإدارةالقائمة الجانبية، حدد الشهادات والبيانات السرية.
    2. ضمن البيانات السرية للعميل، حدد + بيانات سرية جديدة للعميل.
    3. ضمن Add a client secret، قم بتوفير Description واختر متى يجب أن تنتهي صلاحية المفتاح.
    4. حدد إضافة.

عند إنشاء السر، لاحظ قيمة المفتاح للاستخدام في خطوة لاحقة. لا يمكنك توصيل البيانات السرية مجدداً في المدخل.

منح الأذونات في معرف Microsoft Entra

الآن بعد أن سجلت تطبيقين لتمثيل API ووحدة التحكم التجريبية، امنح أذونات للسماح لتطبيق العميل باستدعاء تطبيق الواجهة الخلفية.

  1. في مدخل Microsoft Azure، ابحث عن App registrations وحددها.

  2. اختر تطبيق العميل الخاص بك. ثم في القائمة الجانبية، قك بتحديدأذونات واجهة برمجة التطبيقات.

  3. قم بتحديد"Add a permission".

  4. ضمن تحديد واجهة برمجة تطبيقات، حدد واجهات برمجة التطبيقات الخاصة بي، ثم ابحث عن التطبيق الخلفي وحدده.

  5. حدد الأذونات المفوضة، ثم حدد الأذونات المناسبة لتطبيق الخلفية.

  6. حدد إضافة أذونات.

اختياريا:

  1. انتقل إلى صفحةأذونات APIلتطبيق العميل.

  2. قم بتحديدمنح موافقة المشرف لـ<اسم المستأجر الخاص بك>لمنح الموافقة نيابة عن جميع المستخدمين في هذا الدليل.

تكوين خادم تخويل OAuth 2.0 في APIM

  1. في مدخل Azure، انتقل إلى مثيل API Management الخاص بك.

  2. ضمن مدخل المطور في القائمة الجانبية، حدد OAuth 2.0 + OpenID الاتصال.

  3. ضمن علامة التبويبOAuth 2.0، قم بتحديدإضافة.

    القائمة OAuth 2.0

  4. أدخل اسمًا ووصفًا اختياريًا في حقلي الاسموالوصف.

    إشعار

    تحدد هذه المجالات خادم مصادقة OAuth 2.0 ضمن خدمة APIM الحالية. لا تأتي قيمهم من خادم OAuth 2.0.

  5. إدخالعنوان URL الخاص بصفحة تسجيل العميل- على سبيل المثال،https://contoso.com/login. هذه الصفحة هي المكان الذي يمكن للمستخدمين فيه إنشاء حساباتهم وإدارتها، في حال كان موفر OAuth 2.0 يدعم إدارة المستخدمين للحسابات. تختلف الصفحة وفقاً لموفر المزامنة OAuth 2.0 المستخدم.

    إذا لم يكن موفر المزامنة OAuth 2.0 الخاص بك لا يشمل إدارة المستخدم للحسابات المكونة، أدخل عنوان URL عنصراً نائباً هنا مثل عنوان URL الخاص بشركتك، أو عنوان URL مثلhttp://localhost.

    خادم OAuth 2.0 الجديد

  6. يحتوي المقطع التالي من النموذج على أنواع منح التخويلو عنوان URL الخاص بنقطة نهاية التخويلوإعدادات أسلوب طلب التخويل.

    • تحديد نوع واحد أو أكثر منأنواع منح التخويلالمطلوبة. في هذا المثال، قم بتحديدرمز التخويل(الافتراضي). معرفة المزيد

    • أدخل عنوان URL الخاص بنقطة النهاية للتخويل. يمكن الحصول على عنوان URL لنقطة النهاية من صفحةنقاط النهايةلأحد تسجيلات التطبيق. بالنسبة لتطبيق مستأجر واحد في معرف Microsoft Entra، سيكون عنوان URL هذا مشابها لأحد عناوين URL التالية، حيث {aad-tenant} يتم استبداله بمعرف مستأجر Microsoft Entra.

      يوصى باستخدام نقطة النهاية v2؛ ومع ذلك، تدعم APIM كلاً من نقطتي النهاية v1 وv2.

      https://login.microsoftonline.com/{aad-tenant}/oauth2/v2.0/authorize (v2)

      https://login.microsoftonline.com/{aad-tenant}/oauth2/authorize (v1)

    • يحدد أسلوب طلب التخويل الطريقة التي يتم من خلالها إرسال طلب التخويل إلى خادم OAuth 2.0. قم بتحديدPOST.

    حدد إعدادات التخويل

  7. حدد عنوان URL لنقطة نهاية الرمز المميز وأساليب مصادقة العميل وطريقة إرسال الرمز المميز للوصول والنطاق الافتراضي.

    • أدخلعنوان URL للرمز المميز لنقطة النهاية. بالنسبة لتطبيق مستأجر واحد في معرف Microsoft Entra، سيكون مشابها لأحد عناوين URL التالية، حيث {aad-tenant} يتم استبداله بمعرف مستأجر Microsoft Entra. استخدام نفس إصدار نقطة النهاية (v2 أو v1) الذي اخترته سابقاً.

      https://login.microsoftonline.com/{aad-tenant}/oauth2/v2.0/token (v2)

      https://login.microsoftonline.com/{aad-tenant}/oauth2/token (v1)

    • إذا كنت تستخدم نقاط النهايةv1، قم بإضافة معلمة نصية:
      * اسم:المورد.
      * القيمة: معرف التطبيق الخلفيمعرف تطبيق (العميل).

    • إذا كنت تستخدم نقطة النهايةv2:
      أدخل نطاق التطبيق الخلفي الذي أنشأته في حقلالنطاق الافتراضي.
      * قم بتعيين قيمة للخاصيةaccessTokenAcceptedVersionإلى2فيبيان التطبيقلكلاً من التطبيق الخلفي وتسجيلات تطبيق العميل.

    • قبول الإعدادات الافتراضيةلأساليب مصادقة العميلوطريقة إرسال الرمز المميز للوصول.

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

  9. بمجرد تحديد معرّفالعميلووبيانات السرية للعميليتم إنشاءRedirect URIلـللتعليمات البرمجية الخاصة بالتخويل. يُستخدم معرف الموارد المنتظم هذا لتكوين URL الرد في تكوين الخادم OAuth 2.0.

    في مدخل المطور، تكون لاحقة URI بالشكل:

    • /signin-oauth/code/callback/{authServerName}تدفق منح التعليمة البرمجية الخاصة بالتخويل
    • /signin-oauth/implicit/callbackتدفق المنح الضمني

    إضافة بيانات اعتماد العميل لخدمة OAuth 2.0

    نسخ عنوان URI المناسب لإعادة التوجيه إلى صفحةالمصادقة لتسجيل تطبيق العميل. في تسجيل التطبيق، حدد Authentication>+ Add a platform>Web، ثم أدخل Redirect URI.

  10. إذا تم تعيين أنواع منحة التخويل إلى كلمة مرور مالك المورد، يتم استخدام المقطع بيانات اعتماد كلمة مرور مالك المورد لتحديد بيانات الاعتماد تلك؛ وإلا يمكنك تركها فارغة.

  11. بمجرد اكتمال النموذج انقر فوقإنشاءلحفظ تكوين ملقم التخويل OAuth 2.0 APIM.

  12. إعادة النشرلمدخل المطور.

    هام

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

تكوين واجهة برمجة تطبيقات لاستخدام تخويل مستخدم OAuth 2.0

بعد حفظ تكوين خادم OAuth 2.0، قم بتكوين واجهة برمجة تطبيقات أو واجهات برمجة التطبيقات لاستخدام هذا التكوين.

هام

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

  1. انقر فوقواجهات برمجة التطبيقاتمن القائمةAPIMفي الجهة اليسرى.

  2. تحديد اسم واجهة برمجة التطبيقات المطلوبة وتحديد علامة التبويبالإعدادات. التمرير إلى قسمالأمان، ثم تحديدOAuth 2.0.

  3. حددخادم التخويلالمطلوب من القائمة المنسدلة، وانقر فوقحفظ.

    تهيئة خادم مصادقة OAuth 2.0

بوابة المطور- اختبر تخويل مستخدم OAuth 2.0

بمجرد تكوين خادم مصادقة OAuth 2.0 وتهيئة واجهة برمجة التطبيقات الخاصة بك لاستخدام ذلك الخادم، فيمكنك اختبارها بالانتقال إلى بوابة المطور والاتصال بواجهة برمجة التطبيقات.

  1. انقر فوقمدخل المطور (قديم)في القائمة العلوية من صفحةنظرة عامة علىمثيل Azure APIM.

  2. تصفح أي عملية تحت API في بوابة المطور.

  3. قم بتحديدجرِّبهلتنتقل بك إلى وحدة تحكم المطور.

  4. لاحظ عنصرا جديدا في قسم التخويل ، يتوافق مع خادم التخويل الذي أضفته للتو.

  5. حدد رمز التخويل من القائمة المنسدلة للتخويل.

    حدد ترخيص التعليمة البرمجية للتخويل

  6. بمجرد مطالبتك، سجل الدخول إلى مستأجر Microsoft Entra.

    • إذا قمت بالفعل دخول إلى الحساب، فقد لاتم مطالبتك بذلك.

  7. بعد تسجيل الدخول بنجاح، Authorization تتم إضافة عنوان إلى الطلب، مع رمز وصول من معرف Microsoft Entra. ما يلي هو الرمز المميز لنموذج مختصر (بتشفير Base64):

    Authorization: Bearer eyJ0eXAiOi[...]3pkCfvEOyA

  8. قم بتكوين القيم المطلوبة للمعلمات المتبقية، وحدد إرسال لاستدعاء واجهة برمجة التطبيقات.

قم بتكوين صورة التحقق من صحة JWT للمصادقة المسبقة على الطلبات

في التكوين حتى الآن، لا تتحقق APIM من صحة الرمز المميز للوصول. يمرر فقط الرمز المميز في عنوان التفويض إلى واجهة برمجة التطبيقات الخلفية.

لطلبات للتخويل المسبق، قم بتكوين نهجvalidate-jwtللتحقق من صحة الرمز المميز للوصول لكل طلب وارد. إذا كان الطلب لا يحتوي على رمز مميز صالح، فإن APIM تحظره.

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

  • في openid-config عنوان URL، aad-tenant هو معرف المستأجر في معرف Microsoft Entra. ابحث عن هذه القيمة في مدخل Microsoft Azure، على سبيل المثال، في صفحة نظرة عامة لمورد Microsoft Entra. يفترض المثال الموضح تطبيق Microsoft Entra أحادي المستأجر ونقطة نهاية تكوين v2.
  • قيمة claim هي معرف العميل للتطبيق الخلفي الذي قمت بتسجيله في معرف Microsoft Entra.
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
    <openid-config url="https://login.microsoftonline.com/{aad-tenant}/v2.0/.well-known/openid-configuration" />
    <audiences>
        <audience>{audience-value - (ex:api://guid)}</audience>
    </audiences>
    <issuers>
        <issuer>{issuer-value - (ex: https://sts.windows.net/{tenant id}/)}</issuer>
    </issuers>
    <required-claims>
        <claim name="aud">
            <value>{backend-app-client-id}</value>
        </claim>
    </required-claims>
</validate-jwt>

إشعار

يصنف عنوان URL openid-config يتوافق مع نقطة نهاية الإصدار 2. بالنسبة لنقطة النهاية v1 openid-config ، استخدم https://login.microsoftonline.com/{aad-tenant}/.well-known/openid-configuration.

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

المحتوى ذو الصلة