إثراء الرموز المميزة بمطالبات من مصادر خارجية باستخدام موصلات API

مقالة
11/08/2023

قبل أن تبدأ استخدم اختر نوع النهجالمحدد لاختيار نوع النهج التي تقوم بإعدادها. يوفر Azure Active Directory B2C طريقتين لتحديد كيفية تفاعل المستخدمين مع تطبيقاتك: من خلال تدفقات محددة مسبقا للمستخدمين أو من خلال سياسات مخصصة قابلة للتكوين بشكل كامل. تختلف الخطوات المطلوبة في هذه المقالة لكل أسلوب.

Azure Active Directory B2C (Azure AD B2C) تمكن مطوري الهوية من دمج تفاعل مع واجهة برمجة تطبيقات RESTful في تدفق المستخدمين باستخدام موصلات APIالخاصة بهم . وهو يمكّن المطورين من استرداد البيانات بشكل حيوي من مصادر الهوية الخارجية. في نهاية هذه المعاينة، ستتمكن من إنشاء تدفق مستخدم Azure AD B2C الذي يتفاعل مع واجهات برمجة التطبيقات لإثراء الرموز المميزة بمعلومات من مصادر خارجية.

يمكنك استخدام موصلات API المطبقة على الخطوة Before sending the token (preview) لإثراء الرموز المميزة للتطبيقات الخاصة بك بمعلومات من مصادر خارجية. عند تسجيل دخول مستخدم أو تسجيل الدخول، سيقوم Azure AD B2C باستدعاء نقطة نهاية API المكونة في موصل API، والتي يمكنها الاستعلام عن معلومات حول مستخدم في خدمات المتلقين للمعلومات مثل الخدمات السحابية ومتاجر المستخدم المخصصة وأنظمة الأذونات المخصصة وأنظمة الهوية القديمة وغيرها.

إشعار

هذه الميزة قيد المعاينة العامة.

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

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

إنشاء تدفق مستخدم لتمكين المستخدمين من تسجيل الدخول إلى تطبيقك.
تسجيل تطبيق ويب.

أكمل الخطوات في ابدأ العمل مع النهج المخصص في خدمات مجال Active Directory B2C
تسجيل تطبيق ويب.

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

إنشاء موصل واجهة برمجة التطبيقات

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

سجل الدخول إلى مدخل Azure.
من خدمات Azure، حدد Azure AD B2C.
حدد API connectors، ثم حدد New API connector.
توفير الاسم المعروض للاستدعاء. على سبيل المثال، إثراء الرمز المميز من مصدر خارجي.
توفير نقطة نهاية معرّف URL لاستدعاء واجهة برمجة التطبيقات للنظام.
اختر نوع المصادقة وقم بتكوين معلومات المصادقة لاستدعاء واجهة برمجة التطبيقات الخاصة بك. تعرّف على كيفية تأمين موصل واجهة برمجة التطبيقات.
حدد حفظ.

تمكين موصل API في تدفق المستخدم

اتبع هذه الخطوات لإضافة موصل واجهة برمجة التطبيقات إلى تسجيل تدفق مستخدم.

سجل الدخول إلى مدخل Azure.
من خدمات Azure، حدد Azure AD B2C.
حدد تدفقات المستخدم، ثم حدد تدفق المستخدم الذي تريد إضافة موصل واجهة برمجة التطبيقات إليه.
حدد موصلات API، ثم حدد نقطة نهاية API التي تريد استدعاءها في الخطوة Before sending the token (preview) في تدفق المستخدم:
حدد حفظ.

هذه الخطوة موجودة فقط من أجل Sign up and sign in (Recommended)، Sign up (Recommended)، و تدفق المستخدم Sign in (Recommended)

طلب مثال تم إرساله إلى API في هذه الخطوة

يتم استدعاء موصل API في هذه الخطوة عندما يكون الرمز المميز على وشك أن يتم إصداره أثناء تسجيل الدخول و عمليات التسجيل. موصل واجهة برمجة التطبيقات يتحقق كطلب HTTP POST ويتم إرسال سمات المستخدم (مطالبات) كأزواج قيم المفاتيح في نص JSON. يتم تسلسل السمات بشكل مشابه لخصائص مستخدم Microsoft Graph.

POST <API-endpoint>
Content-type: application/json
{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "ab3ec3b2-a435-45e4-b93a-56a005e88bb7",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "client_id": "231c70e8-8424-48ac-9b5d-5623b9e4ccf3",
 "step": "PreTokenIssuance",
 "ui_locales":"en-US"
}

