نظرة عامة على الرموز المميزة في Microsoft Azure Active Directory B2C

مقالة
04/24/2023

يُظهر Azure Active Directory B2C (Azure AD B2C) أنواعًا مختلفة من رموز الأمان المميزة أثناء معالجة كل تدفق للمصادقة. تصف هذه المقالة التنسيق وخصائص الأمان ومحتويات كل نوع من الرمز المميز.

الأنواع الخاصة بالرمز المميز

يدعم Microsoft Azure Active Directory B2Cبروتوكولات التعيين OAuth 2.0 وOpenID، والتي تستخدم الرموز المميزة للمصادقة والوصول الآمن للموارد. جميع الرموز المميزة المستخدمة في Microsoft Azure Active Directory B2C هيرموز الويب المميزة JSON (JWTs)المحتوية على تأكيدات معلومات بشأن الرمز المميز للمالك وموضوعه.

تُستخدم الرموز المميزة التالية في الاتصال مع Microsoft Azure Active Directory B2C:

الرمز المميز للتعريف- A JWT الذي يحتوي على المطالبات التي يمكنك استخدامها لتحديد المستخدمين في التطبيق الخاص بك. يُرسل هذا الرمز المميز بشكل آمن في طلبات HTTP للاتصال بين مكونين لنفس التطبيق أو الخدمة. يمكنك استخدام المطالبات في الرمز المميز للمعرف كما تراه ملائمًا. وعادةً ما يُستخدمون لعرض معلومات الحساب أو لاتخاذ قرارات التحكم بالوصول في التطبيق. يتم توقيع الرموز المميزة للمعرف الصادرة عن Azure AD B2C، ولكنها غير مشفرة. عندما يتلقى التطبيق أو API الرمز المميز للمعرف، فيجب التحقق من صحة التوقيع لإثبات أن الرمز المميز أصلي. يجب أن يتحقق التطبيق أو API أيضًا من صحة بعض المطالبات في الرمز المميز لإثبات أنه صالح. اعتمادًا على متطلبات السيناريو، من الممكن أن تختلف المطالبات التي تم التحقق من صحتها من قِبل التطبيق، ولكن يجب أن يقوم التطبيق الخاص بك بتنفيذ بعض عمليات التحقق من صحة المطالبة الشائعة في كل سيناريو.
رمز الوصول - JWT الذي يحتوي على مطالبات يمكنك استخدامها لتحديد الأذونات الممنوحة لواجهات برمجة التطبيقات الخاصة بك. تم تسجيل رموز الوصول المميزة، ولكنها غير مشفرة. تُستخدم رموز الوصول المميزة لتوفير الوصول إلى APIs وخوادم الموارد. عندما تتلقى API رمز وصول مميز، يجب التحقق من صحة التوقيع لإثبات أن الرمز المميز أصلي. يجب أيضًا تحقق API من صحة بعض المطالبات في الرمز المميز لإثبات أنه صالح. اعتمادًا على متطلبات السيناريو، من الممكن أن تختلف المطالبات التي تم التحقق من صحتها من قِبل التطبيق، ولكن يجب أن يقوم التطبيق الخاص بك بتنفيذ بعض عمليات التحقق من صحة المطالبة الشائعة في كل سيناريو.
تحديث الرمز المميز- يُستخدم تحديث الرموز المميزة للحصول على رموز معرف مميزة جديدة ورموز الوصول المميزة في تدفق OAuth 2.0. وإنها توفر لتطبيقك وصولًا طويل الأمد إلى الموارد بالنيابة عن المستخدمين دون الحاجة إلى التفاعل مع هؤلاء المستخدمين. رموز التحديث المبهمة لتطبيقك. يتم إصدارها من قِبل Azure AD B2C ويمكن فحصها وتفسيرها فقط من قِبل Azure AD B2C. وإنها طويلة الأمد، ولكن لا ينبغي كتابة طلبك مع توقع استمرار الرمز المميز للتحديث لفترة زمنية محددة. يمكن إبطال رموز التحديث المميزة في أي لحظة لأسباب مختلفة. الطريقة الوحيدة لتطبيقك من أجل معرفة ما إذا كان رمز التحديث المميز صالحًا أم لا هو محاولة استرداده من خلال تقديم طلب الرمز المميز إلى Microsoft Azure Active Directory B2C. عندما تقوم بقبول رمز تحديث مميز لرمز مميز جديد، تتلقى رمز تحديث مميز جديد في استجابة الرمز المميز. حفظ الرمز التحديث المميز الجديد. يتم استبدال الرمز المميز للتحديث الذي استخدمته مسبقًا في الطلب. يساعد هذا الإجراء على ضمان بقاء الرموز المميزة للتحديث صالحة لأطول فترة ممكنة. التطبيقات ذات الصفحة المفردة التي تستخدم تدفق رمز التخويل المميز مع PKCE دائمًا لها عمر رمز مميز للتحديث لمدة 24 ساعة. تعرف على المزيد بشأن الآثار الأمنية لرموز التحديث المميزة في مستعرض الويب.

