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

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

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

يمكنك أيضًا تصميم التفاعل كخطوة تزامن. هذا مناسب عندما تتوقف واجهة برمجة التطبيقات REST عن التحقق من صحة البيانات على الشاشة، والاستمرار في إرجاع المطالبات. للحصول على مزيدٍ من المعلومات، راجع معاينة: دمج مطالبات واجهة برمجة تطبيقات REST في رحلة مستخدم Azure AD B2C الخاص بك كخطوة نحو التزامن.

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

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

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

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

1. سجل الدخول إلى مدخل Azure.

2. من خدمات Azure، حدد Azure AD B2C.

3. حدد API connectors، ثم حدد New API connector.

   

4. توفير الاسم المعروض للاستدعاء. على سبيل المثال، التحقق من صحة معلومات المستخدم.

5. توفير نقطة نهاية معرّف URL لاستدعاء واجهة برمجة التطبيقات للنظام.

6. اختر نوع المصادقة وقم بتكوين معلومات المصادقة لاستدعاء واجهة برمجة التطبيقات الخاصة بك. تعرّف على كيفية تأمين موصل واجهة برمجة التطبيقات.

   

7. حدد حفظ.

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

موصل واجهة برمجة التطبيقات يتحقق كطلب 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": "11111111-0000-0000-0000-000000000000",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "<step-name>",
 "client_id":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

تتوفر خصائص المستخدم والسمات المخصصة المسرودة في Azure AD B2C>سمات المستخدم فقط ليتم إرسالها في الطلب.

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

بالإضافة إلى ذلك، يتم إرسال هذه المطالبات عادًة في كافة طلبات هذه الخطوة:

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

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

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

1. سجل الدخول إلى مدخل Azure.

2. من خدمات Azure، حدد Azure AD B2C.

3. حدد تدفقات المستخدم، ثم حدد تدفق المستخدم الذي تريد إضافة موصل واجهة برمجة التطبيقات إليه.

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

   • بعد الاتحاد مع موفر الهوية أثناء التسجيل
   • قبل إنشاء المستخدم
   • قبل إرسال الرمز المميز (إصدار أولي)

   

5. حدد حفظ.

هذه الخطوات موجودة فقط للتسجيل وتسجيل الدخول (موصى به)والتسجيل (موصى به) ولكن تنطبق فقط على جزء تجربة التسجيل.

بعد الاتحاد مع موفر الهوية أثناء التسجيل

يتم استدعاء موصل API في هذه الخطوة في عملية التسجيل مباشرة بعد مصادقة المستخدم مع موفر هوية (مثل Google وFacebook ومعرف Microsoft Entra). تسبق هذه الخطوة صفحة مجموعة السمات، وهي النموذج المقدم للمستخدم لتجميع سمات المستخدم. لا يتم استدعاء هذه الخطوة إذا كان مستخدم تسجيل باستخدام حساب محلي.

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

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "step": "PostFederationSignup",
 "client_id":"<guid>",
 "ui_locales":"en-US"
}

تعتمد المطالبات الدقيقة المرسلة إلى واجهة برمجة التطبيقات على المعلومات التي يقدمها موفر الهوية. يتم إرسال "البريد الإلكتروني" على الدوام.

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

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

• استجابة المتابعة
• استجابة الحظر

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

تشير متابعة الاستجابة إلى أن تدفق المستخدم يجب أن يستمر إلى الخطوة التالية: صفحة تجميع السمات.

في متابعة الاستجابة، يمكن لواجهة برمجة التطبيقات إرجاع المطالبات. إذا تم إرجاع مطالبة من قبل واجهة برمجة التطبيقات، فإن المطالبة تفعل ما يلي:

• تعبئة حقل الإدخال مسبقًا في صفحة تجميع السمات.

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

استجابة الحظر

ينهي حظر الاستجابة تدفق المستخدم. يمكن إصدارها عن قصد من قبل واجهة برمجة التطبيقات لإيقاف استمرار تدفق المستخدم عن طريق عرض صفحة كتلة للمستخدم. تعرض صفحة الحظر ما userMessage توفره واجهة برمجة التطبيقات.

راجع مثالًا على حظر الاستجابة.

قبل إنشاء المستخدم

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

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

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "PostAttributeCollection",
 "client_id":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

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

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

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