تعتمد المطالبات التي يتم إرسالها إلى واجهة برمجة التطبيقات على المعلومات المعرفة للمستخدم. تتوفر خصائص المستخدم والسمات المخصصة المسرودة في Azure AD B2C>سمات المستخدم فقط ليتم إرسالها في الطلب. توجد السمات المخصصة بتنسيق extension_<extensions-app-id>_CustomAttribute في الدليل. يجب أن تتوقع واجهة برمجة التطبيقات تلقي المطالبات بنفس التنسيق المتسلسل. لمزيد من المعلومات حول السمات المخصصة، راجع تعريف السمات المخصصة في Azure AD B2C. بالإضافة إلى ذلك، يتم إرسال هذه المطالبات عادة في كافة طلبات هذه الخطوة:

UI Locales ('ui_locales') - إعدادات المستخدم النهائي المحلية (الإعدادات المحلية) كما تم تكوينها على جهازهم. يمكن استخدام هذا من قبل واجهة برمجة التطبيقات الخاصة بك لإرجاع استجابات دولية.
Step ('step') - الخطوة أو النقطة على تدفق المستخدم الذي تم استدعاء موصل API له. قيمة هذه الخطوة هي '
Client ID ('client_id') - appId قيمة التطبيق الذي يقوم المستخدم النهائي بالمصادقة عليه في تدفق المستخدم. هذا ليس تطبيق المورد appId في الرموز المميزة للوصول.
objectId - معرف المستخدم. يمكنك استخدام هذا من أجل الاستعلام عن خدمات المتلقين للمعلومات حول المستخدم.

هام

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

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

عندما تتلقى واجهة برمجة تطبيقات الويب طلب HTTP من معرف Microsoft Entra أثناء تدفق المستخدم، يمكن أن ترجع "استجابة متابعة".

استجابة المتابعة

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

إشعار

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

مثال على الاستجابة

مثال على استجابة المتابعة

HTTP/1.1 200 OK
Content-type: application/json
{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // return claim
    "extension_<extensions-app-id>_CustomAttribute": "value" // return claim
}

المعلمة	نوع	مطلوبة	الوصف
الإصدار	السلسلة	‏‏نعم‬	إصدار واجهة برمجة التطبيقات الخاصة بك.
إجراء	السلسلة	‏‏نعم‬	يجب أن تكون القيمة `Continue`.
<builtInUserAttribute>	<نوع السمة>	لا	يمكن إرجاعها في الرمز المميز إذا تم تحديدها ك مطالبة تطبيق.
<extension_{extensions-app-id}_CustomAttribute>	<نوع السمة>	لا	المطالبة لا تحتاج إلى احتواء `_<extensions-app-id>_` ، فذلك اختياري. يمكن إرجاعها في الرمز المميز إذا تم تحديدها ك مطالبة تطبيق.

في هذا السيناريو، نحن نقوم بإثراء بيانات الرمز المميز للمستخدم من خلال التكامل مع سير عمل خط عمل الشركة. أثناء التسجيل أو تسجيل الدخول باستخدام حساب محلي أو اتحادي، يقوم Azure AD B2C باستدعاء واجهة برمجة تطبيقات REST للحصول على بيانات ملف تعريف المستخدم الموسعة من مصدر بيانات بعيد. في هذه العينة، يرسل Azure AD B2C معرف المستخدم الفريد، معرف الكائن. ثم يقوم API REST بإرجاع رصيد حساب المستخدم (رقم عشوائي). استخدم هذه العينة كنقطة بداية للتكامل مع نظام CRM الخاص بك أو قاعدة بيانات التسويق أو أي سير عمل لخط العمل. يمكنك أيضا تصميم التفاعل كملف تعريف فني للتحقق من الصحة. هذا مناسب عندما تكون واجهة برمجة التطبيقات REST تقوم بالتحقق من صحة البيانات على الشاشة والمطالبات العائدة. أكمل الخطوات الموجودة في دليل Walkthrough: Add an API connector to a sign-up user flow

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

أكمل الخطوات في اGet started with custom policies. يجب أن يكون لديك سياسة مخصصة للعمل من أجل الاشتراك وتسجيل الدخول في الحسابات المحلية.
تعرف على كيفية دمج عمليات تبادل مطالبات REST API في نهج Azure AD B2C المخصص.

إعداد نقطة نهاية واجهة برمجة تطبيقات REST