نقاط النهاية

يتلقىالتطبيق المسجلالرموز المميزة ويتواصل مع Microsoft Azure Active Directory B2C من خلال إرسال الطلبات إلى نقاط النهاية هذه:

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

من الممكن أن تأتي رموز الأمان المميزة التي يتلقاها تطبيقك من Microsoft Azure Active Directory B2C من نقاط النهاية/authorizeأو/token. عندما يتم الحصول على رموز المعرّف المميزة من:

/authorizeنقطة النهاية، ويتم ذلك باستخدامالتدفق الضمني، والذي يتم استخدامه في كثير من الأحيان للمستخدمين لتسجيل الدخول إلى تطبيقات الويب المسندة إلى JavaScript. ومع ذلك، إذا كان تطبيقك يستخدم MSAL.js 2.0 أو أحدث، فلا تقم بتمكين منحة التدفق الضمني في تسجيل تطبيقك لأن MSAL.js 2.0+ يدعم تدفق التعليمات البرمجية للتخويل باستخدام PKCE.
/tokenنقطة النهاية، ويتم ذلك باستخدامتدفق رمز التخويل،الذي يُبقي الرمز المميز مخفي من مستعرض الويب.

المطالبات

عند استخدام Microsoft Azure Active Directory B2C، يكون لديك تحكم تفصيلي في محتوى الرموز المميزة. من الممكن تكوينتدفقات المستخدمينوالنهج المخصصةلإرسال مجموعات معينة من بيانات المستخدم في المطالبات المطلوبة للتطبيق الخاص بك. من الممكن أن تتضمن هذه المطالبات خصائص قياسية مثلdisplayNameوemailAddress. يمكن للتطبيقات أن تستخدم هذه المطالبات للمصادقة الآمنة للمستخدمين والطلبات.

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

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

