مشاركة عبر


اتصالات OAuth 2.0 في مدير بيانات الاعتماد - تفاصيل العملية وتدفقاتها

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

توفر هذه المقالة تفاصيل حول تدفقات العملية لإدارة اتصالات OAuth 2.0 باستخدام مدير بيانات الاعتماد في Azure API Management. تنقسم تدفقات العملية إلى جزأين: الإدارةووقت التشغيل.

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

إدارة الاتصالات

يعتني جزء الإدارة من الاتصالات في مدير بيانات الاعتماد بإعداد موفر بيانات اعتماد وتكوينه لرموز OAuth 2.0 المميزة، وتمكين تدفق الموافقة للموفر وإعداد اتصال واحد أو أكثر بموفر بيانات الاعتماد للوصول إلى بيانات الاعتماد.

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

رسم تخطيطي يوضح سير العملية لإنشاء بيانات الاعتماد.

درج وصف
1 يرسل العميل طلبا لإنشاء موفر بيانات الاعتماد.
2 يتم إنشاء موفر بيانات الاعتماد وإرسال استجابة مرة أخرى.
3 يرسل العميل طلبا لإنشاء اتصال.
4 يتم إنشاء الاتصال وإرسال استجابة مرة أخرى مع المعلومات التي تفيد بأن الاتصال غير "متصل".
5 يرسل العميل طلبا لاسترداد عنوان URL لتسجيل الدخول لبدء موافقة OAuth 2.0 لدى موفر بيانات الاعتماد. يتضمن الطلب عنوان URL لإعادة التوجيه بعد استخدامه في الخطوة الأخيرة.
6 يتم إرجاع الاستجابة مع عنوان URL لتسجيل الدخول الذي يجب استخدامه لبدء تدفق الموافقة.
7 يفتح العميل متصفحا يحتوي على عنوان URL لتسجيل الدخول الذي تم توفيره في الخطوة السابقة. تتم إعادة توجيه المتصفح إلى تدفق موافقة OAuth 2.0 لموفر بيانات الاعتماد.
8 بعد الموافقة على الموافقة، تتم إعادة توجيه المتصفح باستخدام رمز تفويض إلى عنوان URL لإعادة التوجيه الذي تم تكوينه لدى موفر بيانات الاعتماد.
9 تستخدم إدارة واجهة برمجة التطبيقات رمز التخويل لجلب الوصول إلى الرموز المميزة وتحديثها.
10 تتلقى إدارة واجهة برمجة التطبيقات الرموز المميزة وتشفيرها.
11 تعيد إدارة واجهة برمجة التطبيقات التوجيه إلى عنوان URL المقدم من الخطوة 5.

مزود بيانات الاعتماد

عند ضبط موفر بيانات الاعتماد الخاص بك، يمكنك الاختيار بين موفري OAuth المختلفين وأنواع المنح (رمز التفويض أو بيانات اعتماد العميل). يتطلب كل مزود تكوينات محددة. أشياء مهمة يجب وضعها في الاعتبار:

  • يمكن أن يحتوي تكوين موفر بيانات الاعتماد على نوع منح واحد فقط.
  • يمكن أن يحتوي تكوين موفر بيانات الاعتماد الواحد على اتصالات متعددة.

إشعار

باستخدام موفر OAuth 2.0 العام، يمكن استخدام موفري الهوية الآخرين الذين يدعمون معايير تدفق OAuth 2.0 .

عند تكوين موفر بيانات الاعتماد، ينشئ مدير بيانات الاعتماد مخزن بيانات اعتماد خلف الكواليس يستخدم لتخزين الرموز المميزة للوصول إلى OAuth 2.0 الخاصة بالموفر مؤقتا وتحديث الرموز المميزة.

الاتصال بموفر بيانات الاعتماد

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

تختلف عملية تكوين اتصال بناء على المنحة التي تم تكوينها وهي خاصة بتكوين موفر بيانات الاعتماد. على سبيل المثال، إذا كنت ترغب في تكوين معرف Microsoft Entra لاستخدام كلا النوعين من المنح، فأنت بحاجة إلى تكوينين لموفر بيانات الاعتماد. يلخص الجدول التالي نوعي المنح.

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

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

نهج الوصول

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

Identity وصف فوائد الاعتبارات
كيان الخدمة الهوية التي يمكن استخدام رموزها المميزة للمصادقة ومنح الوصول إلى موارد Azure محددة عندما تستخدم المؤسسة معرف Microsoft Entra. باستخدام كيان خدمة، تتجنب المؤسسات إنشاء مستخدمين وهميين لإدارة المصادقة عندما يحتاجون إلى الوصول إلى مورد. كيان الخدمة هو هوية Microsoft Entra التي تمثل تطبيق Microsoft Entra مسجل. يسمح بالوصول ذو النطاق الأكثر إحكاما إلى سيناريوهات الاتصال وتفويض المستخدم. غير مرتبط بمثيل إدارة واجهة برمجة تطبيقات معين. يعتمد على معرف Microsoft Entra لفرض الأذونات. يتطلب الحصول على سياق التخويل رمزا مميزا لمعرف Microsoft Entra.
الهوية المدارة <Your API Management instance name> يتوافق هذا الخيار مع هوية مدارة مرتبطة بمثيل إدارة واجهة برمجة التطبيقات. بشكل افتراضي، يتم توفير الوصول إلى الهوية المدارة المعينة من قبل النظام لمثيل إدارة واجهة برمجة التطبيقات المقابل. ترتبط الهوية بمثيل إدارة واجهة برمجة التطبيقات. يمكن لأي شخص لديه حق وصول المساهم إلى مثيل إدارة واجهة برمجة التطبيقات الوصول إلى أي اتصال يمنح أذونات الهوية المدارة.
المستخدمون أو المجموعات المستخدمون أو المجموعات في مستأجر معرف Microsoft Entra. يسمح لك بتقييد الوصول إلى مستخدمين أو مجموعات معينة من المستخدمين. يتطلب أن يكون لدى المستخدمين حساب معرف Microsoft Entra.

وقت تشغيل الاتصالات

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

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

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

رسم تخطيطي يوضح تدفق العملية لاسترداد الرمز المميز في وقت التشغيل.

درج وصف
1 يرسل العميل طلبا إلى مثيل إدارة واجهة برمجة التطبيقات.
2 يتحقق نهج الحصول على التفويض مما إذا كان الرمز المميز للوصول صالحا للاتصال الحالي.
3 إذا انتهت صلاحية الرمز المميز للوصول ولكن الرمز المميز للتحديث صالح، تحاول إدارة واجهة برمجة التطبيقات جلب وصول جديد وتحديث الرموز المميزة من موفر بيانات الاعتماد الذي تم تكوينه.
4 يعرض موفر بيانات الاعتماد كلا من رمز الوصول المميز والرمز المميز للتحديث ، والتي يتم تشفيرها وحفظها في إدارة واجهة برمجة التطبيقات.
5 بعد استرداد الرموز المميزة، يتم إرفاق الرمز المميز للوصول باستخدام النهج set-header كرأس تخويل للطلب الصادر إلى واجهة برمجة تطبيقات الواجهة الخلفية.
6 يتم إرجاع الاستجابة إلى إدارة واجهة برمجة التطبيقات.
7 يتم إرجاع الاستجابة إلى العميل.