لهذه المعاينة، يجب أن يكون لديك REST API الذي يتحقق من صحة ما إذا كان كائن Azure AD B2C المستخدم مسجل في النظام الخلفي الخاص بك. إذا تم تسجيله، يقوم REST API بإرجاع رصيد حساب المستخدم. وإلا، يقوم REST API بإرجاع الحساب الجديد في الدليل وإرجاع رصيد البداية 50.00 . توضح التعليمات البرمجية JSON التالية البيانات التي سيرسلها Azure AD B2C إلى نقطة نهاية REST API.

{
    "objectId": "User objectId",
    "lang": "Current UI language"
}

بمجرد تحققواجهة برمجة تطبيقات REST من صحة البيانات، يجب أن يرجع HTTP 200 (ok)، مع بيانات JSON التالية:

{
    "balance": "760.50"
}

لا مجال للحديث عن الإعداد لنقطة نهاية واجهة برمجة تطبيقات REST في هذه المقالة. لقد أنشأنا عينة Azure Functions. يمكنك الوصول إلى التعليمة البرمجية للدالة Azure الكاملة في GitHub.

تعريف المطالبات

توفر المطالبة تخزينًا مؤقتًا للبيانات أثناء تنفيذ نهج Azure AD B2C. يمكنك التصريح عن المطالبات ضمن قسم مخطط المطالبات.

افتح ملف ملحقات النُهج الخاص بك. على سبيل المثال، SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
ابحث عن عنصر BuildingBlocks . إذا كان العنصر غير موجود، قم بإضافته.
حدد موقع عنصر ClaimsSchema . إذا كان العنصر غير موجود، قم بإضافته.
قم بإضافة المطالبات التالية إلى عنصر ClaimsSchema.

<ClaimType Id="balance">
  <DisplayName>Your Balance</DisplayName>
  <DataType>string</DataType>
</ClaimType>
<ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

قم بإضافة ملف تعريف تقني RESTful API

يوفر الملف التقني restful الدعم للتفاعل مع خدمة RESTful الخاصة بك. يرسل Azure AD B2C البيانات إلى خدمة RESTful في InputClaims مجموعة ويتلقى البيانات مرة أخرى في OutputClaims مجموعة. ابحث عن العنصر ClaimsProviders في الملف TrustFrameworkExtensions.xml وقم بإضافة موفر مطالبات جديد كما يلي:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <!-- Set the ServiceUrl with your own REST API endpoint -->
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
        <Item Key="AuthenticationType">None</Item>
        <!-- REMOVE the following line in production environments -->
        <Item Key="AllowInsecureAuthInProduction">true</Item>
      </Metadata>
      <InputClaims>
        <!-- Claims sent to your REST API -->
        <InputClaim ClaimTypeReferenceId="objectId" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="balance" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

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

تكوين ملف التعريف التقني لواجهة برمجة التطبيقات RESTful

بعد توزيع واجهة برمجة تطبيقات REST، قم بتعيين بيانات التعريف REST-GetProfile الخاصة بملف التعريف الفني لتعكس واجهة برمجة تطبيقات REST الخاصة بك، بما في ذلك:

ServiceUrl. تعيين URL لنقطة نهاية واجهة برمجة تطبيقات REST.
SendClaimsIn. حدد كيفية إرسال مطالبات الإدخال إلى موفر مطالبات RESTful.
نوع المصادقة. تعيين نوع المصادقة التي ينفذها موفر مطالبات RESTful Basic أو ClientCertificate
AllowInsecureAuthInProduction. في بيئة التشغيل، تأكد من تعيين بيانات التعريف هذه إلى false.

راجع بيانات التعريف لملف التعريف الفني RESTful لمزيد من التكوينات. يحدد التعليقان أعلاه AuthenticationTypeو AllowInsecureAuthInProduction التغييرات التي يجب عليك القيام بها عند الانتقال إلى بيئة التشغيل. لمعرفة كيفية تأمين واجهات برمجة التطبيقات RESTful للإنتاج، راجع تأمين واجهة برمجة التطبيقات الخاصة بك RESTful.

إضافة خطوة تزامن

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

افتح الملف الأساسي للسياسة. على سبيل المثال، SocialAndLocalAccounts/TrustFrameworkBase.xml.
البحث عن العنصر <UserJourneys>. انسخ العنصر بأكمله، ثم احذفه.
افتح ملف ملحقات النُهج الخاص بك. على سبيل المثال، SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
الصق <UserJourneys> في ملف الملحقات، بعد إغلاق العنصر<ClaimsProviders>.