الاسم	المطالبة	قيمة المثال	الوصف
الجمهور	`aud`	`90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6`	تحديد المستلم المقصود للرمز المميز. بالنسبة لـMicrosoft Azure Active Directory B2C، يكون الجمهور هو معرف التطبيق. يجب أن يتحقق التطبيق الخاص بك من صحة هذه القيمة ويرفض الرمز المميز إذا لم يكن متطابقًا. يكون الجمهور مرادفًا للمورد.
مُصدر الشهادة	`iss`	`https://<tenant-name>.b2clogin.com/775527ff-9a37-4307-8b3d-cc311f58d925/v2.0/`	تحديد خدمة الرمز المميز للأمان (STS) التي تُنشئ الرمز المميز وتُعيده. كما أنه يقوم بتعريف الدليل الذي تمت مصادقة المستخدم فيه. يجب أن يقوم تطبيقك بالتحقق من صحة مطالبة المُصدِّر للتأكد من أن الرمز المميز جاء من نقطة النهاية المناسبة.
تم إصداره في	`iat`	`1438535543`	يتم تمثيل الوقت الذي تم فيه إصدار الرمز المميز في وقت epoch.
موعد انتهاء الصلاحية	`exp`	`1438539443`	الوقت الذي يصبح فيه الرمز المميز غير صالح، ويتم تمثيله في وقت epoch. يجب أن يقوم تطبيقك باستخدام هذه المطالبة للتحقق من صلاحية عمر الرمز المميز.
وليس قبل	`nbf`	`1438535543`	الوقت الذي يصبح فيه الرمز المميز صالحاً، ويتم تمثيله في وقت الحقبة. هذه المرة عادةً ما يكون نفس الوقت الذي تم إصدار الرمز المميز فيه. يجب أن يقوم تطبيقك باستخدام هذه المطالبة للتحقق من صلاحية عمر الرمز المميز.
إصدار	`ver`	`1.0`	إصدار الرمز المميز للمعرف، كما هو محدد من قِبل Microsoft Azure Active Directory B2C.
شفرة التجزئة للتعليمات البرمجية	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	شفرة التجزئة للتعليمات البرمجية المضمنة في الرمز المميز للمعرف فقط عند إصدار الرمز المميز مع رمز تخويل المميز OAuth 2.0. يمكن استخدام شفرة التجزئة للتعليمات البرمجية للتحقق من صحة رمز التخويل المميز. للحصول على مزيد من المعلومات بشأن كيفية إجراء هذا التحقق، انظرمواصفات OpenID Connect.
شفرة التجزئة للرمز المميز للوصول	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	شفرة التجزئة للرمز المميز للوصول مضمنة في الرمز المميز للمعرف فقط عند إصدار الرمز المميز مع الرمز المميز للوصول OAuth 2.0. يمكن استخدام شفرة التجزئة لرمز الوصول المميز للتحقق من صحة رمز الوصول المميز. لمزيد من المعلومات بشأن كيفية إجراء هذا التحقق، انظرمواصفات OpenID Connect
nonce	`nonce`	`12345`	وnonce هي استراتيجية يتم استخدامها للتخفيف من هجمات إعادة الرمز المميز. يمكن للتطبيق الخاص بك أن يقوم بتحديد رقم nonce في طلب التخويل باستخدام تعليمة الاستعلام `nonce`. يتم إرسال القيمة التي تقدمها في الطلب بدون تعديل في المطالبة`nonce`برمز معرف مميز فقط. تسمح هذه المطالبة لتطبيقك بالتحقق من القيمة مقابل القيمة التي تم تحديدها في الطلب. يجب أن يقوم تطبيقك بإجراء هذا التحقق أثناء عملية التحقق من صحة رمز المعرف المميز.
الموضوع	`sub`	`884408e1-2918-4cz0-b12d-3aa027d7563b`	الأساسي الذي يقوم الرمز المميز بتأكيد المعلومات بشأنه، مثل مستخدم التطبيق. هذه القيمة غير قابلة للتغيير، ولا يمكن إعادة تعيينها أو إعادة استخدامها. من الممكن استخدامه لإجراء فحوصات التخويل بأمان، على سبيل المثال عند استخدام رمز الوصول المميز للمورد. بشكل افتراضي، يتم ملء مطالبة الموضوع بمعرف الكائن للمستخدم في الدليل.
مرجع فئة السياق المتعلق بالمصادقة	`acr`	غير قابل للتطبيق	يتم استخدامه فقط مع النهج القديمة.
نهج إطار العمل للثقة	`tfp`	`b2c_1_signupsignin1`	اسم النهج الذي يُستخدم للحصول على رمز المعرف المميز.
الوقت المتعلق بالمصادقة	`auth_time`	`1438535543`	الوقت الذي قام فيه المستخدم بإدخال معلومات تسجيل الدخول للمرة الأخيرة، متمثلة في وقت epoch. لا يوجد تمييز بين أن المصادقة هي تسجيل دخول جديد أو جلسة تسجيل دخول أحادية (SSO) أو نوع تسجيل دخول آخر. `auth_time`هي آخر مرة بدأ فيها التطبيق (أو المستخدم) محاولة مصادقة ضد Microsoft Azure Active Directory B2C. لا يتم تمييز الأسلوب المستخدم للمصادقة.
النطاق	`scp`	`Read`	أذونات وصول الممنوحة للمورد للحصول على رمز وصول مميز. يتم فصل الأذونات المعطاة المتعددة من خلال المسافة.
الطرف المخول له	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	معرف التطبيقلتطبيق العميل الذي بدأ الطلب.