• استجابة المتابعة
• استجابة الحظر
• استجابة التحقق من الصحة

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

تشير استجابة المتابعة إلى أن تدفق المستخدم يجب أن يستمر إلى الخطوة التالية: إنشاء مستخدم في الدليل.

في متابعة الاستجابة، يمكن لواجهة برمجة التطبيقات إرجاع المطالبات. إذا تم إرجاع مطالبة من قبل واجهة برمجة التطبيقات، فإن المطالبة تفعل ما يلي:

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

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

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

استجابة الحظر

ينهي حظر الاستجابة تدفق المستخدم. يمكن إصدارها عن قصد من قبل واجهة برمجة التطبيقات لإيقاف استمرار تدفق المستخدم عن طريق عرض صفحة كتلة للمستخدم. تعرض صفحة الحظر ما userMessage توفره واجهة برمجة التطبيقات.

راجع مثالًا على حظر الاستجابة.

استجابة خطأ التحقق من الصحة

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

راجع مثال استجابة خطأ التحقق من الصحة.

قبل إرسال الرمز المميز (إصدار أولي)

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

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

POST <API-endpoint>
Content-type: application/json

{
 "clientId": "231c70e8-8424-48ac-9b5d-5623b9e4ccf3",
 "step": "PreTokenApplicationClaims",
 "ui_locales":"en-US",
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
}

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

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

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

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

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

تشير استجابة المتابعة إلى أن تدفق المستخدم يجب أن يستمر إلى الخطوة التالية: إصدار الرمز المميز.

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

قيمة المطالبة في الرمز المميز سيتم إرجاعها بواسطة واجهة برمجة التطبيقات، وليس القيمة في الدليل. لا يمكن الكتابة فوق بعض قيم المطالبة بواسطة استجابة واجهة برمجة التطبيقات. تتوافق المطالبات التي يمكن إرجاعها بواسطة واجهة برمجة التطبيقات مع المجموعة الموجودة ضمن سمات المستخدم باستثناء 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
}

راجع مثالًا على استجابة الحظر

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "There was a problem with your request. You are not able to sign up at this time. Please contact your system administrator",
}

تجربة المستخدم النهائي مع استجابة حظر

راجع مثال استجابة خطأ التحقق من الصحة

HTTP/1.1 400 Bad Request
Content-type: application/json

{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Please enter a valid Postal Code."
}

تجربة المستخدم النهائي مع استجابة خطأ التحقق من الصحة

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

لهذه المعاينة، يجب أن يكون لديكواجهة برمجة تطبيقات REST الذي يتحقق من صحة ما إذا كان كائن Azure AD B2C المستخدم مسجل في النظام الخلفي الخاص بك مع معرّف الولاء. إذا تم التسجيل، يجب أن تقوم واجهة برمجة تطبيقات REST بإرجاع التعليمة البرمجية الترويجية للتسجيل، والذي يمكن للعميل استخدامه لشراء السلع داخل تطبيقك. وإلا، يجب أن ترجع واجهة برمجة تطبيقات REST رسالة خطأ HTTP 409: "معرّف الولاء '{loyalty ID}' غير مقترن بعنوان البريد الإلكتروني '{email}'".

توضح التعليمات البرمجية JSON التالية البيانات التي سيرسلها Azure AD B2C إلى نقطة نهاية REST API.

{
    "email": "User email address",
    "language": "Current UI language",
    "loyaltyId": "User loyalty ID"
}

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

{
    "promoCode": "24534"
}

إذا فشل التحقق من الصحة، يجب أن ترجع واجهة برمجة تطبيقات REST بروتوكول HTTP 409 (تعارض) مع userMessageعنصرJSON. تتوقع IEF userMessage مطالبة واجهة برمجة تطبيقات REST بالإرجاع. سيتم تقديم هذه المطالبة كسلسلة للمستخدم في حالة فشل التحقق من الصحة.

{
    "version": "1.0.1",
    "status": 409,
    "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
}

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

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

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

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

<ClaimType Id="loyaltyId">
  <DisplayName>Your loyalty ID</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="promoCode">
  <DisplayName>Your promo code</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Paragraph</UserInputType>
