تدفق رمز التخويل OAuth 2.0 فيAzure Active Directory B2C

مقالة
11/06/2023

يمكنك استخدام منحة رمز التخويل OAuth 2.0 في التطبيقات المثبتة على جهاز ما للوصول إلى الموارد المحمية، مثل واجهات برمجة التطبيقات على الويب. باستخدام تطبيق Azure Active Directory B2C (Azure AD B2C) لـ OAuth 2.0، يمكنك إضافة مهام الاشتراك، وتسجيل الدخول، وغيرها من مهام إدارة الهوية إلى تطبيقات الصفحة الواحدة، والموبايل، وسطح المكتب الخاصة بك. هذه المقالة لها لغة مستقلة. في المقالة، نقوم بوصف كيفية إرسال رسائل HTTP وتلقيها دون استخدام أي مكتبات مفتوحة المصدر. إذا أمكن، نوصي باستخدام Microsoft Authentication Libraries (MSAL) المعتمد. انظر عينة من التطبيقات التي تستخدم MSAL.

تم وصف تدفق التعليمة البرمجية للتخويل OAuth 2.0 في القسم 4.1 من مواصفات OAuth 2.0. يمكنك استخدامه للمصادقة والتخويل في معظم أنواع التطبيقات، بما في ذلك تطبيقات الويب وتطبيقات الصفحة الواحدة والتطبيقات المثبتة الأصلية. يمكنك استخدام تدفق رمز التخويل OAuth 2.0 للحصول على الرموز المميزة الخاصة بالوصول والتحديث للتطبيقات الخاصة بك بشكل آمن، والتي يمكن استخدامها للوصول إلى الموارد التي يتم تأمينها بواسطة خادم التخويل. الرمز المميز الخاص بالتحديث يسمح للعميل بالحصول على رموز جديدة للوصول (والتحديث) بمجرد انتهاء صلاحية الرمز المميز الوصول الخاص بالوصول بعد ساعة واحدة.

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

ملاحظة

لإضافة إدارة الهوية إلى تطبيق ويب باستخدام Azure AD B2C، استخدم OpenID Connect بدلًا من OAuth 2.0.

يوسع Azure AD B2C تدفق OAuth 2.0 القياسية للقيام بأكثر من مصادقة وتخويل بسيط. فإنه يقدم تدفق المستخدم. مع تدفق المستخدم، يمكنك استخدام OAuth 2.0 لإضافة تجارب المستخدم إلى التطبيق الخاص بك، مثل الاشتراك، وتسجيل الدخول، وإدارة ملف التعريف. يتضمن موفرو الهوية الذين يستخدمون بروتوكول OAuth 2.0 Amazon ومعرف Microsoft Entra وFacebook وGitHub وGoogle وLinkedIn.

لتجربة طلبات HTTP في هذه المقالة:

استبدل {tenant} باسم مستأجر Azure AD B2C الخاص بك.
استبدل 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 بمعرف التطبيق للتطبيق الذي قمت بتسجيله مسبقًا في Azure AD B2C tenant الخاص بك.
استبدل {policy} باسم نهج أنشأته في المستأجر الخاص بك، على سبيل المثال b2c_1_sign_in.

إعداد معرّف URI لإعادة التوجيه المطلوب لتطبيقات الصفحة الواحدة

يتطلب تدفق رمز التخويل لتطبيقات صفحة واحدة بعض الإعداد الإضافي. اتبع الإرشادات لإنشاء تطبيق الصفحة الواحدة لوضع علامة معرف URI لإعادة توجيه الخاص بك بشكل صحيح كما تم تمكينه لـ CORS. لتحديث عنوان إعادة توجيه URL حالي لتمكين CORS، يمكنك النقر على مطالب الترحيل في القسم "Web" من علامة التبويب المصادقةالخاصة بـتسجيل التطبيق. بدلاً من ذلك، يمكنك فتح محرر بيان تسجيلات التطبيقات وتعيين الحقل type معرّف URI لإعادة التوجيه إلى spa في القسم replyUrlsWithType.

spaنوع إعادة التوجيه متوافق مع التدفق الضمني. يمكن للتطبيقات التي تستخدم التدفق الضمني حاليًّا للحصول على رموز مميزة الانتقال إلى spa نوع معرّف URI لإعادة التوجيه دون عوائق ومتابعة استخدام التدفق الضمني.

