تسجيل الدخول على الويب باستخدام OpenID Connect في Azure Active Directory B2C
OpenID Connect هو بروتوكول مصادقة، بني على رأس OAuth 2.0، والذي يمكن استخدامه لتسجيل دخول المستخدمين بشكل آمن إلى تطبيقات الويب. باستخدام تنفيذ Azure Active Directory B2C (Azure AD B2C) الاتصال OpenID، يمكنك الاستعانة بمصادر خارجية للتسجيل وتسجيل الدخول وتجارب إدارة الهوية الأخرى في تطبيقات الويب الخاصة بك إلى معرف Microsoft Entra. يوضح لك هذا الدليل كيفية القيام بذلك بطريقة مستقلة عن اللغة. وهو يصف كيفية إرسال واستقبال رسائل HTTP دون استخدام أي من مكتباتنا مفتوحة المصدر.
إشعار
معظم مكتبات المصادقة مفتوحة المصدر تحصل على رموز JWT المميزة للتطبيق الخاص بك وتتحقق من صحتها. نوصي باستكشاف هذه الخيارات، بدلًا من تنفيذ التعليمات البرمجية الخاصة بك. لمزيد من المعلومات، راجع نظرة عامة حول مكتبة مصادقة مايكروسوفت (MSAL)،ومكتبة مصادقة Microsoft Identity Web.
OpenID Connect يوسع بروتوكول OAuth 2.0التخويل للاستخدام كبروتوكول مصادقة . يسمح لك بروتوكول المصادقة هذا بتنفيذ تسجيل دخول واحد. وهو يقدم مفهوم رمز تعريف مميز، يسمح للعميل بالتحقق من هوية المستخدم والحصول على معلومات ملف التعريف الأساسية حول المستخدم.
يتيح الاتصال OpenID أيضا للتطبيقات الحصول على رموز الوصول المميزة بشكل آمن. يمكنك استخدام رموز الوصول المميزة للوصول إلى الموارد التي يؤمنها خادم التخويل. نوصي الاتصال OpenID إذا كنت تقوم بإنشاء تطبيق ويب تستضيفه على خادم والوصول إليه من خلال مستعرض. لمزيد من المعلومات حول الرموز المميزة، راجع نظرة عامة على الرموز المميزة في Azure Active Directory B2C
يوسع Azure AD B2C بروتوكول OpenID Connect القياسي للقيام بأكثر من المصادقة البسيطة والتخويل. وهو يقدم معلمة تدفق المستخدم، والتي تمكنك من استخدام OpenID Connect لإضافة تجارب المستخدم إلى التطبيق الخاص بك، مثل الاشتراك، وتسجيل الدخول، وإدارة ملف التعريف.
إرسال طلبات المصادقة
عندما يحتاج تطبيق الويب الخاص بك إلى مصادقة المستخدم وتشغيل تدفق المستخدم، يمكنه توجيه المستخدم إلى /authorize نقطة نهاية. بعد ذلك، يتخذ المستخدم إجراءات بناءً على تدفق المستخدم.
في هذا الطلب، يشير العميل إلى الأذونات التي يحتاج إلى الحصول عليها من المستخدم في scope المعلمة، ويحدد تدفق المستخدم لتشغيله. للتعرف على كيفية عمل الطلب، قم بلصق الطلب في المتصفح وتشغيله. استبدل:
{tenant}باسم اسم المستأجر الخاص بك.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6بمعرف التطبيق الخاص بالتطبيق الذي سجلته في المستأجر الخاص بك.{application-id-uri}/{scope-name}مع معرف التطبيق URI ونطاق تطبيق قمت بتسجيله في المستأجر الخاص بك.{policy}باسم النهج الذي لديك في المستأجر الخاص بك، على سبيل المثالb2c_1_sign_in.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
| المعلمة | المطلوب | الوصف |
|---|---|---|
| {مستأجر} | نعم | قم بتسمية مستأجر Azure AD B2C الخاص بك. إذا كنت تستخدم مجالاً مخصصًاً، استبدل tenant.b2clogin.com بمجالك، مثلfabrikam.com. |
| {policy} | نعم | تدفق المستخدم أو النهج الذي يقوم التطبيق بتشغيله. حدد اسم تدفق المستخدم الذي تقوم بإنشائه في مستأجر Azure AD B2C. على سبيل المثال b2c_1_sign_in، أو b2c_1_sign_up، أو b2c_1_edit_profile. |
| client_id | نعم | معرف التطبيق الذي عيّنه مدخل Azure إلى التطبيق الخاص بك. |
| نونس | نعم | قيمة مضمنة في الطلب (الذي تم إنشاؤه بواسطة التطبيق) المضمن في الرمز المميز للمعرف الناتج كمطالبة. يمكن للتطبيق بعد ذلك التحقق من هذه القيمة للتخفيف من هجمات إعادة تشغيل الرمز المميز. القيمة هي عادة سلسلة فريدة عشوائية يمكن استخدامها لتعريف أصل الطلب. |
| response_type | نعم | يجب أن يتضمن رمز المعرّف المميز OpenID Connect. إذا كان تطبيق الويب الخاص بك يحتاج أيضًا إلى رموز مميزة لاستدعاء واجهة برمجة تطبيقات الويب، فيمكنك استخدام code+id_token. |
| النطاق | نعم | قائمة نطاقات مفصولة بمسافة. يشير النطاق openidإلى إذن لتسجيل الدخول للمستخدم والحصول على بيانات حول المستخدم في نموذج رموز المعرّف المميزة. offline_access نطاق اختياري لتطبيقات الويب. يشير إلى أن التطبيق الخاص بك يحتاج إلى رمز تحديث مميز للوصول الموسع إلى الموارد. يشير https://{tenant-name}/{app-id-uri}/{scope} إلى إذن للموارد المحمية، مثل واجهة برمجة تطبيقات ويب. للحصول على مزيدٍ من المعلومات، راجع طلب الرمز المميز للوصول. |
| prompt | لا | نوع تفاعل المستخدم الذي تحتاجه. القيمة الصالحة الوحيدة في هذا الوقت هي login، والتي تجبر المستخدم على إدخال بيانات الاعتماد الخاصة به في هذا الطلب. |
| redirect_uri | نعم | redirect_uri معلمة التطبيق الخاص بك، حيث يرسل الخادم استجابات المصادقة إلى التطبيق الخاص بك. يجب أن تتطابق تمامًا مع أحد معلمات redirect_uriالتي قمت بتسجيلها في مدخل Azure، إلا أنه يجب أن تكون مرمزة لعنوان URL. |
| response_mode | لا | الأسلوب المستخدم لإرسال رمز التخويل الناتج إلى التطبيق الخاص بك. يمكن أن يكون إما query،form_post، أو fragment. نوصي باستخدام وضع الاستجابة للحصول على form_post أفضل أمان. |
| الحالة | لا | قيمة يمكنك تضمينها في الطلب الذي يقوم خادم التخويل بإرجاعه في استجابة الرمز المميز. يمكن أن تكون سلسلة من أي محتوى تريده. عادة ما يتم استخدام قيمة فريدة تم إنشاؤها عشوائيّاً لمنع هجمات التزوير لطلب عبر الموقع. يتم استخدام الحالة أيضًا لترميز معلومات حول حالة المستخدم في التطبيق قبل حدوث طلب المصادقة، مثل الصفحة التي كانوا عليها. إذا كنت لا تريد تسجيل عناوين URL متعددة لإعادة التوجيه في مدخل Azure، فيمكنك استخدام المعلمة state لتمييز الاستجابات في تطبيقك عن خدمة Azure AD B2C بسبب طلبات مختلفة. |
| login_hint | لا | يمكن استخدامها لملء حقل اسم تسجيل الدخول لصفحة تسجيل الدخول مسبقا. للحصول على مزيدٍ من المعلومات، راجع الملء السابق لاسم تسجيل الدخول. |
| domain_hint | لا | توفير تلميح إلى Azure AD B2C حول موفر الهوية الاجتماعية التي يجب استخدامها لتسجيل الدخول. إذا تم تضمين قيمة صالحة، ينتقل المستخدم مباشرة إلى صفحة تسجيل الدخول لموفر الهوية. لمزيدٍ من المعلومات، راجع إعادة توجيه تسجيل الدخول إلى موفر خدمة اجتماعية. |
| معلمات مخصصة | لا | المعلمات المخصصة التي يمكن استخدامها مع النُّهج المخصصة. على سبيل المثال، محتوى الصفحة المخصص الديناميكي URIأو محللات المطالبة بقيمة المفتاح. |
عند هذه النقطة، يُطلب من المستخدم إكمال سير العمل. قد يُضطر المستخدم إلى إدخال اسم المستخدم وكلمة المرور الخاصة به، أو تسجيل الدخول باستخدام هوية اجتماعية، أو الاشتراك في الدليل. قد يكون هناك أي عدد آخر من الخطوات اعتمادًا على كيفية تعريف تدفق المستخدم.
بعد أن يكمل المستخدم تدفق المستخدم، يتم إرجاع استجابة إلى التطبيق الخاص بك في المعلمة المشار redirect_uri إليها، باستخدام الأسلوب الذي تحدده في المعلمة response_mode . الاستجابة هي نفسها لكل حالة من الحالات السابقة، بشكل مستقل عن تدفق المستخدم.
استجابة ناجحة باستخدام response_mode=fragment ستبدو كما يلي:
GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
| المعلمة | الوصف |
|---|---|
| id_token | الرمز المميز للمعرف الذي طلبه التطبيق. يمكنك استخدام الرمز المميز للمعرّف للتحقق من هوية المستخدم وبدء جلسة مع المستخدم. |
| الكود | رمز التخويل الذي طلبه التطبيق، إذا استخدمت response_type=code+id_token. يمكن للتطبيق استخدام رمز التخويل لطلب الرمز المميز للوصول لمورد هدف. تنتهي صلاحية رموز التخويل عادة بعد حوالي 10 دقائق. |
| الحالة | إذا تم تضمين معلمة state في الطلب، يجب أن تظهر نفس القيمة في الاستجابة. ينبغي أن يتحقق التطبيق من أن قيم state في الطلب والاستجابة متطابقة. |
يمكن أيضًا إرسال استجابات الخطأ إلى المعلمة redirect_uri بحيث يمكن للتطبيق معالجتها بشكل مناسب:
GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
| المعلمة | الوصف |
|---|---|
| error | رمز يمكن استخدامه لتصنيف أنواع الأخطاء التي تحدث. |
| error_description | يمكن أن تساعد رسالة خطأ معينة في تحديد السبب الجذري لخطأ المصادقة. |
| الحالة | إذا تم تضمين معلمة state في الطلب، يجب أن تظهر نفس القيمة في الاستجابة. ينبغي أن يتحقق التطبيق من أن قيم state في الطلب والاستجابة متطابقة. |
تحقق من صحة الرمز المميز للمعرف
مجرد تلقي رمز مميز للمعرف لا يكفي لمصادقة المستخدم. التحقق من صحة توقيع الرمز المميز للمعرف والتحقق من المطالبات في الرمز المميز وفقًا لمتطلبات التطبيق الخاص بك. يستخدم Azure AD B2C رموز ويب JSON (JWTs) وتشفير المفتاح العام لتسجيل الرموز المميزة والتحقق من صحتها.
إشعار
تتحقق معظم مكتبات المصادقة مفتوحة المصدر من صحة رموز JWT المميزة للتطبيق الخاص بك. نوصي باستكشاف هذه الخيارات، بدلًا من تطبيق منطق التحقق من الصحة الخاص بك. لمزيد من المعلومات، راجع نظرة عامة حول مكتبة مصادقة مايكروسوفت (MSAL)،ومكتبة مصادقة Microsoft Identity Web.
يحتوي Azure AD B2C على نقطة نهاية بيانات تعريفOpenID Connect، والتي تسمح للتطبيق بالحصول على معلومات حول Azure AD B2C في وقت التشغيل. تتضمن هذه المعلومات نقاط النهاية ومحتويات الرمز المميز ومفاتيح توقيع الرمز المميز. يوجد مستند بيانات تعريف JSON لكل تدفق مستخدم في المستأجر B2C الخاص بك. على سبيل المثال، مستند بيانات التعريف 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 في رمز المعرف المميز، انظر مطالبة بتدفق المستخدم. خيارك الآخر هو ترميز تدفق المستخدم في قيمة المعلمة stateعند إصدار الطلب، وثم فك ترميزه لتحديد أي تدفق المستخدم تم استخدامه. كلتا الطريقتين صالحة.
بعد الحصول على مستند بيانات التعريف من نقطة نهاية بيانات التعريف OpenID الاتصال، يمكنك استخدام المفاتيح العامة RSA 256 للتحقق من صحة توقيع الرمز المميز للمعرف. قد تكون هناك مفاتيح متعددة مدرجة في نقطة النهاية هذه، يتم تحديد كل منها من خلال مطالبة kid. يحتوي عنوان الرمز المميز للمعرف أيضا على مطالبة kid، والتي تشير إلى أي من هذه المفاتيح تم استخدامه لتوقيع الرمز المميز للمعرف.
للتحقق من الرموز المميزة من Azure AD B2C، تحتاج إلى إنشاء المفتاح العام باستخدام الأس (e) والمعامل (n). للقيام بذلك، تحتاج إلى معرفة كيفية إنشاء المفتاح العام في لغة برمجة من اختيارك. يمكن العثور على الوثائق الرسمية حول إنشاء المفتاح العام مع بروتوكول RSA هنا: https://tools.ietf.org/html/rfc3447#section-3.1
بعد التحقق من صحة توقيع الرمز المميز للمعرف، هناك مطالبات مختلفة تحتاج إلى التحقق منها. على سبيل المثال،
- التحقق من صحة المطالبة
nonceلمنع هجمات نقل الرمز المميز. يجب أن تكون القيمة الخاصة به هي القيمة التي حددتها في طلب تسجيل الدخول. - التحقق من صحة المطالبة
audللتأكد من إصدار الرمز المميز للمعرف للتطبيق الخاص بك. يجب أن تكون قيمته هي معرف التطبيق الخاص بالتطبيق الخاص بك. - التحقق من صحة المطالبات
iatوexpللتأكد من أن الرمز المميز للمعرف لم تنته صلاحيته.
هناك أيضًا العديد من عمليات التحقق من الصحة التي يجب عليك أن تجريها. يتم وصف عمليات التحقق بالتفصيل في OpenID الاتصال Core Spec. قد تحتاج أيضا إلى التحقق من صحة المزيد من المطالبات، اعتمادا على السيناريو الخاص بك. تتضمن بعض العمليات الشائعة للتحقق من الصحة ما يلي:
- تأكد من تسجيل المستخدم/المؤسسة للتطبيق.
- تأكد من أن المستخدم لديه تخويل/امتيازات مناسبة.
- تأكد من حدوث قوة معينة من المصادقة، مثل مصادقة Microsoft Entra متعددة العوامل.
بعد التحقق من صحة الرمز المميز "للمعرف" ، يمكنك بدء جلسة عمل مع المستخدم. يمكنك استخدام المطالبات في الرمز المميز "للمعرف" للحصول على معلومات حول المستخدم في التطبيق الخاص بك. تتضمن استخدامات هذه المعلومات العرض والسجلات والتخويل.
احصل على رمز مميز
إذا كنت بحاجة إلى تطبيق الويب الخاص بك لتشغيل تدفق المستخدم فقط، يمكنك تخطي المقاطع القليلة التالية. تنطبق هذه المقاطع فقط على تطبيقات الويب التي تحتاج إلى إجراء استدعاءات مصادق عليها إلى واجهة برمجة تطبيقات ويب وهي محمية بواسطة Azure AD B2C نفسه.
يمكنك استرداد رمز التخويل الذي حصلت عليه (باستخدامresponse_type=code+id_token) لرمز مميز للمورد المطلوب عن طريق إرسال طلب POSTإلى نقطة نهاية/token. في Azure AD B2C، يمكنك طلب رموز الوصول المميزة لواجهات برمجة التطبيقات الأخرى كالمعتاد عن طريق تحديد النطاق (النطاقات) الخاصة بها في الطلب.
يمكنك أيضا طلب رمز وصول لواجهة برمجة تطبيقات الويب الخلفية الخاصة بتطبيقك. في هذه الحالة، يمكنك استخدام معرف عميل التطبيق كنطاق مطلوب، ما يؤدي إلى رمز مميز للوصول مع معرف العميل هذا ك "الجمهور":
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| المعلمة | المطلوب | الوصف |
|---|---|---|
| {مستأجر} | نعم | اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك |
| {policy} | نعم | تدفق المستخدم الذي تم استخدامه للحصول على رمز التخويل. لا يمكنك استخدام تدفق مستخدم مختلف في هذا الطلب. إضافة هذه المعلمة إلى سلسلة الاستعلام، وليس إلى نص POST. |
| client_id | نعم | معرف التطبيق الذي عيّنه مدخل Azure إلى التطبيق الخاص بك. |
| client_secret | نعم، في Web Apps | بيانات سرية عن التطبيق الذي تم إنشاؤه في مدخل Azure. يتم استخدام بيانات العميل السرية في هذا التدفق لسيناريوهات تطبيق ويب، حيث يمكن للعميل تخزين بياناته السرية بشكل آمن. بالنسبة لسيناريوهات التطبيق الأصلي (العميل العام)، لا يمكن تخزين أسرار العميل بشكل آمن، وبالتالي لا يتم استخدامها في هذا التدفق. إذا كنت تستخدم سر العميل، فقم بتغييره على أساس دوري. |
| الكود | نعم | رمز التخويل الذي حصلت عليه في بداية تدفق المستخدم. |
| grant_type | نعم | نوع المنحة، الذي يجب أن يكون authorization_code لتدفق رمز التخويل. |
| redirect_uri | لا | معلمة التطبيق redirect_uriحيث تلقيت رمز التخويل. |
| النطاق | لا | قائمة نطاقات مفصولة بمسافة. يشير النطاق openidإلى إذن لتسجيل الدخول للمستخدم والحصول على بيانات حول المستخدم في نموذج رموز المعرّف المميزة. يمكن استخدامه للحصول على رموز مميزة إلى واجهة برمجة تطبيقات الويب الخلفية الخاصة بالتطبيق الخاص بك، والتي يتم تمثيلها بنفس معرف التطبيق على أنه العميل. يشير النطاق offline_access إلى أن التطبيق الخاص بك يحتاج إلى رمز مميز للتحديث للوصول الموسع إلى الموارد. |
تبدو استجابة الرمز المميز الناجحة كما يلي:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"expires_on": "1644254945",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| المعلمة | الوصف |
|---|---|
| not_before | وقت الفترة التي يصبح فيها الرمز المميز صالحا. |
| token_type | قيمة نوع الرمز المميز. Bearer هو النوع الوحيد المدعوم. |
| access_token | الرمز المميز JWT الموقّع الذي طلبته. |
| النطاق | النطاقات الصالحة للرمز المميز. |
| expires_in | طول الوقت الذي يكون رمز الوصول صالحًا (بالثواني). |
| expires_on | وقت الفترة عندما يصبح الرمز المميز للوصول غير صالح. |
| refresh_token | رمز تحديث OAuth 2.0. يمكن للتطبيق استخدام هذا الرمز المميز للحصول على المزيد من الرموز المميزة بعد انتهاء صلاحية الرمز المميز الحالي. يمكن استخدام الرموز المميزة للتحديث للاحتفاظ بالوصول إلى الموارد لفترات زمنية ممتدة. يجب أن يكون النطاق offline_access قد تم استخدامه في كل من طلبات التخويل والرموز المميزة لتلقي الرمز المميز للتحديث. |
تبدو استجابات الخطأ كما يلي:
{
"error": "invalid_grant",
"error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
| المعلمة | الوصف |
|---|---|
| error | رمز يمكن استخدامه لتصنيف أنواع الأخطاء التي تحدث. |
| error_description | رسالة يمكن أن تساعد في تحديد السبب الجذري لخطأ المصادقة. |
استخدام الرمز المميز
بعد الحصول على رمز مميز للوصول بنجاح، يمكنك استخدام الرمز المميز في الطلبات إلى واجهات برمجة تطبيقات الويب الخلفية عن طريق تضمينه في Authorization العنوان:
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
تحديث الرمز المميز
تعد الرموز المميزة ورموز المعرّف المميزة قصيرة الأجل. بعد انتهاء صلاحيتها، يجب تحديثها لمتابعة الوصول إلى الموارد. عند تحديث رمز الوصول المميز، تقوم متاجرة عمل-مستهلك لـ Azure AD بإرجاع رمز مميز جديد. سيقوم رمز الوصول المميز المحدث بتحديث قيم المطالبة nbf (وليس قبل)، وiat (الصادر في)، وexp (انتهاء الصلاحية). جميع قيم المطالبة الأخرى مشابهة لتلك الموجودة في الرمز المميز للوصول السابق.
يجب عليك تحديث رمز مميز عن طريق إرسال طلب POST آخر إلى نقطة النهاية /token. هذه المرة، توفير المعلمة refresh_tokenبدلًا من المعلمة code:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| المعلمة | المطلوب | الوصف |
|---|---|---|
| {مستأجر} | نعم | اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك |
| {policy} | نعم | تدفق المستخدم الذي تم استخدامه للحصول على الرمز المميز للتحديث الأصلي. لا يمكنك استخدام تدفق مستخدم مختلف في هذا الطلب. إضافة هذه المعلمة إلى سلسلة الاستعلام، وليس إلى نص POST. |
| client_id | نعم | معرف التطبيق الذي عيّنه مدخل Azure إلى التطبيق الخاص بك. |
| client_secret | نعم، في Web Apps | بيانات سرية عن التطبيق الذي تم إنشاؤه في مدخل Azure. يتم استخدام بيانات العميل السرية في هذا التدفق لسيناريوهات تطبيق ويب، حيث يمكن للعميل تخزين بياناته السرية بشكل آمن. بالنسبة لسيناريوهات التطبيق الأصلي (العميل العام)، لا يمكن تخزين أسرار العميل بشكل آمن، وبالتالي لا يتم استخدامها في هذه المكالمة. إذا كنت تستخدم سر العميل، يرجى تغييره على أساس دوري. |
| grant_type | نعم | نوع المنحة، الذي يجب أن يكون refresh_tokenلهذا الجزء من تدفق رمز التخويل. |
| refresh_token | نعم | الرمز المميز للتحديث الأصلي الذي تم الحصول عليه في الجزء الثاني من التدفق. يجب أن يتم استخدام النطاق offline_access في كل من طلبات التخويل والرموز المميزة لتلقي الرمز المميز للتحديث. |
| redirect_uri | لا | معلمة التطبيق redirect_uriحيث تلقيت رمز التخويل. |
| النطاق | لا | قائمة نطاقات مفصولة بمسافة. يشير النطاق openidإلى إذن لتسجيل الدخول للمستخدم والحصول على بيانات حول المستخدم في نموذج رموز المعرّف المميزة. يمكن استخدامه لإرسال الرموز المميزة إلى واجهة برمجة تطبيقات الويب الخلفية الخاصة بالتطبيق الخاص بك، والتي يتم تمثيلها بنفس معرف التطبيق على أنها العميل. يشير النطاق offline_access إلى أن التطبيق الخاص بك يحتاج إلى رمز مميز للتحديث للوصول الموسع إلى الموارد. |
تبدو استجابة الرمز المميز الناجحة كما يلي:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
"refresh_token_expires_in": "1209600"
}
| المعلمة | الوصف |
|---|---|
| not_before | وقت الفترة التي يصبح فيها الرمز المميز صالحا. |
| token_type | قيمة نوع الرمز المميز. Bearer هو النوع الوحيد المدعوم. |
| access_token | الرمز المميز JWT الموقع الذي تم طلبه. |
| النطاق | النطاقات الصالحة للرمز المميز. |
| expires_in | طول الوقت الذي يكون رمز الوصول صالحًا (بالثواني). |
| refresh_token | رمز تحديث OAuth 2.0. يمكن للتطبيق استخدام هذا الرمز المميز للحصول على رموز مميزة إضافية بعد انتهاء صلاحية الرمز المميز الحالي. يمكن استخدام الرموز المميزة للتحديث للاحتفاظ بالوصول إلى الموارد لفترات زمنية ممتدة. |
| refresh_token_expires_in | مدة صلاحية الرمز المميز للتحديث (بالثواني). |
تبدو استجابات الخطأ كما يلي:
{
"error": "invalid_grant",
"error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
| المعلمة | الوصف |
|---|---|
| error | رمز يمكن استخدامه لتصنيف أنواع الأخطاء التي تحدث. |
| error_description | رسالة يمكن أن تساعد في تحديد السبب الجذري لخطأ المصادقة. |
أرسل طلب تسجيل الخروج
عندما تريد تسجيل خروج المستخدم من التطبيق، لا يكفي مسح ملفات تعريف الارتباط الخاصة بالتطبيق أو إنهاء الجلسة مع المستخدم. إعادة توجيه المستخدم إلى Azure AD B2C لتسجيل الخروج. إذا فشلت في القيام بذلك، قد يكون المستخدم قادرًا على إعادة المصادقة إلى التطبيق الخاص بك دون إدخال بيانات الاعتماد الخاصة به مرة أخرى. لمزيد من المعلومات، راجع سلوك جلسة عمل Azure AD 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%2Fjwt.ms%2F
| المعلمة | المطلوب | الوصف |
|---|---|---|
| {مستأجر} | نعم | اسم مستأجر Azure AD B2C الخاص بك. إذا كنت تستخدم مجالاً مخصصًاً، استبدل tenant.b2clogin.com بمجالك، مثلfabrikam.com. |
| {policy} | نعم | تدفق المستخدم الذي تحدده في طلب التخويل. على سبيل المثال، إذا قام المستخدم بتسجيل الدخول مع b2c_1_sign_in تدفق المستخدم، حدد b2c_1_sign_in في طلب تسجيل الخروج. |
| id_token_hint | لا | رمز مميز معرّف تم إصداره مسبَقًا لتمريره إلى نقطة نهاية تسجيل الخروج كملمح حول جلسة عمل المستخدم النهائي الحالي المصادق عليها مع العميل. id_token_hintيضمن أن post_logout_redirect_uriهو عنوان لموقع الرد المسجل في إعدادات التطبيق Azure AD B2C. لمزيد من المعلومات، راجع تأمين إعادة توجيه تسجيل الخروج الخاص بك. |
| client_id | لا* | معرف التطبيق الذي عيّنه مدخل Azure إلى التطبيق الخاص بك. *هذا مطلوب عند استخدام Application عزل تكوين تسجيل دخول أحادي ويتم تعيين طلب رمز مميز للمعرف في طلب تسجيل الخروج إلى No. |
| post_logout_redirect_uri | لا | عنوان موقع الويب الذي يجب إعادة توجيه المستخدم إليه بعد تسجيل الخروج بنجاح. إذا لم يتم تضمينه، يعرض Azure AD B2C للمستخدم رسالة عامة. ما لم تقدم id_token_hint، يجب عدم تسجيل عنوان URL هذا كعنون URL للرد في إعدادات تطبيق Azure AD B2C. |
| الحالة | لا | إذا قمت بتضمين معلمة state في طلب التخويل، يقوم خادم التخويل بإرجاع نفس القيمة في الاستجابة إلى post_logout_redirect_uri. يجب أن يتحقق التطبيق من أن state القيمة في الطلب والاستجابة متطابقة. |
عند طلب تسجيل الخروج، يبطل Azure AD B2C جلسة العمل المستندة إلى ملف تعريف الارتباط Azure AD B2C، ويحاول تسجيل الخروج من موفري الهوية الموحدة. لمزيد من المعلومات، راجع تسجيل الخروج المفرد.
تأمين إعادة توجيه تسجيل الخروج
بعد تسجيل الخروج، تتم إعادة توجيه المستخدم إلى URI الذي تحدده في المعلمة post_logout_redirect_uri ، بغض النظر عن عناوين URL للرد التي تحددها للتطبيق. ومع ذلك، إذا تم تمرير id_token_hintصالح، ويتم تشغيل "طلب الرمز المميز للمعرف" في طلبات الخروج ، يتحقق Azure AD B2C من أن قيمة post_logout_redirect_uri مطابقة لأحد معرفات عناوين مواقع إعادة التوجيه المكونة للتطبيق قبل إجراء إعادة التوجيه. إذا لم يتم تكوين عنوان URL للرد المطابق للتطبيق، يتم عرض رسالة خطأ ولا تتم إعادة توجيه المستخدم.
لتعيين الرمز المميز المطلوب للمعرف في طلبات الخروج، راجع تكوين سلوك جلسة العمل في Azure Active Directory B2C.
الخطوات التالية
- تعرف على المزيد حول جلسة عمل Azure AD B2C.