حدد موقع <UserJourney Id="SignUpOrSignIn"> ، ثم قم بإضافة الخطوة التزامن التالية قبل الخطوة الأخيرة.

<OrchestrationStep Order="7" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="RESTGetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
  </ClaimsExchanges>
</OrchestrationStep>

قم بإعادة بناء التزامن الخطوة الأخيرة عن طريق تغيير Order إلى 8 . يجب أن تبدو خطوتا التنسيق النهائيتان كما يلي:

<OrchestrationStep Order="7" Type="ClaimsExchange">
  <ClaimsExchanges>
    <ClaimsExchange Id="RESTGetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
  </ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />

كرر الخطوتين الأخيرتين لمرحلتي المستخدم ProfileEdit و PasswordReset.

تضمين مطالبة في الرمز المميز

لإعادة المطالبة balance مرة أخرى إلى طلب جهة الاعتمد، أضف مطالبة إخراج إلى الملف SocialAndLocalAccounts/SignUpOrSignIn.xml. إضافة مطالبة إخراج ستؤدي إلى إصدار المطالبة في الرمز المميز بعد رحلة مستخدم ناجحة، وسيتم إرسالها إلى التطبيق. تعديل عنصر ملف التعريف التقني داخل قسم جهة الاعتماد لإضافة balance كمطالبة إخراج.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      <OutputClaim ClaimTypeReferenceId="balance" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

كرر هذه الخطوة ProfileEdit.xmlورحلات المستخدم PasswordReset.xml. احفظ الملفات التي قمت بتغييرها: TrustFrameworkBase.xmlو TrustFrameworkExtensions.xml SignUpOrSignin.xmlو ProfileEdit.xmlو PasswordReset.xml.

اختبار النهج المخصص

سجل الدخول إلى مدخل Azure.
إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
اختر All services في الزاوية العلوية اليسرى من مدخل Azure، ثم ابحث عن App registrations وحددها.
حدد إطار عمل تجربة الهوية.
حدد Upload "نهج مخصص"،ثم قم بتحميل ملفات النهج التي قمت بتغييرها: TrustFrameworkBase.xmlو TrustFrameworkExtensions.xmlوSignUpOrSignin.xmlو ProfileEdit.xmlو PasswordReset.xml.
حدد سياسة الاشتراك أو تسجيل الدخول التي قمت بتحميلها، وانقر فوق زر Run now.
يجب أن تكون قادرا على التسجيل باستخدام عنوان بريد إلكتروني أو حساب على فيسبوك.
يتضمن الرمز المميز المرسل إلى طلبك المطالبة balance.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584961516,
  "nbf": 1584957916,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
  "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584957916,
  "auth_time": 1584957916,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "balance": "202.75"
  ...
}

أفضل الممارسات وكيفية استكشاف الأخطاء وإصلاحها

استخدام الوظائف السحابية بلا خادم

توفر الوظائف بلا خادم، مثل مشغلات HTTP في Azure Functions،طريقة لإنشاء نقاط نهاية واجهة برمجة التطبيقات لاستخدامها مع موصل واجهة برمجة التطبيقات. يمكن للوظيفة السحابية بلا خادم أيضًا استدعاء واجهات برمجة التطبيقات الأخرى على الويب ومتاجر البيانات والخدمات السحابية الأخرى واستدعاءها للسيناريوهات المعقدة.

أفضل الممارسات

تأكد من:

تتبع واجهة برمجة التطبيقات خاصتك طلبات واجهة برمجة التطبيقات واتفاق الاستجابة كما هو موضح أعلاه.
يشير Endpoint URL لموصل واجهة برمجة التطبيقات إلى نقطة نهاية واجهة برمجة التطبيقات الصحيحة.
يتحقق واجهة برمجة التطبيقات الخاص بك بشكل صريح من القيم الخالية من المطالبات المتلقاة التي يعتمد عليها.
تطبيق API أسلوب مصادقة الموضحة في تأمين موصل API الخاص بك.
تستجيب واجهة برمجة التطبيقات في أسرع وقت ممكن لضمان تجربة مستخدم مرنة.
- سوف ينتظر Azure AD B2C لمدة أقصاها 20 ثانية لتلقي استجابة. إذا لم يتم تلقي أي منها، فسيحاول مرة أخرى (إعادة المحاولة) معاودة الاتصال بواجهة برمجة التطبيقات.
- إذا كنت تستخدم وظيفة بدون خادم أو خدمة ويب قابلة للتطوير ، فاستخدم خطة استضافة تحافظ على واجهة برمجة التطبيقات "مستيقظة" أو "دافئة" في الإنتاج. بالنسبة إلى Azure Functions، يوصى باستخدام خطة Premium في الإنتاج كحد أدنى.
تأكد من وجود قابلية وصول عالية لواجهة برمجة التطبيقات الخاصة بك.
قم بمراقبة الأداء وتحسين واجهات برمجة التطبيقات في المصب أو قواعد البيانات أو تبعيات أخرى لواجهة برمجة التطبيقات.

