إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
هام
اعتبارا من 1 مايو 2025، لن يكون Azure AD B2C متوفرا للشراء للعملاء الجدد. تعرف على المزيد في الأسئلة المتداولة.
يمكنك استخدام منحة رمز التخويل OAuth 2.0 في التطبيقات المثبتة على جهاز للوصول إلى الموارد المحمية، مثل واجهات برمجة تطبيقات الويب. باستخدام تنفيذ Azure Active Directory B2C (Azure AD B2C) ل OAuth 2.0، يمكنك إضافة مهام التسجيل وتسجيل الدخول وغيرها من مهام إدارة الهوية إلى تطبيقات الصفحة الواحدة والجوال وسطح المكتب. في هذه المقالة، نصف كيفية إرسال رسائل HTTP وتلقيها دون استخدام أي مكتبات مفتوحة المصدر. هذه المقالة مستقلة عن اللغة. عندما يكون ذلك ممكنا، نوصي باستخدام مكتبات مصادقة Microsoft (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 IDوFacebookوGitHubوGoogleوLinkedIn.
لتجربة طلبات HTTP في هذه المقالة:
- استبدل
{tenant}باسم مستأجر Azure AD B2C. - استبدل
00001111-aaaa-2222-bbbb-3333cccc4444بمعرف التطبيق الخاص بتطبيق قمت بتسجيله مسبقا في مستأجر Azure AD B2C. - استبدل
{policy}باسم نهج قمت بإنشائه في المستأجر الخاص بك، على سبيل المثالb2c_1_sign_in.
إعادة توجيه إعداد URI المطلوب لتطبيقات الصفحة الواحدة
يتطلب تدفق رمز التخويل لتطبيقات الصفحة الواحدة إعدادا إضافيا. اتبع الإرشادات لإنشاء تطبيق الصفحة الواحدة لوضع علامة على عنوان URI لإعادة التوجيه بشكل صحيح على أنه ممكن ل CORS. لتحديث URI إعادة توجيه موجود لتمكين CORS، يمكنك النقر فوق موجه الترحيل في قسم "ويب" من علامة التبويب مصادقةتسجيل التطبيق. بدلا من ذلك، يمكنك فتح محرر بيان تسجيلات التطبيقات وتعيين 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=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%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 B2C |
| {policy} | مطلوبة | تدفق المستخدم الذي سيتم تشغيله. حدد اسم تدفق المستخدم الذي أنشأته في مستأجر Azure AD B2C. على سبيل المثال: 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 | مستحسن / مطلوب | يستخدم لتأمين منح رمز التخويل عبر مفتاح الإثبات لتبادل التعليمات البرمجية (PKCE). مطلوب إذا code_challenge_method تم تضمينه. تحتاج إلى إضافة منطق في التطبيق الخاص بك لإنشاء code_verifier و code_challenge. هو code_challenge تجزئة SHA256 مرمزة بعنوان URL Base64 ل 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 لمحتوى الصفحة المخصص الديناميكي أو أدوات حل المطالبة بقيمة المفتاح. |
| حالة | اوصت | قيمة مضمنة في الطلب يمكن أن تكون سلسلة من أي محتوى تريد استخدامه. عادةً، يتم استخدام قيمة فريدة من نوعها تم إنشاؤها عشوائيًا، لمنع هجمات تزييف طلب مواقع مشتركة. كما يتم استخدام الحالة لترميز معلومات حول حالة المستخدم في التطبيق قبل حدوث طلب المصادقة. على سبيل المثال، الصفحة التي قام المستخدم بتصفحها أو تدفق المستخدم الذي تم تنفيذه. |
هام
من أجل الأمان والخصوصية، لا تضع عناوين URL أو البيانات الحساسة الأخرى مباشرة في معامل الحالة. بدلا من ذلك، استخدم مفتاحا أو معرفا يتوافق مع البيانات المخزنة في تخزين المتصفح، مثل localStorage أو sessionStorage. تتيح هذه الطريقة لتطبيقك الإشارة إلى البيانات اللازمة بشكل آمن بعد المصادقة.
عند هذه النقطة، يطلب من المستخدم إكمال سير عمل تدفق المستخدم. قد يتضمن ذلك إدخال المستخدم اسم المستخدم وكلمة المرور الخاصة به، أو تسجيل الدخول باستخدام هوية اجتماعية، أو التسجيل في الدليل، أو أي عدد آخر من الخطوات. تعتمد إجراءات المستخدم على كيفية تعريف تدفق المستخدم.
بعد أن يكمل المستخدم تدفق المستخدم، يقوم معرف Microsoft Entra بإرجاع استجابة لتطبيقك بالقيمة التي استخدمتها ل 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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
| المعلمة | مطلوب؟ | الوصف |
|---|---|---|
| {tenant} | مطلوبة | اسم مستأجر Azure AD B2C |
| {policy} | مطلوبة | تدفق المستخدم الذي تم استخدامه للحصول على رمز التخويل. لا يمكنك استخدام تدفق مستخدم مختلف في هذا الطلب. |
| client_id | مطلوبة | معرّف التطبيق المعيّن للتطبيق الخاص بك في مدخل Azure. |
| client_secret | نعم، في Web Apps | سر التطبيق الذي تم إنشاؤه في مدخل Microsoft Azure. يتم استخدام أسرار العميل في هذا التدفق لسيناريوهات Web App، حيث يمكن للعميل تخزين سر العميل بشكل آمن. بالنسبة لسيناريوهات التطبيق الأصلي (العميل العام)، لا يمكن تخزين أسرار العميل بشكل آمن، وبالتالي لا يتم استخدامها في هذه المكالمة. إذا كنت تستخدم سر العميل، فقم بتغييره على أساس دوري. |
| grant_type | مطلوبة | نوع المنحة. بالنسبة لتدفق رمز التخويل، يجب أن يكون authorization_codeنوع المنحة . |
| نطاق | اوصت | قائمة نطاقات مفصولة بمسافة. تشير قيمة نطاق واحدة إلى Azure AD B2C كلا الإذنين المطلوبين. يشير استخدام معرف العميل كنطاق إلى أن تطبيقك يحتاج إلى رمز مميز للوصول يمكن استخدامه مقابل الخدمة الخاصة بك أو واجهة برمجة تطبيقات الويب، ممثلة بنفس معرف العميل.
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": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| المعلمة | الوصف |
|---|---|
| not_before | الوقت الذي يعتبر فيه الرمز المميز صالحا، في وقت الحقبة. |
| token_type | قيمة نوع الرمز المميز. النوع الوحيد الذي يدعمه معرف Microsoft Entra هو Bearer. |
| access_token | رمز ويب JSON المميز الموقع (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 B2C بإرجاع رمز مميز جديد. سيتم تحديث رمز الوصول المميز المحدث 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=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| المعلمة | مطلوب؟ | الوصف |
|---|---|---|
| {tenant} | مطلوبة | اسم مستأجر Azure AD B2C |
| {policy} | مطلوبة | تدفق المستخدم الذي تم استخدامه للحصول على رمز التحديث المميز الأصلي. لا يمكنك استخدام تدفق مستخدم مختلف في هذا الطلب. |
| client_id | مطلوبة | معرّف التطبيق المعيّن للتطبيق الخاص بك في مدخل Azure. |
| client_secret | نعم، في Web Apps | سر التطبيق الذي تم إنشاؤه في مدخل Microsoft Azure. يتم استخدام أسرار العميل في هذا التدفق لسيناريوهات Web App، حيث يمكن للعميل تخزين سر العميل بشكل آمن. بالنسبة لسيناريوهات التطبيق الأصلي (العميل العام)، لا يمكن تخزين أسرار العميل بشكل آمن، وبالتالي لا يتم استخدامها في هذه المكالمة. إذا كنت تستخدم سر العميل، فيرجى تغييره على أساس دوري. |
| 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": "00001111-aaaa-2222-bbbb-3333cccc4444 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 لإعادة التوجيه. قم بتضمين عميل أصلي في تطبيقك.
- إنشاء تدفقات المستخدم للحصول على أسماء تدفق المستخدم.