التكوين

تُستخدم الخصائص التاليةلإدارة مدة بقاء رموز الأمان المميزة المنبعثةمن Microsoft Azure Active Directory B2C:

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

تمكين حالات الاستخدام التالية باستخدام هذه الخصائص:

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

هذه الإعدادات غير متاحة لتدفقات المستخدم لإعادة تعيين كلمة المرور.

التوافق

تُستخدم الخصائص التاليةلإدارة توافق الرمز المميز:

مطالبة المُصدر (الإصدار) - تحدد هذه الخاصية مستأجر Microsoft Azure Active Directory B2C الذي قم بإصدار الرمز المميز. القيمة الافتراضية هي https://<domain>/{B2C tenant GUID}/v2.0/. تتضمن قيمةhttps://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/معرفات لكل من مستأجر Microsoft Azure Active Directory B2C وتدفق المستخدم الذي تم استخدامه في طلب الرمز المميز. إذا احتاج التطبيق أو المكتبة إلى أن يكون Microsoft Azure Active Directory B2C متوافقًا معمواصفات OpenID Connect Discovery 1.0، فاستخدم هذه القيمة.
مطالبة الموضوع (الفرعي) - تقوم هذه الخاصية بتحديد الكيان الذي يؤكد الرمز المميز للمعلومات الخاصة به. القيمة الافتراضيةلمعرف العنصر، الذي يقوم بملءsubالمطالبة في الرمز المميز مع معرف الكائن للمستخدم. يتم توفير قيمةغير مدعومفقط للتوافق مع الإصدارات السابقة. يوصى بالتبديل إلى ObjectIDبمجرد أن تتمكن من ذلك.
مطالبة تمثل معرف النهج- تحدد هذه الخاصية نوع المطالبة الذي يتم فيه ملء اسم النهج المستخدم في طلب الرمز المميز. القيمة الافتراضية هي tfp. يتم توفير قيمةacrفقط للتوافق مع الإصدارات السابقة.

المرور من خلال

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

يدعم Microsoft Azure Active Directory B2C حاليا فقط تمرير رمز الوصول المميز لمزودي الهوية OAuth 2.0، والتي تشمل Facebook و Google. وبالنسبة لجميع موفري الهوية الآخرين، يتم إرجاع المطالبة فارغة.

التحقق من الصحة

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

والتحقق من صحة التوقيع

تحتوي JWT على ثلاثة أجزاء،رأس، و نص، وتوقيع. من الممكن استخدام مقطع التوقيع للتحقق من صحة الرمز المميز بحيث يمكن الوثوق به من قِبل تطبيقك. يتم توقيع الرموز المميزة لـMicrosoft Azure Active Directory B2C باستخدام خوارزميات التشفير غير المتماثلة المتوافقة مع معايير الصناعة، مثل RSA 256.

يحتوي عنوان الرمز المميز على معلومات حول المفتاح وطريقة التشفير المستخدمة لتوقيع الرمز المميز:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

قيمة المطالبةalg هي الخوارزمية التي تم استخدامها لتوقيع الرمز المميز. قيمة المطالبةkid هي المفتاح العام الذي تم استخدامه لتوقيع الرمز المميز. في أي وقت، يمكن لـMicrosoft Azure Active Directory B2C تسجيل رمز مميز باستخدام أي مجموعة من أزواج المفاتيح العامة والخاصة. يقوم Microsoft Azure Active Directory B2C بتدوير مجموعة المفاتيح المحتملة بشكل دوري. يجب كتابة طلبك للتعامل مع هذه التغييرات الرئيسية تلقائيًا. يوجد تكرار معقول للتحقق من وجود تحديثات للمفاتيح العامة المستخدمة بواسطة Microsoft Azure Active Directory B2C كل 24 ساعة. للتعامل مع التغييرات غير المتوقعة في المفاتيح، يجب كتابة التطبيق الخاص بك لإعادة استرداد المفاتيح العامة إذا تلقى قيمةkidغير المتوقعة.

