تكوين الرموز المميزة في Microsoft Azure Active Directory B2C

مقالة
11/20/2023

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

في هذه المقالة، ستتعلم كيفية تكوين مدة بقاء وتوافق رمز مميز في Azure Active Directory B2C (Azure AD B2C).

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

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

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

سلوك مدة بقاء الرمز المميز

يمكنك تكوين مدة بقاء الرمز المميز، بما في ذلك:

مدة بقاء رمز الوصول والتعريف المميز (بالدقائق) - مدة بقاء الرمز المميز لحامل OAuth 2.0 ورموز المعرف المميزة. الافتراضي هو 60 (1 ساعة). الحد الأدنى (شامل) 5 دقائق. يكون الحد الأقصى (شامل) 1,440 دقيقة (24 ساعة)
مدة بقاء رمز التحديث المميز (بالأيام) - الحد الأقصى للفترة الزمنية التي يمكن قبلها استخدام رمز التحديث المميز للحصول على رمز وصول جديد، إذا تم منح التطبيق الخاص بك نطاق offline_access. الافتراضي 14 يوماً. يكون الحد الأدنى (شامل) يومًا واحدًا. يكون الحد الأقصى (شامل) 90 يومًا.
مدة بقاء نافذة رمز التحديث المميز المنزلقة - نوع نافذة مدة بقاء رمز التحديث المميز. Boundedيشير إلى أنه يمكن توسيع رمز التحديث المميز كما هو واضح في مدة البقاء (بالأيام). No expiry يشير إلى أن مدة بقاء النافذة المنزلقة للرمز المميز للتحديث لن تنتهي صلاحيتها.
طول مدة البقاء (بالأيام) -بعد انقضاء هذه الفترة الزمنية، يضطر المستخدم إلى إعادة المصادقة، بغض النظر عن فترة صلاحية أحدث رمز تحديث مميز حصل عليه التطبيق. يجب أن تكون القيمة أكبر من أو تساوي مدة بقاء رمز التحديث المميز.

يظهر الرسم التخطيطي التالي سلوك مدة بقاء النافذة المنزلقة لرمز التحديث المميز.

Refresh token lifetime

إشعار

التطبيقات ذات الصفحة الواحدة التي تستخدم تدفق رمز التفويض مع PKCE يكون لها دائمًا مدة بقاء رمز تحديث يبلغ 24 ساعة في حين أن تطبيقات الجوال وتطبيقات سطح المكتب وتطبيقات الويب لا تواجه هذا القيد. تعرف على المزيد بشأن الآثار الأمنية لرموز التحديث المميزة في متصفح الويب.

تكوين مدة بقاء الرمز المميز

لتكوين مدة بقاء رمز تدفق المستخدم المميز الخاص بك:

سجل الدخول إلى مدخل Azure.
إذا كان لديك حق الوصول إلى عدة مستأجرين، فحدد رمز الإعدادات في القائمة العلوية للتبديل إلى مستأجر Azure AD B2C من قائمة Directories + subscriptions.
اختر كل الخدمات في الزاوية العلويةِ اليسرى من مدخل Microsoft Azure، ثم ابحث عن Azure AD B2Cوحدده.
حدد تدفق المستخدم (النُهج).
افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
حدد الخصائص.
ضمن مدة بقاء الرمز المميز، قم بضبط الخصائص لتناسب احتياجات التطبيق الخاص بك.
حدد حفظ.

configure user flows tokens in Azure portal.

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

<ClaimsProviders>
  <ClaimsProvider>
    <DisplayName>Token Issuer</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="JwtIssuer">
        <Metadata>
          <Item Key="token_lifetime_secs">3600</Item>
          <Item Key="id_token_lifetime_secs">3600</Item>
          <Item Key="refresh_token_lifetime_secs">1209600</Item>
          <Item Key="rolling_refresh_token_lifetime_secs">7776000</Item>
          <!--<Item Key="allow_infinite_rolling_refresh_token">true</Item>-->
          <Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
          <Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
        </Metadata>
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
</ClaimsProviders>

يتم تعيين القيم التالية في المثال السابق:

مدة بقاء الرمز المميز للوصول بالثواني - مدة بقاء الرمز المميز للوصول (بالثواني). الافتراضي هو 3,600 (1 ساعة). الحد الأدنى هو 300 دقائق (5 دقائق). الحد الأقصى هو 86,400 (24 ساعة).
مدة بقاء الرمز المميز للوصول بالثواني - مدة بقاء الرمز المميز للمعرف (بالثواني). الافتراضي هو 3,600 (1 ساعة). الحد الأدنى هو 300 دقائق (5 دقائق). الحد الأقصى هو 86,400 (24 ساعة).
token_lifetime_secs - مدة بقاء رمز التحديث المميز (بالثواني). الافتراضي هو 1,209,600 (14 يوما). الحد الأدنى هو 86,400 (24 ساعة). الحد الأقصى هو 7,776,000 (90 يومًا).
rolling_refresh_token_lifetime_secs - مدة بقاء نافذة رمز التحديث المميز المنزلقة (بالثواني). يكون الافتراضي 7,776,000 (90 يومًا). الحد الأدنى هو 86,400 (24 ساعة). الحد الأقصى هو 31,536,000 (365 يومًا). إذا كنت تريد عدم فرض مدة بقاء النافذة المنزلقة، قم بتعيين قيمة allow_infinite_rolling_refresh_token إلى true.
allow_infinite_rolling_refresh_token - مدة بقاء نافذة رمز التحديث المميز المنزلقة لا تنتهي أبدًا.