1. الحصول على رمز التخويل

يبدأ تدفق تعليمة برمجية للتخويل بتوجيه العميل للمستخدم إلى/authorize نقطة النهاية. هذا هو الجزء التفاعلي من التدفق، حيث يقوم المستخدم بإجراء. في هذا الطلب، يشير العميل إلى الأذونات التي يحتاج الحصول عليها من المستخدم في scope المعلمة. توضح الأمثلة التالية (مع فواصل الأسطر لسهولة القراءة) كيفية الحصول على رمز تخويل. إذا كنت تختبر طلب GET HTTP هذا، فاستخدم متصفحك.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256

المعلمة	مطلوب؟	الوصف
{tenant}	مطلوب	اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك
{policy}	مطلوب	يتم تشغيل تدفق المستخدم. حدد اسم تدفق المستخدم الذي أنشأته في مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك. على سبيل المثال: `b2c_1_sign_in`، أو `b2c_1_sign_up`، أو `b2c_1_edit_profile`.
client_id	مطلوب	معرّف التطبيق المعيّن للتطبيق الخاص بك في مدخل Azure.
response_type	مطلوب	نوع الاستجابة التي يجب أن يتضمن`code` لتدفق تعليمة برمجية للتخويل. يمكنك تلقي رمز مميز للمعرف إذا قمت بتضمينه في نوع الاستجابة مثل `code+id_token`، وفي هذه الحالة، يحتاج النطاق إلى تضمينه`openid`.
redirect_uri	مطلوب	معرّف URI لإعادة التوجيه للتطبيق الخاص بك، حيث يتم إرسال استجابات المصادقة واستقبالها من قبل التطبيق الخاص بك. يجب أن تتطابق تمامًا أحد معرّفات URIs لإعادة التوجيه التي قمت بتسجيلها في المدخل، إلا أنه يجب أن يكون مرمزًا لعنوان URL.
النطاق	مطلوب	قائمة نطاقات مفصولة بمسافة. يشير النطاق `openid`إلى إذن لتسجيل الدخول للمستخدم والحصول على بيانات حول المستخدم في نموذج رموز المعرّف المميزة. `offline_access` نطاق اختياري لتطبيقات الويب. يشير إلى أن تطبيقك سيحتاج إلى رمز تحديث مميز للوصول الموسع إلى الموارد. يشير معرف العميل إلى أن الرمز المميز الذي تم إصداره مخصص للاستخدام من قبل العميل المسجل في Azure AD B2C. يشير `https://{tenant-name}/{app-id-uri}/{scope}` إلى إذن للموارد المحمية، مثل واجهة برمجة تطبيقات ويب. للحصول على مزيدٍ من المعلومات، راجع طلب الرمز المميز للوصول.
response_mode	المستحسنة	الطريقة التي تستخدمها لإرسال رمز التخويل الناتج إلى التطبيق. يمكن أن يكون `query`، أو `form_post`، أو `fragment`.
الولاية	المستحسنة	قيمة مضمنة في الطلب يمكن أن تكون سلسلة من أي محتوى تريد استخدامه. عادةً، يتم استخدام قيمة فريدة من نوعها تم إنشاؤها عشوائيًا، لمنع هجمات تزييف طلب مواقع مشتركة. كما يتم استخدام الحالة لترميز معلومات حول حالة المستخدم في التطبيق قبل حدوث طلب المصادقة. على سبيل المثال، الصفحة التي قام المستخدم بتصفحها أو تدفق المستخدم الذي تم تنفيذه.
مطالبة	‏‏اختياري	نوع تفاعل المستخدم المطلوب. حاليًّا، القيمة الصالحة الوحيدة هي `login`، والتي تجبر المستخدم على إدخال بيانات الاعتماد الخاصة به في هذا الطلب. تسجيل الدخول الأحادي غير سارٍ.
code_challenge	الموصى بها / المطلوبة	يستخدم لتأمين منح رمز التفويض عبر Proof Key for Code Exchange (PKCE). مطلوب إذا تم تضمين `code_challenge_method`. تحتاج إلى إضافة منطق في تطبيقك لإنشاء `code_verifier` و`code_challenge`. `code_challenge` هو تجزئة SHA256 المشفرة بعنوان Base64 URL لـ `code_verifier`. يمكنك تخزين `code_verifier` في تطبيقك لاستخدامه لاحقًا، وإرسال `code_challenge` بجانب طلب التخويل. للحصول على مزيدٍ من المعلومات، راجع PKCE RFC. يوصى بذلك الآن لجميع أنواع التطبيقات - التطبيقات الأصلية وSPAs والعملاء السريين مثل تطبيقات الويب.
`code_challenge_method`	الموصى بها / المطلوبة	الأسلوب المستخدم لتشفير`code_verifier`للمعلمة`code_challenge`. يجب أن يكون هذا `S256`، ولكن المواصفات تسمح باستخدام `plain` إذا تعذر على العميل لأي سبب كان دعم SHA256. إذا استبعدت `code_challenge_method`، ولكن لا تزال تُضمن `code_challenge`، فمن المفترض أن يكون `code_challenge` نصًا عاديًا. يدعم النظام الأساسي الخاص بالهوية في Microsoft `plain`و`S256`. للحصول على مزيدٍ من المعلومات، راجع PKCE RFC. مطلوب لتطبيقات الصفحة الواحدة باستخدام تدفق رمز التخويل.
login_hint	لا	يمكن استخدامها لملء حقل اسم تسجيل الدخول في صفحة تسجيل الدخول مسبقًا. للحصول على مزيدٍ من المعلومات، راجع الملء السابق لاسم تسجيل الدخول.
domain_hint	لا	توفير تلميح إلى Azure AD B2C حول موفر الهوية الاجتماعية التي يجب استخدامها لتسجيل الدخول. إذا تم تضمين قيمة صالحة، ينتقل المستخدم مباشرة إلى صفحة تسجيل الدخول لموفر الهوية. لمزيد من المعلومات، راجع إعادة توجيه تسجيل الدخول إلى موفر الخدمة الاجتماعي.
معلمات مخصصة	لا	المعلمات المخصصة التي يمكن استخدامها مع النُّهج المخصصة. على سبيل المثال، محتوى الصفحة المخصص الديناميكي URIأو محللات المطالبة بقيمة المفتاح.

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