</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 وقم بإضافة موفر مطالبات جديد كما يلي:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-ValidateProfile">
      <DisplayName>Check loyaltyId 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/ValidateProfile?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="loyaltyId" />
        <InputClaim ClaimTypeReferenceId="email" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

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

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

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

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

راجع بيانات التعريف لملف التعريف الفني RESTful لمزيد من التكوينات.

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

التحقق من صحة إدخال المستخدم

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

إضافة مرجع ملف تعريف تقني التحقق من الصحة إلى ملف تعريف تقني للتسجيل، والذي يستدعي REST-ValidateProfile. ستتم إضافة ملف التعريف الفني للتحقق من الصحة الجديد إلى أعلى <ValidationTechnicalProfiles> المجموعة المحددة في النهج الأساسي. يعني هذا السلوك أنه فقط بعد التحقق من صحة ناجحة، ينتقل Azure AD B2C لإنشاء الحساب في الدليل.

1. ابحث عن عنصر ClaimsProviders. أضف ClaimsProvider جديد على النحو التالي:

   <ClaimsProvider>
     <DisplayName>Local Account</DisplayName>
     <TechnicalProfiles>
       <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
         <OutputClaims>
           <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
           <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
           <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
           <OutputClaim ClaimTypeReferenceId="displayName"/>
           <OutputClaim ClaimTypeReferenceId="givenName"/>
           <OutputClaim ClaimTypeReferenceId="surName"/>
           <!-- Required to present the text box to collect the data from the user -->
           <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
           <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
           to subsequent orchestration steps and token issuance-->
           <OutputClaim ClaimTypeReferenceId="promoCode" />
         </OutputClaims>
         <ValidationTechnicalProfiles>
           <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
         </ValidationTechnicalProfiles>
       </TechnicalProfile>
     </TechnicalProfiles>
   </ClaimsProvider>
   <ClaimsProvider>
     <DisplayName>Self Asserted</DisplayName>
     <TechnicalProfiles>
       <TechnicalProfile Id="SelfAsserted-Social">
         <InputClaims>
           <InputClaim ClaimTypeReferenceId="email" />
         </InputClaims>
           <OutputClaims>
           <OutputClaim ClaimTypeReferenceId="email" />
           <OutputClaim ClaimTypeReferenceId="displayName"/>
           <OutputClaim ClaimTypeReferenceId="givenName"/>
           <OutputClaim ClaimTypeReferenceId="surname"/>
           <!-- Required to present the text box to collect the data from the user -->
           <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
           <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
           to subsequent orchestration steps and token issuance-->
           <OutputClaim ClaimTypeReferenceId="promoCode" />
         </OutputClaims>
         <ValidationTechnicalProfiles>
           <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
         </ValidationTechnicalProfiles>
       </TechnicalProfile>
     </TechnicalProfiles>
   </ClaimsProvider>
   

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

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

<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="promoCode" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

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

1. سجل الدخول إلى مدخل Azure.
2. إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر معرف Microsoft Entra من قائمة الدلائل + الاشتراكات.
3. اختر All services في الزاوية العلوية اليسرى من مدخل Azure، ثم ابحث عن App registrations وحددها.
4. حدد إطار عمل تجربة الهوية.
5. حدّد Upload Custom Policy، ثم قم بتحميل ملفات النهج الذي قمت بتغييرها، TrustFrameworkExtensions.xml، وSignUpOrSignin.xml.
6. حدد سياسة الاشتراك أو تسجيل الدخول التي قمت بتحميلها، وانقر فوق زر Run now.
7. يجب أن تكون قادرًا على التسجيل باستخدام عنوان بريد إلكتروني.
8. انقر على الرابط تسجيل الدخول الآن.
9. في معرّف الولاء الخاص بك، اكتب 1234، وانقر فوق Continue. عند هذه النقطة، يجب أن تحصل على رسالة خطأ التحقق من الصحة.
10. تغيير إلى قيمة أخرى ثم انقر فوق Continue.
11. يتضمن الرمز المميز المرسل إلى طلبك المطالبة promoCode.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "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": 1584292103,
  "auth_time": 1584292103,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "promoCode": "84362"
  ...
}

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

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

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

تأكد من:

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

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

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

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

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

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

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

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

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

تأكد من:

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

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

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

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

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

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