هام

يجب أن تتوافق نقاط النهاية الخاصة بك مع متطلبات أمان Microsoft Azure AD B2C. أُوقِف العمل بإصدارات وأصفار TLS الأقدم. لمزيد من المعلومات، راجع متطلبات مجموعة TLS والتشفير.

استخدام التسجيل

استخدام الوظائف السحابية بلا خادم

استخدام التسجيل

بشكل عام، من المفيد استخدام أدوات التسجيل التي تتيحها خدمة واجهة برمجة تطبيقات الويب، مثل Application insightsلمراقبة واجهة برمجة التطبيقات بحثًا عن رموز الأخطاء غير المتوقعة والاستثناءات والأداء الضعيف.

مراقبة رموز حالة HTTP التي ليست HTTP 200 أو 400.
يشير رمز حالة HTTP 401 أو 403 عادةً إلى وجود مشكلة في المصادقة. تحقق من طبقة المصادقة الخاصة بواجهة برمجة التطبيقات والتكوين المطابق في موصل واجهة برمجة التطبيقات.
استخدام مستويات أكثر قوة من التسجيل (على سبيل المثال "trace" أو "debug") في التطوير إذا لزم الأمر.
راقب واجهة برمجة التطبيقات الخاصة بك لاستجابة طويلة المدى. بالإضافة إلى ذلك، يقوم Azure AD B2C بتسجيل بيانات التعريف حول المعاملات واجهة برمجة التطبيقات التي تحدث أثناء مصادقة المستخدم عبر تدفق مستخدم. للعثور على هذه:

انتقل إلى Azure AD B2C
ضمن Activities، حدد Audit logs.
تصفية طريقة عرض القائمة: بالنسبة للتاريخ، حدد الفترة الزمنية التي تريدها، وبالنسبة للنشاط، حدد تم استدعاء واجهة برمجة التطبيقات كجزء من تدفق المستخدم.
افحص السجلات الفردية. يمثل كل صف موصل واجهة برمجة التطبيقات يحاول أن يتم استدعاؤه أثناء تدفق مستخدم. إذا فشل استدعاء واجهة برمجة التطبيقات للنظام ثم حدثت إعادة محاولة، فإنه لا يزال يمثل كسجل واحد. يشير numberOfAttempts إلى عدد المرات التي تم فيها استدعاء واجهة برمجة التطبيقات. يمكن أن تكون هذه القيمة 1 أو 2. توجد معلومات أخرى مفصلة حول استدعاء واجهة برمجة التطبيقات للنظام في السجلات.

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

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

لمعرفة كيفية تأمين واجهات برمجة التطبيقات، راجع المقالات التالية:

للحصول على مزيدٍ من المعلومات، راجع معاينة: دمج مطالبات واجهة برمجة تطبيقات REST في رحلة مستخدم Azure AD B2C الخاص بك كخطوة نحو التزامن
Secure your RESTful API
Reference: RESTful technical profile

مشاركة عبر

إثراء الرموز المميزة بمطالبات من مصادر خارجية باستخدام موصلات API

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

إنشاء موصل واجهة برمجة التطبيقات

تمكين موصل API في تدفق المستخدم

طلب مثال تم إرساله إلى API في هذه الخطوة

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

استجابة المتابعة

مثال على الاستجابة

مثال على استجابة المتابعة

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

إعداد نقطة نهاية واجهة برمجة تطبيقات REST

تعريف المطالبات

قم بإضافة ملف تعريف تقني RESTful API

تكوين ملف التعريف التقني لواجهة برمجة التطبيقات RESTful

إضافة خطوة تزامن

تضمين مطالبة في الرمز المميز

اختبار النهج المخصص

أفضل الممارسات وكيفية استكشاف الأخطاء وإصلاحها

استخدام الوظائف السحابية بلا خادم

أفضل الممارسات

استخدام التسجيل

استخدام الوظائف السحابية بلا خادم

استخدام التسجيل

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

الملاحظات

الموارد الإضافية