بعد أن يكمل المستخدم تدفق المستخدم، يقوم Microsoft Entra ID بإرجاع استجابة لتطبيقك بالقيمة التي استخدمتها ل redirect_uri. يستخدم الأسلوب المحدد في معلمة response_mode. الاستجابة مشابهة تمامًا لكل سيناريو من سيناريوهات إجراء المستخدم، مستقلة عن تدفق المستخدم الذي تم تنفيذه.

يبدو أن الاستجابة الناجحة التي تستخدم response_mode=query هي:

GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...        // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response                // the value provided in the request

المعلمة	الوصف
التعليمة البرمجية	رمز التخويل الذي طلبه التطبيق. يمكن للتطبيق استخدام رمز التخويل لطلب رمز وصول لمورد الهدف. رموز التفويض قصيرة الأجل بشكل كبير. عادةً، تنتهي صلاحيتها بعد حوالي 10 دقائق.
الولاية	راجع الوصف الكامل في الجدول في المقطع السابق. إذا تم تضمين معلمة `state` في الطلب، يجب أن تظهر نفس القيمة في الاستجابة. يجب أن يتحقق التطبيق من تطابق قيم `state` في الطلب والاستجابة.

يمكن أيضًا إرسال استجابات الخطأ إلى معرّف URI لإعادة التوجيه بحيث يمكن للتطبيق التعامل معها بشكل مناسب:

GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response

المعلمة	الوصف
خطأ	سلسلة رمز الخطأ التي يمكنك استخدامها لتصنيف أنواع الأخطاء الواقعة. يمكنك أيضًا استخدام السلسلة للرد على الأخطاء.
error_description	رسالة خطأ معينة يمكن أن تساعدك في تحديد السبب الجذري لخطأ المصادقة.
الولاية	راجع الوصف الكامل في الجدول السابق. إذا تم تضمين معلمة `state` في الطلب، يجب أن تظهر نفس القيمة في الاستجابة. يجب أن يتحقق التطبيق من تطابق قيم `state` في الطلب والاستجابة.

2. احصل على الرمز المميز للوصول

