تسجيل الدخول إلى التطبيق أحادي الصفحة باستخدام التدفق الضمني OAuth 2.0 في Azure Active Directory B2C
العديد من التطبيقات الحديثة لديها واجهة أمامية لتطبيق الصفحة الواحدة (SPA) تتم كتابتها بشكل أساسي بلغة JavaScript. وغالباً ما تتم كتابة التطبيق باستخدام إطار عمل مثل React أو Angular أو Vue.js. أيضاً، تواجه تطبيقات الصفحة الواحدة (SPA) وغيرها من تطبيقات JavaScript التي تعمل بشكل أساسي في متصفح بعض الصعوبات الإضافية عند المصادقة:
تختلف خصائص الأمان لهذه التطبيقات عن تطبيقات الويب التقليدية المستندة إلى الخادم.
لا تدعم العديد من خوادم التخويل وموفري الهوية طلبات مشاركة الموارد عبر الأصل (CORS).
يمكن أن تكون عمليات إعادة توجيه المتصفح على صفحة كاملة بعيداً عن التطبيق غازية لتجربة المستخدم.
الطريقة الموصى بها لدعم تطبيقات الصفحة الواحدة (SPA) هي تدفق رمز التخويل OAuth 2.0 (باستخدام PKCE).
بعض أطر العمل مثل MSAL.js 1.x، لا تدعم سوى تدفق المنح الضمني. في هذه الحالات، تدعم متاجرة عمل-مستهلك الخاصة بـ Azure Active Directory (Azure AD B2C) تدفق منح التخويل الضمني 2.0 OAuth. يرد وصف التدفق في القسم 4.2 الخاص بمواصفات OAuth 2.0. في التدفق الضمني، يتلقى التطبيق الرموز المميزة مباشرةً من نقطة نهاية تخويل متاجرة عمل-مستهلك Microsoft Azure Active Directory، دون أي تبادل خادم إلى خادم. يتم تنفيذ منطق المصادقة ومعالجة الجلسة بالكامل في عميل JavaScript إما من خلال إعادة توجيه الصفحة أو مربع منبثق.
يوسع تطبيق متاجرة عمل-مستهلك Azure AD التدفق الضمني القياسي لـ OAuth 2.0 ليكون أكثر من مجرد مصادقة وتخويل. يقدم متاجرة عمل-مستهلك Azure AD معلمة النهج. باستخدام معلمة النهج، يمكنك استخدام OAuth 2.0 لإضافة نهج إلى التطبيق الخاص بك، مثل الاشتراك، وتسجيل الدخول، وتدفقات المستخدمين لإدارة ملف التعريف. في مثال طلبات HTTP الوارد في هذه المقالة، نستخدم {tenant}.onmicrosoft.com للشرح. استبدل {tenant} محل اسم مستأجرك إذا كان لديك واحداً. أيضاً، تحتاج إلى وجود إنشاء تدفق مستخدم.
نستخدم الشكل التالي لتوضيح تدفق تسجيل الدخول الضمني. يتم وصف كل خطوة بالتفصيل لاحقاً في هذه المقالة.
إرسال طلبات المصادقة
عندما يحتاج تطبيق الويب الخاص بك إلى مصادقة المستخدم وتشغيل تدفق مستخدم، يقوم بتوجيه المستخدم إلى نقطة نهاية /authorize في متاجرة عمل-مستهلك Microsoft Azure Active Directory. بعد ذلك، يتخذ المستخدم إجراءات بناءً على تدفق المستخدم.
في هذا الطلب، يشير العميل إلى الأذونات التي يحتاج إلى الحصول عليها من المستخدم في معلمة scope وتدفق المستخدم لتشغيلها. للتعرف على كيفية عمل الطلب، حاول لصق الطلب تشغيله في أي متصفح. استبدال:
{tenant}باسم مستأجر Microsoft Azure Active Directory B2C.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6بمعرّف التطبيق الخاص بالتطبيق الذي قمت بتسجيله مسبقاً في المستأجر الخاص بك.{policy}باسم نهج أنشأته في المستأجر الخاص بك، على سبيل المثالb2c_1_sign_in.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
يتم شرح المعلمات في طلب HTTP GET في الجدول أدناه.
| المعلمة | مطلوب | الوصف |
|---|---|---|
| {tenant} | نعم | اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك |
| {policy} | نعم | اسم تدفق المستخدم الذي تريد تشغيله. حدد اسم تدفق المستخدم الذي أنشأته في مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك. على سبيل المثال: b2c_1_sign_in، أو b2c_1_sign_up، أو b2c_1_edit_profile. |
| client_id | نعم | معرف التطبيق الذي حدده مدخل Azure لتطبيقك. |
| response_type | نعم | يجب أن يتضمن id_token لتسجيل الدخول إلى OpenID Connect. قد يتضمن أيضاً نوع الاستجابة token. إذا كنت تستخدم token، يمكن لتطبيقك أن يتلقى فوراً رمزاً مميزاً للوصول من نقطة نهاية التخويل، دون تقديم طلب ثانٍ إلى نقطة نهاية التخويل. إذا كنت تستخدم نوع استجابة token، فيجب أن تحتوي معلمة scope على نطاق يشير إلى المورد الذي سيتم إصدار الرمز المميز له. |
| redirect_uri | لا | عنوان URI لإعادة التوجيه الخاص بتطبيقك الذي يمكن لتطبيقك إرسال استجابات المصادقة واستلامها من خلاله. يجب أن تتطابق تماماً مع أحد عناوين URI لإعادة التوجيه التي قمت بإضافتها إلى التطبيق المسجل في المدخل، إلا أنه يجب أن يكون مرمزاً لعنوان URL. |
| response_mode | لا | تحديد الأسلوب الذي سيتم استخدامه لإعادة إرسال الرمز المميز الناتج إلى تطبيقك. بالنسبة للتدفقات الضمنية، استخدم fragment. |
| النطاق | نعم | قائمة نطاقات مفصولة بمسافة. تشير قيمة نطاق واحد إلى Microsoft Entra معرف كلا الإذنين المطلوبين. يشير نطاق openid إلى إذن لتسجيل الدخول للمستخدم والحصول على بيانات حول المستخدم في شكل الرموز المميزة للمعرّف. النطاق offline_access اختياري لتطبيقات الويب. ويشير إلى أن التطبيق الخاص بك يحتاج إلى رمز مميز للتحديث للوصول إلى الموارد لفترة طويلة. |
| الولاية | لا | قيمة مضمنة في الطلب يتم إرجاعها أيضاً في استجابة الرمز المميز. ويمكن أن تكون سلسلة من أي محتوى تريد استخدامه. عادةً ما يتم استخدام قيمة مميزة تم إنشاؤها عشوائياً لمنع هجمات تزييف طلب مواقع مشتركة. تستخدم الحالة أيضاً لترميز معلومات حول حالة المستخدم في التطبيق قبل حدوث طلب المصادقة، على سبيل المثال، الصفحة التي كان المستخدم عليها، أو تدفق المستخدم الذي كان قيد التنفيذ. |
| nonce | نعم | قيمة مضمنة في الطلب (تم إنشاؤها بواسطة التطبيق) يتم تضمينها في الرمز المميز للمعرّف الناتج كمطالبة. يمكن للتطبيق بعد ذلك التحقق من صحة هذه القيمة للتقليل من الهجمات التي تحدث أثناء نقل الرمز المميز. عادةً ما تكون القيمة عبارة عن سلسلة عشوائية ومميزة يمكن استخدامها لتحديد أصل الطلب. |
| prompt | لا | نوع تفاعل المستخدم المطلوب. حالياً، القيمة الصالحة الوحيدة هي login. تفرض هذه المعلمة على المستخدم إدخال معلومات تسجيل الدخول الخاصة به في هذا الطلب. تسجيل الدخول الأحادي لا يسري. |
هذا هو الجزء التفاعلي من التدفق. يطلب من المستخدم إكمال سير عمل النهج. قد يضطر المستخدم إلى إدخال اسم المستخدم وكلمة المرور الخاصين به، أو تسجيل الدخول بهوية اجتماعية، أو التسجيل لحساب محلي، أو أي عدد آخر من الخطوات. تعتمد إجراءات المستخدم على كيفية تعريف تدفق المستخدم.
بعد أن يكمل المستخدم تدفق المستخدم، ترجع متاجرة عمل-مستهلك Microsoft Azure Active Directory استجابة لتطبيقك عبر redirect_uri. يستخدم الأسلوب المحدد في معلمة response_mode. يكون لكل سيناريوهات إجراءات المستخدم نفس الاستجابة بالضبط، بغض النظر عن تدفق المستخدم الذي تم تنفيذه.
الاستجابة الناجحة
تبدو الاستجابة الناجحة التي تستخدم response_mode=fragment وresponse_type=id_token+token كما يلي، مع فواصل بين الأسطر للوضوح:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| المعلمة | الوصف |
|---|---|
| access_token | الرمز المميز للوصول الذي طلبه التطبيق من Microsoft Azure Active Directory B2C. |
| token_type | قيمة نوع الرمز المميز. النوع الوحيد الذي تدعمه متاجرة عمل-مستهلك Microsoft Azure Active Directory هو Bearer. |
| expires_in | مدة صلاحية الرمز المميز للوصول (بالثواني). |
| النطاق | النطاقات التي تقبل الرمز المميز. يمكنك أيضاً استخدام النطاقات لتخزين الرموز المميزة لاستخدامها لاحقاً. |
| id_token | الرمز المميز للمعرّف الذي طلبه التطبيق. يمكنك استخدام الرمز المميز للمعرّف للتحقق من هوية المستخدم وبدء جلسة مع المستخدم. لمزيد من المعلومات حول الرموز المميزة للمعرّف ومحتوياتها، راجع مرجع الرموز المميزة الخاصة بمتاجرة عمل-مستهلك Azure AD. |
| الولاية | إذا تم تضمين معلمة state في الطلب، فيجب أن تظهر نفس القيمة في الاستجابة. يجب أن يتحقق التطبيق من تطابق قيم state في الطلب والاستجابة. |
استجابة الخطأ
يمكن أيضاً إرسال استجابات الخطأ إلى عنوان URI لإعادة التوجيه بحيث يمكن للتطبيق التعامل معها بشكل مناسب:
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| المعلمة | الوصف |
|---|---|
| خطأ | رمز يُستخدَم لتصنيف أنواع الأخطاء التي تحدث. |
| error_description | يمكن أن تساعدك رسالة خطأ معينة في تحديد السبب الجذري لخطأ المصادقة. |
| الولاية | إذا تم تضمين معلمة state في الطلب، فيجب أن تظهر نفس القيمة في الاستجابة. يجب أن يتحقق التطبيق من تطابق قيم state في الطلب والاستجابة. |
التحقق من صحة الرمز المميز للمعرّف
إن تلقي رمز مميز للمعرّف ليس كافياً لمصادقة المستخدم. تحقق من صحة توقيع الرمز المميز للمعرّف، وتحقق من المطالبات في الرمز المميز وفقاً لمتطلبات تطبيقك. يستخدم Azure AD B2C رموز ويب JSON (JWTs) وتشفير المفتاح العام لتسجيل الرموز المميزة والتحقق من صحتها.
تتوفر العديد من المكتبات مفتوحة المصدر للتحقق من صحة رموز JSON المميزة للويب (JWT)، اعتماداً على اللغة التي تفضل استخدامها. ضع في اعتبارك استكشاف المكتبات مفتوحة المصدر المتاحة بدلاً من تنفيذ منطق التحقق من الصحة الخاص بك. يمكنك استخدام المعلومات الواردة في هذه المقالة لمساعدتك في تعلم كيفية استخدام هذه المكتبات بشكل صحيح.
يحتوي متاجرة عمل-مستهلك Azure AD على نقطة نهاية بيانات تعريف OpenID Connect. يمكن للتطبيق استخدام نقطة النهاية لإحضار معلومات حول متاجرة عمل-مستهلك Azure AD في وقت التشغيل. تتضمن هذه المعلومات نقاط النهاية ومحتويات الرمز المميز ومفاتيح توقيع الرمز المميز. يوجد مستند بيانات تعريف JSON لكل تدفق مستخدم في مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك. على سبيل المثال، مستند بيانات التعريف لتدفق مستخدم باسم b2c_1_sign_in في مستأجر fabrikamb2c.onmicrosoft.com موجود في:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
يعد jwks_uri إحدى خصائص مستند التكوين هذا. القيمة لنفس تدفق المستخدم ستكون:
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
لتحديد تدفق المستخدم الذي تم استخدامه لتوقيع رمز مميز للمعرّف (ومكان إحضار بيانات التعريف منه)، يمكنك استخدام أي من الخيارات التالية:
تم تضمين اسم تدفق المستخدم في مطالبة
acrفيid_token. للحصول على معلومات حول كيفية تحليل المطالبات من رمز مميز للمعرّف، راجع مرجع الرموز المميزة لمتاجرة عمل-مستهلك Azure AD.قم بتشفير تدفق المستخدم في قيمة معلمة
stateعند إصدار الطلب. بعد ذلك، قم بفك تشفير معلمةstateلتحديد تدفق المستخدم الذي تم استخدامه.
بعد الحصول على مستند بيانات التعريف من نقطة نهاية بيانات تعريف OpenID Connect، يمكنك استخدام المفاتيح العمومية RSA-256 (الموجودة في نقطة النهاية هذه) للتحقق من صحة توقيع الرمز المميز للمعرّف. قد تكون هناك مفاتيح متعددة مدرجة في نقطة النهاية هذه في أي وقت، ويتم تحديد كل منها من خلال kid. يحتوي عنوان id_token أيضاً على مطالبة kid. ويحدد أياً من هذه المفاتيح تم استخدامه لتوقيع الرمز المميز للمعرّف. لمزيد من المعلومات، بما في ذلك التعرف على التحقق من صحة الرموز المميزة، راجع مرجع الرموز المميزة لمتاجرة عمل-مستهلك Azure AD.
بعد التحقق من صحة توقيع الرمز المميز للمعرّف، تتطلب العديد من المطالبات التحقق. على سبيل المثال:
التحقق من صحة المطالبة
nonceلمنع هجمات نقل الرمز المميز. يجب أن تكون القيمة الخاصة به هي القيمة التي حددتها في طلب تسجيل الدخول.التحقق من صحة المطالبة
audللتأكد من إصدار الرمز المميز للمعرّف لتطبيقك. يجب أن تكون قيمته هي معرّف التطبيق الخاص بتطبيقك.التحقق من صحة المطالبات
iatوexpللتأكد من أن الرمز المميز للمعرّف لم تنتهِ صلاحيته.
تم وصف العديد من عمليات التحقق من الصحة التي يجب عليك إجراؤها بالتفصيل في المواصفات الأساسية لـ OpenID Connect. قد ترغب أيضاً في التحقق من صحة المطالبات الإضافية، اعتماداً على السيناريو الخاص بك. تتضمن بعض العمليات الشائعة للتحقق من الصحة ما يلي:
التأكد من أن المستخدم/ المؤسسة قد قام بالاشتراك في التطبيق.
التأكد من أن المستخدم لديه التخويل/ الامتيازات المناسبة.
التأكد من حدوث قوة معينة من المصادقة، مثل استخدام Microsoft Entra مصادقة متعددة العوامل.
لمزيد من المعلومات حول المطالبات في الرمز المميز للمعرّف، راجع مرجع الرموز المميزة لمتاجرة عمل-مستهلك Azure AD.
بعد التحقق من صحة الرمز المميز للمعرّف، يمكنك بدء جلسة مع المستخدم. في التطبيق الخاص بك، استخدم المطالبات في الرمز المميز للمعرّف للحصول على معلومات حول المستخدم. يمكن استخدام هذه المعلومات للعرض والسجلات والتخويل وما إلى ذلك.
الوصول إلى الرموز المميزة
إذا كان الشيء الوحيد الذي تحتاجه تطبيقات الويب الخاصة بك هو تنفيذ تدفقات المستخدم، فيمكنك تخطي الأقسام القليلة التالية. تنطبق المعلومات الواردة في الأقسام التالية فقط على تطبيقات الويب التي تحتاج إلى إجراء استدعاءات مصادق عليها إلى واجهة برمجة تطبيقات الويب، المحمية بواسطة متاجرة عمل-مستهلك Microsoft Azure Active Directory نفسها.
الآن بعد أن قمت بتسجيل دخول المستخدم إلى SPA الخاص بك، يمكنك الحصول على رموز الوصول لاستدعاء واجهات برمجة تطبيقات الويب التي يتم تأمينها بواسطة معرف Microsoft Entra. حتى إذا كنت قد تلقيت بالفعل رمزاً مميزاً باستخدام نوع استجابة token، يمكنك استخدام هذا الأسلوب للحصول على رموز مميزة لموارد إضافية دون إعادة توجيه المستخدم لتسجيل الدخول مرة أخرى.
في تدفق تطبيق الويب النموذجي، يمكنك تقديم طلب إلى نقطة نهاية /token. ومع ذلك، لا تدعم نقطة النهاية طلبات مشاركة الموارد عبر المصادر، لذا فإن إجراء استدعاءات AJAX للحصول على رمز مميز للتحديث ليس خياراً. بدلاً من ذلك، يمكنك استخدام التدفق الضمني في عنصر HTML iframe مخفي للحصول على رموز مميزة جديدة لواجهات برمجة تطبيقات الويب الأخرى. وفيما يلي مثال على ذلك، مع فواصل بين الأسطر للوضوح:
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| المعلمة | مطلوب؟ | الوصف |
|---|---|---|
| {tenant} | مطلوب | اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك |
| {policy} | مطلوب | يتم تشغيل تدفق المستخدم. حدد اسم تدفق المستخدم الذي أنشأته في مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك. على سبيل المثال: b2c_1_sign_in، أو b2c_1_sign_up، أو b2c_1_edit_profile. |
| client_id | مطلوب | معرّف التطبيق المعيّن للتطبيق الخاص بك في مدخل Azure. |
| response_type | مطلوب | يجب تضمين id_token لتسجيل الدخول إلى OpenID Connect. قد يتضمن أيضاً token الخاص بنوع الاستجابة. إذا كنت تستخدم token هنا، فيمكن لتطبيقك أن يتلقى فوراً رمزاً مميزاً للوصول من نقطة نهاية التخويل، دون تقديم طلب ثانٍ إلى نقطة نهاية التخويل. إذا كنت تستخدم نوع استجابة token، فيجب أن تحتوي معلمة scope على نطاق يشير إلى المورد الذي سيتم إصدار الرمز المميز له. |
| redirect_uri | المستحسنة | عنوان URI لإعادة التوجيه الخاص بتطبيقك الذي يمكن لتطبيقك إرسال استجابات المصادقة واستلامها من خلاله. يجب أن يتطابق تماماً مع أحد عناوين URL لإعادة التوجيه التي قمت بتسجيلها في المدخل، إلا إنه يجب أن يكون مشفراً بعنوان URL. |
| النطاق | مطلوب | قائمة نطاقات مفصولة بمسافات. للحصول على رموز مميزة، قم بتضمين جميع النطاقات التي تحتاجها للمورد المقصود. |
| response_mode | المستحسنة | تحديد الطريقة التي سيتم استخدامها لإرسال الرمز المميز الناتج مرة أخرى إلى تطبيقك. بالنسبة للتدفق الضمني، استخدم fragment. يمكن تحديد وضعين آخرين، query وform_post؛ لكنهما لا يعملان في التدفق الضمني. |
| الولاية | المستحسنة | قيمة مضمنة في الطلب الذي يتم إرجاعه أيضاً في استجابة الرمز المميز. ويمكن أن تكون سلسلة من أي محتوى تريد استخدامه. عادةً ما يتم استخدام قيمة مميزة تم إنشاؤها عشوائياً لمنع هجمات تزييف طلب مواقع مشتركة. تُستخدم الحالة أيضاً لتشفير المعلومات حول حالة المستخدم في التطبيق قبل حدوث طلب المصادقة، مثل الصفحة التي كان فيها. على سبيل المثال، الصفحة أو العرض الذي كان المستخدم موجوداً عليه. |
| nonce | مطلوب | قيمة مضمنة في الطلب (تم إنشاؤها بواسطة التطبيق) يتم تضمينها في الرمز المميز للمعرّف الناتج كمطالبة. يمكن للتطبيق بعد ذلك التحقق من صحة هذه القيمة للتقليل من الهجمات التي تحدث أثناء نقل الرمز المميز. عادةً ما تكون القيمة عبارة عن سلسلة عشوائية ومميزة تحدد أصل الطلب. |
| prompt | مطلوب | للتحديث والحصول على الرموز المميزة في iframe مخفي، استخدم prompt=none لضمان عدم توقف iframe في صفحة تسجيل الدخول، وإعادته فوراً. |
| login_hint | مطلوب | للتحديث والحصول على الرموز المميزة في iframe مخفي، قم بتضمين اسم المستخدم للمستخدم في هذا التلميح للتمييز بين الجلسات المتعددة التي قد تكون لدى المستخدم في وقت معين. يمكنك استخراج اسم المستخدم من تسجيل دخول سابق باستخدام مطالبة preferred_username (نطاق profile مطلوب لتلقي مطالبة preferred_username). |
| domain_hint | مطلوب | يمكن أن يكون consumers، أو organizations. للتحديث والحصول على الرموز المميزة في iframe مخفي، قم بتضمين قيمة domain_hint في الطلب. استخرج مطالبة tid من الرمز المميز للمعرّف الخاص بتسجيل دخول سابق لتحديد القيمة التي يجب استخدامها (نطاق الملف profile مطلوب لتلقي مطالبة tid). إذا كانت قيمة مطالبة tid هي 9188040d-6c67-4c5b-b112-36a304b66dad، فاستخدم domain_hint=consumers. وإلا فاستخدم domain_hint=organizations. |
عند تعيين المعلمة prompt=none، فإن هذا الطلب إما سينجح أو يفشل على الفور، ويعود إلى التطبيق الخاص بك. يتم إرسال استجابة ناجحة إلى تطبيقك عبر عنوان URI لإعادة التوجيه باستخدام الأسلوب المحدد في المعلمة response_mode.
الاستجابة الناجحة
تبدو الاستجابة الناجحة باستخدام response_mode=fragment مثل هذا المثال:
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| المعلمة | الوصف |
|---|---|
| access_token | الرمز المميز الذي طلبه التطبيق. |
| token_type | نوع الرمز المميز سيكون دائماً Bearer. |
| الولاية | إذا تم تضمين معلمة state في الطلب، فيجب أن تظهر نفس القيمة في الاستجابة. يجب أن يتحقق التطبيق من تطابق قيم state في الطلب والاستجابة. |
| expires_in | مدة صلاحية الرمز المميز للوصول (بالثواني). |
| النطاق | النطاقات التي يكون الرمز المميز للوصول صالحاً لها. |
استجابة الخطأ
يمكن أيضاً إرسال استجابات الخطأ إلى عنوان URI لإعادة التوجيه بحيث يمكن للتطبيق التعامل معها بشكل مناسب. بالنسبة لـ prompt=none، يبدو الخطأ المتوقع كما يظهر في هذا المثال:
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| المعلمة | الوصف |
|---|---|
| خطأ | سلسلة رموز خطأ يمكن استخدامها لتصنيف أنواع الأخطاء التي تحدث. يمكنك أيضاً استخدام السلسلة للتفاعل مع الأخطاء. |
| error_description | يمكن أن تساعدك رسالة خطأ معينة في تحديد السبب الجذري لخطأ المصادقة. |
إذا تلقيت هذا الخطأ في طلب iframe، فيجب على المستخدم تسجيل الدخول بشكل تفاعلي مرة أخرى لاسترداد رمز مميز جديد.
تحديث الرموز المميزة
تنتهي صلاحية الرموز المميزة للمعرّف والرموز المميزة للوصول المميزة بعد فترة قصيرة من الوقت. يجب أن يكون تطبيقك جاهزاً لتحديث هذه الرموز بشكل دوري. لا تسمح لك التدفقات الضمنية بالحصول على رمز مميز للتحديث لأسباب أمنية. لتحديث أي نوع من الرموز المميزة، استخدم التدفق الضمني في عنصر HTML iframe مخفي. وقم بتضمين معلمة prompt=none في طلب التخويل. لتلقي قيمة id_token جديدة، تأكد من استخدام response_type=id_token، وscope=openid، ومعلمة nonce.
إرسال طلب تسجيل الخروج
عندما تريد تسجيل خروج المستخدم من التطبيق، أعد توجيه المستخدم إلى نقطة نهاية تسجيل الخروج في Microsoft Azure Active Directory B2C. يمكنك بعد ذلك مسح جلسة عمل المستخدم في التطبيق. إذا لم تقم بإعادة توجيه المستخدم، فقد يتمكن من إعادة المصادقة إلى التطبيق الخاص بك دون إدخال بيانات تسجيل الدخول الخاصة به مرة أخرى لأن لديه جلسة تسجيل دخول أحادي صالحة مع Microsoft Azure Active Directory B2C.
يمكنك ببساطة إعادة توجيه المستخدم إلى end_session_endpoint المدرج في نفس مستند بيانات تعريف OpenID Connect الموضح في التحقق من صحة الرمز المميز للمعرّف. على سبيل المثال:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
| المعلمة | مطلوب | الوصف |
|---|---|---|
| {tenant} | نعم | اسم مستأجر Azure AD B2C الخاص بك. |
| {policy} | نعم | تدفق المستخدم الذي تريد استخدامه لتسجيل خروج المستخدم من التطبيق الخاص بك. يجب أن يكون هذا هو نفس تدفق المستخدم الذي استخدمه التطبيق لتسجيل دخول المستخدم. |
| post_logout_redirect_uri | لا | عنوان موقع الويب الذي يجب إعادة توجيه المستخدم إليه بعد تسجيل الخروج بنجاح. إذا لم يتم تضمينه، فسيعرض متاجرة عمل-مستهلك Azure AD للمستخدم رسالة عامة. |
| الولاية | لا | إذا تم تضمين معلمة state في الطلب، فيجب أن تظهر نفس القيمة في الاستجابة. يجب أن يتحقق التطبيق من أن صحة تطابق قيم state في الطلب والاستجابة. |
ملاحظة
يؤدي توجيه المستخدم إلى end_session_endpoint مسح بعض حالة تسجيل الدخول الأحادي للمستخدم باستخدام متاجرة عمل-مستهلك Azure AD. ومع ذلك، فإنه لا يقوم بتسجيل خروج المستخدم من جلسة موفر الهوية الاجتماعية للمستخدم. إذا حدد المستخدم نفس موفر الهوية أثناء تسجيل دخول لاحق، تتم إعادة مصادقة المستخدم، دون إدخال بيانات تسجيل الدخول الخاصة به. إذا أراد المستخدم تسجيل الخروج من تطبيق Azure AD B2C، فهذا لا يعني بالضرورة أنه يريد تسجيل الخروج تمامًا من حساب Facebook الخاص به، على سبيل المثال. ومع ذلك، بالنسبة للحسابات المحلية، سيتم إنهاء جلسة المستخدم بشكل صحيح.
الخطوات التالية
راجع نموذج التعليمات البرمجية: تسجيل الدخول باستخدام متاجرة عمل-مستهلك Azure AD في JavaScript SPA.