إعدادات التوافق مع الرمز المميز

يمكنك تكوين توافق الرمز المميز، بما في ذلك:

مطالبة المصدر (iss) - تنسيق مصدر الرمز المميز للوصول والمعرف.
مطالبة موضوع (sub) - هو المبدأ الذي يؤكد الرمز المميز معلوماته، مثل مستخدم التطبيق. هذه القيمة غير قابلة للتغيير، ولا يمكن إعادة تعيينها أو إعادة استخدامها. من الممكن استخدامه لإجراء فحوصات التخويل بأمان، على سبيل المثال عند استخدام رمز الوصول المميز للمورد. بشكل افتراضي، يتم ملء مطالبة الموضوع بمعرف الكائن للمستخدم في الدليل.
مطالبة تمثل تدفق المستخدم - تعرف هذه المطالبة تدفق المستخدم الذي تم تنفيذه. القيم المحتملة: tfp(افتراضي)، أو acr.

لتكوين إعدادات توافق تدفق المستخدم:

حدد تدفق المستخدم (النُهج).
افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
حدد الخصائص.
ضمن إعدادات توافق الرمز المميز، قم بضبط الخصائص لتناسب احتياجات التطبيق الخاص بك.
حدد حفظ.

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

<ClaimsProviders>
  <ClaimsProvider>
    <DisplayName>Token Issuer</DisplayName>
    <TechnicalProfiles>
      <TechnicalProfile Id="JwtIssuer">
        <Metadata>
          ...
          <Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
          <Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
        </Metadata>
      </TechnicalProfile>
    </TechnicalProfiles>
  </ClaimsProvider>
</ClaimsProviders>

مطالبة المصدر (iss) - يتم تعيين مطالبة المصدر (iss) مع عنصر بيانات التعريف IssuanceClaimPattern. القيم المقبولة هي AuthorityAndTenantGuid وAuthorityWithTfp.
تعيين المطالبة التي تمثل معرف النهج - الخيارات لإعداد هذه القيمة هي TFP (نهج إطار الثقة) وACR (مرجع سياق المصادقة). القيمة الموصى بها هي TFP. تعيين AuthenticationContextReferenceClaimPattern مع قيمة None.

في عنصر ClaimsSchema، أضف هذا العنصر:
```
<ClaimType Id="trustFrameworkPolicy">
  <DisplayName>Trust framework policy name</DisplayName>
  <DataType>string</DataType>
</ClaimType>
```
في سياسة جهة الاعتماد، ضمن العنصر OutputClaims، أضف مطالبة الإخراج التالية:
```
<OutputClaim ClaimTypeReferenceId="trustFrameworkPolicy" Required="true" DefaultValue="{policy}" PartnerClaimType="tfp" />
```
بالنسبة لـACR، احذف عنصر AuthenticationContextReferenceClaimPattern.
مطالبة الموضوع (sub) - هذا الخيار افتراضي ObjectID، إذا كنت ترغب في تبديل هذا الإعداد إلى Not Supported، استبدل هذا السطر:
```
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub" />
```
بهذا السطر:
```
<OutputClaim ClaimTypeReferenceId="sub" />
```

تقديم مطالبات اختيارية للتطبيق

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

حدد تدفق المستخدم (النُهج).
افتح تدفق المستخدم الذي قمت بإنشائه سابقاً.
اختر مطالبات التطبيق.
اختر المطالبات والسمات التي تريد إرسالها مرة أخرى إلى تطبيقك.
حدد حفظ.

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

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

يضيف المثال التالي المطالبة accountBalance. يتم إرسال accountBalance إلى الطلب كرصيد.

<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}" />
      <!--Add the optional claims here-->
      <OutputClaim ClaimTypeReferenceId="accountBalance" DefaultValue="" PartnerClaimType="balance" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

يحتوي عنصر OutputClaim على السمات التالية:

ClaimTypeReferenceId - معرف نوع المطالبة المحدد مسبقًا في قسم ClaimsSchema في ملف النهج أو ملف النهج الأصل.
PartnerClaimType - يسمح لك بتغيير اسم المطالبة في الرمز المميز.
DefaultValue - قيمة افتراضية. يمكنك أيضًا تعيين القيمة الافتراضية إلى محلل مطالبة، مثل معرف المستأجر.
AlwaysUseDefaultValue - فرض استخدام القيمة الافتراضية.

مدة صلاحية رمز التفويض

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

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

تعرف على المزيد بشأنطلبات رموز الوصول المميزة.
تعرف على كيفية بناء المرونة من خلال أفضل ممارسات المطور.