يمكنك قبول رمز التخويل الذي حصلت عليه باستخدامcode لرمز مميز للمورد المطلوب عن طريق إرسال طلب POST /tokenإلى نقطة النهاية. في Azure AD B2C، يمكنك طلب رموز الوصول المميزة لواجهات برمجة التطبيقات الأخرى كالمعتاد عن طريق تحديد النطاق (النطاقات) الخاصة بها في الطلب.

يمكنك أيضًا طلب رمز الوصول المميز لواجهة برمجة تطبيقات الويب الخلفية الخاصة بالتطبيق الخاص بك عن طريق اتفاقية استخدام معرّف عميل التطبيق كنطاق مطلوب (مما سيؤدي إلى رمز وصول مميز مع معرّف العميل هذا على أنه "الجمهور"):

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1

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
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong

المعلمة	مطلوب؟	الوصف
{tenant}	مطلوب	اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك
{policy}	مطلوب	تدفق المستخدم الذي تم استخدامه للحصول على رمز التخويل. لا يمكنك استخدام تدفق مستخدم مختلف في هذا الطلب.
client_id	مطلوب	معرّف التطبيق المعيّن للتطبيق الخاص بك في مدخل Azure.
client_secret	نعم، في Web Apps	بيانات سرية عن التطبيق الذي تم إنشاؤه في مدخل Azure. يتم استخدام بيانات العميل السرية في هذا التدفق لسيناريوهات تطبيق ويب، حيث يمكن للعميل تخزين بياناته السرية بشكل آمن. بالنسبة لسيناريوهات التطبيق الأصلي (العميل العام)، لا يمكن تخزين بيانات العميل السرية بشكل آمن، وبالتالي لا يتم استخدامها في هذه المكالمة. إذا كنت تستخدم بيانات العميل السرية، يُرجى تغييرها على أساس دوري.
grant_type	مطلوب	نوع المنحة. بالنسبة لتدفق التعليمة البرمجية للتخويل، يجب أن يكون نوع المنحة `authorization_code`.
النطاق	المستحسنة	قائمة نطاقات مفصولة بمسافة. تشير قيمة نطاق واحد إلى Microsoft Entra معرف كلا الإذنين المطلوبين. يشير استخدام معرّف العميل كنطاق إلى أن التطبيق يحتاج إلى رمز مميز للوصول يمكن استخدامه مقابل الخدمة الخاصة بك أو واجهة برمجة تطبيقات الويب، ممثلة بنفس معرّف العميل. ويشير نطاق `offline_access` إلى أن التطبيق الخاص بك يحتاج إلى رمز مميز للتحديث للوصول إلى الموارد لفترة طويلة. يمكنك أيضًا استخدام نطاق `openid` لطلب رمز مميز معرّف من Azure AD B2C.
التعليمة البرمجية	مطلوب	رمز التخويل الذي حصلت عليه في نقطة النهاية `/authorize`.
redirect_uri	مطلوب	معرّف URI لإعادة توجيه للتطبيق حيث تتلقى رمز التخويل.
code_verifier	موصى به	نفس `code_verifier` الذي استخدمته للحصول على رمز التخويل. مطلوبة إذا تم استخدام PKCE في طلب منحة رمز التخويل. لمزيد من المعلومات، راجع PKCE RFC.

إذا كنت تختبر طلب POST HTTP هذا، فيمكنك استخدام أي عميل HTTP مثل Microsoft PowerShell أو ساعي البريد.

استجابة الرمز المميز الناجحة تبدو كما يلي:

{
    "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...",
}

المعلمة	الوصف
not_before	الوقت الذي يعتبر الرمز المميز صالحًا فيه هو وقت محدد.
token_type	قيمة نوع الرمز المميز. النوع الوحيد الذي يدعمه معرف Microsoft Entra هو Bearer.
access_token	رمزJSON Web Token (JWT) المعتمد الذي طلبته.
النطاق	النطاقات التي تقبل الرمز المميز. يمكنك أيضًا استخدام نطاقات لتخزين الرموز المميزة لاستخدامها لاحقًا.
expires_in	طول الوقت الذي يكون الرمز المميز صالحًا فيه (بالثواني).
refresh_token	رمز مميز لتحديث OAuth 2.0. يمكن للتطبيق استخدام هذا الرمز المميز للحصول على رموز مميزة إضافية بعد انتهاء صلاحية الرمز المميز الحالي. الرموز المميزة للتحديث طويلة الأمد. يمكنك استخدامها للاحتفاظ بالوصول إلى الموارد لفترات زمنية ممتدة. للحصول على مزيدٍ من المعلومات، راجع مرجع الرمز المميز الخاص بـAzure AD B2C.