يحتوي Microsoft Azure Active Directory B2C على نقطة نهاية بيانات تعريف OpenID Connect. باستخدام نقطة النهاية هذه، يمكن للتطبيقات طلب معلومات حول Microsoft Azure Active Directory B2C في وقت التشغيل. تتضمن هذه المعلومات نقاط النهاية ومحتويات الرمز المميز ومفاتيح تسجيل الرمز المميز. يحتوي مستأجر Microsoft Azure Active Directory B2C على مستند بيانات التعريف JSON لكل نهج. وثيقة بيانات التعريف هي عنصر JSON يحتوي على العديد من المعلومات المفيدة. تحتوي بيانات التعريف علىjwks_uri، والذي يعطي الموقع لمجموعة المفاتيح العامة المستخدمة لتوقيع الرموز المميزة. يتم توفير هذا الموقع هنا، ولكن من الأفضل جلب الموقع ديناميكيًا باستخدام مستند بيانات التعريف والتحليلjwks_uri:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

يحتوي مستند JSON الموجود في عنوان URL هذا على جميع المعلومات للمفتاح العام المستخدمة في لحظة معينة. يمكن لتطبيقك استخدام المطالبةkidفي عنوان JWT لتحديد المفتاح العام في مستند JSON المستخدم لتسجيل رمز مميز معين. ويمكنه بعد ذلك إجراء التحقق من صحة التوقيع باستخدام المفتاح العام الصحيح والخوارزمية المشار إليها.

يقع مستند بيانات التعريف للنهجB2C_1_signupsignin1في المستأجرcontoso.onmicrosoft.comفي:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

لتحديد النهج الذي تم استخدامه لتسجيل الرمز المميز (وأين تذهب لطلب بيانات التعريف)، لديك خيارين. أولًا، يتم تضمين اسم النهج فيtfp(الافتراضي) أوacr المطالبة (كما تم تكوينها) في الرمز المميز. يمكنك تحليل المطالبات من نصJWT من خلال فك تشفير Base-64 للجسم وإلغاء تسلسل سلسلة JSON الناتجة. المطالبةtfpأوacrهو اسم النهج الذي المستخدم لإصدار الرمز المميز. الخيار الآخر هو تشفير النهج بقيمة المعلمةstateعند إصدار الطلب، ثم فك تشفيرها لتحديد النهج الذي تم استخدامه. أي من الأسلوبين يصلح؟.

يستخدم Microsoft Azure Active Directory B2C خوارزمية RS256، والتي تستند إلى مواصفات RFC 3447 . يتكون المفتاح العام من مكونين: معامل RSA (n) والدليل العام RSA (e). يمكنك تحويل قيم n وe برمجيًا إلى نموذج شهادة للتحقق من صحة الرمز المميز.

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

والتحقق من صحة المطالبات

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

الجمهور- تتحقق من أن رمز المعرف المميز كان مخصصًا لتطبيقك.
ليس قبلووقت انتهاء الصلاحية- للتحقق من عدم انتهاء صلاحية رمز المعرف.
المُصدر- يتحقق من إصدار الرمز المميز لتطبيقك من قِبل Microsoft Azure Active Directory B2C.
nonce- استراتيجية للتخفيف من الهجوم إعادة الرمز المميز.

للحصول على قائمة كاملة بعمليات التحقق التي يجب أن يقوم بها التطبيق الخاص بك، انظرمواصفات OpenID Connect.

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

تعرف على المزيد بشأنالرموز الوصول المميزة.

Share via