تبدو استجابات الخطأ كما يلي:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

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

3. استخدام الرمز المميز

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

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. تحديث الرمز المميز

تعد الرموز المميزة ورموز المعرّف المميزة قصيرة الأجل. بعد انتهاء صلاحيتها، يجب تحديثها لمتابعة الوصول إلى الموارد. عند تحديث رمز الوصول المميز، تقوم متاجرة عمل-مستهلك لـ 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

Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

المعلمة	مطلوب؟	الوصف
{tenant}	مطلوب	اسم مستأجر متاجرة عمل-مستهلك Azure AD الخاص بك
{policy}	مطلوب	تدفق المستخدم الذي تم استخدامه للحصول على الرمز المميز للتحديث الأصلي. لا يمكنك استخدام تدفق مستخدم مختلف في هذا الطلب.
client_id	مطلوب	معرّف التطبيق المعيّن للتطبيق الخاص بك في مدخل Azure.
client_secret	نعم، في Web Apps	بيانات سرية عن التطبيق الذي تم إنشاؤه في مدخل Azure. يتم استخدام بيانات العميل السرية في هذا التدفق لسيناريوهات تطبيق ويب، حيث يمكن للعميل تخزين بياناته السرية بشكل آمن. بالنسبة لسيناريوهات التطبيق الأصلي (العميل العام)، لا يمكن تخزين بيانات العميل السرية بشكل آمن، وبالتالي لا يتم استخدامها في هذه المكالمة. إذا كنت تستخدم بيانات العميل السرية، يُرجى تغييرها على أساس دوري.
grant_type	مطلوب	نوع المنحة. بالنسبة لتدفق التعليمة البرمجية للتخويل، يجب أن يكون نوع المنحة `refresh_token`.
النطاق	المستحسنة	قائمة نطاقات مفصولة بمسافة. تشير قيمة نطاق واحدة إلى Microsoft Entra معرف كلا الإذنين المطلوبين. يشير استخدام معرّف العميل كنطاق إلى أن التطبيق يحتاج إلى رمز مميز للوصول يمكن استخدامه مقابل الخدمة الخاصة بك أو واجهة برمجة تطبيقات الويب، ممثلة بنفس معرّف العميل. ويشير نطاق `offline_access` إلى أن التطبيق الخاص بك يحتاج إلى رمز مميز للتحديث للوصول طويل الأمد إلى الموارد. يمكنك أيضًا استخدام نطاق `openid` لطلب رمز مميز معرّف من Azure AD B2C.
redirect_uri	‏‏اختياري	معرّف URI لإعادة توجيه للتطبيق حيث تتلقى رمز التخويل.
refresh_token	مطلوب	رمز التحديث الأصلي الذي حصلت عليه في المرحلة الثانية من التدفق.

استجابة الرمز المميز الناجحة تبدو كما يلي:

{
    "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...",
}

المعلمة	الوصف
not_before	الوقت الذي يعتبر الرمز المميز صالحًا فيه هو وقت محدد.
token_type	قيمة نوع الرمز المميز. النوع الوحيد الذي يدعمه معرف Microsoft Entra هو Bearer.
access_token	JWT المعتمدة التي طلبتها.
النطاق	النطاقات التي تقبل الرمز المميز. يمكنك أيضًا استخدام النطاقات لتخزين الرموز المميزة مؤقتًا لاستخدامها لاحقًا.
expires_in	طول الوقت الذي يكون الرمز المميز صالحًا فيه (بالثواني).
refresh_token	رمز مميز لتحديث OAuth 2.0. يمكن للتطبيق استخدام هذا الرمز المميز للحصول على رموز مميزة إضافية بعد انتهاء صلاحية الرمز المميز الحالي. تحديث الرموز المميزة طويلة الأمد، ويمكن استخدامها للاحتفاظ بالوصول إلى الموارد لفترات طويلة من الزمن. للحصول على مزيدٍ من المعلومات، راجع مرجع الرمز المميز الخاص بـAzure AD B2C.

تبدو استجابات الخطأ كما يلي:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

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

استخدام دليل Azure AD B2C الخاص بك

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

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

مشاركة عبر