مكتبة عميل Azure Identity ل JavaScript - الإصدار 4.4.0

توفر مكتبة Azure Identity مصادقة الرمز المميز Microsoft Entra ID (سابقا Azure Active Directory) من خلال مجموعة من تطبيقات TokenCredential المريحة.

للحصول على أمثلة لبيانات اعتماد مختلفة، راجع صفحة أمثلة Azure Identity.

الارتباطات الرئيسية:

  • التعليمات البرمجية المصدر
  • حزمة (npm)
  • الوثائق المرجعية لواجهة برمجة التطبيقات
  • وثائق معرف Microsoft Entra
  • عينات

الشروع

البيئات المدعومة حاليا

  • إصدارات LTS من Node.js
    • ملاحظة: إذا كان تطبيقك يعمل على Node.js v8 أو أقل ولا يمكنك ترقية إصدار Node.js إلى أحدث إصدار مستقر، فقم بتثبيت تبعية @azure/identity إلى الإصدار 1.1.0.
  • أحدث إصدارات Safari وChrome وEdge وFirefox.
    • ملاحظة: من بين بيانات الاعتماد المختلفة المصدرة في هذه المكتبة، InteractiveBrowserCredential هو الوحيد المعتمد في المستعرض.

راجع نهج دعم للحصول على مزيد من التفاصيل.

تثبيت الحزمة

تثبيت Azure Identity مع npm:

npm install --save @azure/identity

المتطلبات المسبقه

  • اشتراك Azure .
  • اختياري: يمكن أن يكون Azure CLI و/أو Azure PowerShell مفيدا أيضا للمصادقة في بيئة تطوير وإدارة أدوار الحساب.

متى تستخدم @azure/identity

تركز فئات بيانات الاعتماد التي تعرضها @azure/identity على توفير الطريقة الأكثر وضوحا لمصادقة عملاء Azure SDK محليا، وفي بيئات التطوير الخاصة بك، وفي الإنتاج. نهدف إلى البساطة والدعم المعقول لبروتوكولات المصادقة لتغطية معظم سيناريوهات المصادقة الممكنة على Azure. نحن نتوسع بنشاط لتغطية المزيد من السيناريوهات. للحصول على قائمة كاملة ببيانات الاعتماد المقدمة، راجع قسم فئات بيانات الاعتماد .

يتم دعم جميع أنواع بيانات الاعتماد التي توفرها @azure/identity في Node.js. بالنسبة للمتصفحات، InteractiveBrowserCredential هو نوع بيانات الاعتماد الذي سيتم استخدامه لسيناريوهات المصادقة الأساسية.

تستخدم معظم أنواع بيانات الاعتماد التي تقدمها @azure/identityمكتبة مصادقة Microsoft ل JavaScript (MSAL.js). على وجه التحديد، نستخدم مكتبات MSAL.js v2، والتي تستخدم تدفق رمز التخويل OAuth 2.0 مع PKCE وهي متوافقة معOpenID . بينما يركز @azure/identity على البساطة، تم تصميم مكتبات MSAL.js، مثل @azure/msal-common@azure/msal-node@azure/msal-browser، لتوفير دعم قوي لبروتوكولات المصادقة التي يدعمها Azure.

متى تستخدم شيئا آخر

أنواع بيانات الاعتماد @azure/identity هي تطبيقات لفئة TokenCredential@azure/core-auth. من حيث المبدأ، سيعمل أي كائن بأسلوب getToken يفي getToken(scopes: string | string[], options?: GetTokenOptions): Promise<AccessToken | null> ك TokenCredential. وهذا يعني أنه يمكن للمطورين كتابة أنواع بيانات الاعتماد الخاصة بهم لدعم حالات المصادقة التي لا يغطيها @azure/identity. لمعرفة المزيد، راجع بيانات الاعتماد المخصصة.

على الرغم من أن أنواع بيانات الاعتماد الخاصة بنا تدعم العديد من الحالات المتقدمة، قد يرغب المطورون في التحكم الكامل في بروتوكول المصادقة. بالنسبة لحالة الاستخدام هذه، نوصي باستخدام مكتبة مصادقة Microsoft ل JavaScript (MSAL.js) مباشرة. يمكنك قراءة المزيد من خلال الارتباطات التالية:

بالنسبة إلى مهام سير عمل المصادقة المتقدمة في المستعرض، لدينا قسم نعرض فيه كيفية استخدام مكتبة @azure/msal-browser مباشرة لمصادقة عملاء Azure SDK.

مصادقة العميل في بيئة التطوير

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

المصادقة عبر Azure Developer CLI

يمكن للمطورين كتابة التعليمات البرمجية خارج IDE أيضا استخدام Azure Developer CLI للمصادقة. يمكن للتطبيقات التي تستخدم DefaultAzureCredential أو AzureDeveloperCliCredential بعد ذلك استخدام هذا الحساب لمصادقة المكالمات في تطبيقها عند التشغيل محليا.

للمصادقة مع Azure Developer CLI، يمكن للمستخدمين تشغيل الأمر azd auth login. بالنسبة للمستخدمين الذين يعملون على نظام مع مستعرض ويب افتراضي، سيقوم Azure Developer CLI بتشغيل المتصفح لمصادقة المستخدم.

بالنسبة للأنظمة التي لا تحتوي على مستعرض ويب افتراضي، سيستخدم الأمر azd auth login --use-device-code تدفق مصادقة رمز الجهاز.

المصادقة عبر Azure CLI

يمكن للتطبيقات التي تستخدم AzureCliCredential، سواء مباشرة أو عبر DefaultAzureCredential، استخدام حساب Azure CLI لمصادقة المكالمات في التطبيق عند التشغيل محليا.

للمصادقة مع Azure CLI يمكن للمستخدمين تشغيل الأمر az login. بالنسبة للمستخدمين الذين يعملون على نظام مع مستعرض ويب افتراضي، سيقوم Azure cli بتشغيل المتصفح لمصادقة المستخدم.

تسجيل الدخول إلى حساب Azure CLI

بالنسبة للأنظمة التي لا تحتوي على مستعرض ويب افتراضي، سيستخدم الأمر az login تدفق مصادقة رمز الجهاز. يمكن للمستخدم أيضا إجبار Azure CLI على استخدام تدفق التعليمات البرمجية للجهاز بدلا من تشغيل مستعرض عن طريق تحديد الوسيطة --use-device-code.

رمز جهاز حساب Azure CLI تسجيل الدخول

المصادقة عبر Azure PowerShell

يمكن للتطبيقات التي تستخدم AzurePowerShellCredential، سواء مباشرة أو عبر DefaultAzureCredential، استخدام الحساب المتصل ب Azure PowerShell لمصادقة المكالمات في التطبيق عند التشغيل محليا.

للمصادقة مع Azure PowerShell يمكن للمستخدمين تشغيل Connect-AzAccount cmdlet. بشكل افتراضي، مثل Azure CLI، سيقوم Connect-AzAccount بتشغيل مستعرض الويب الافتراضي لمصادقة حساب مستخدم.

تسجيل الدخول إلى حساب Azure PowerShell

إذا تعذر دعم المصادقة التفاعلية في جلسة العمل، فستجبر الوسيطة -UseDeviceAuthentication cmdlet على استخدام تدفق مصادقة رمز الجهاز بدلا من ذلك، على غرار الخيار المقابل في بيانات اعتماد Azure CLI.

المصادقة عبر Visual Studio Code

يمكن للمطورين الذين يستخدمون Visual Studio Code استخدام ملحق حساب Azure للمصادقة عبر المحرر. يمكن للتطبيقات التي تستخدم VisualStudioCodeCredential بعد ذلك استخدام هذا الحساب لمصادقة المكالمات في تطبيقها عند التشغيل محليا.

للمصادقة في Visual Studio Code، تأكد من تثبيت ملحق حساب Azure. بمجرد التثبيت، افتح لوحة الأوامر وقم بتشغيل الأمر Azure: تسجيل الدخول.

بالإضافة إلى ذلك، استخدم حزمة المكون الإضافي @azure/identity-vscode. توفر هذه الحزمة تبعيات VisualStudioCodeCredential وتمكنها. راجعالمكونات الإضافية .

إنها مشكلة معروفة أن VisualStudioCodeCredential لا يعمل مع إصدارات ملحق حساب Azure أحدث من 0.9.11. هناك إصلاح طويل الأجل لهذه المشكلة قيد التقدم. في غضون ذلك، ضع في اعتبارك المصادقة عبرAzure CLI .

مصادقة العميل في المستعرضات

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

المفاهيم الرئيسية

إذا كانت هذه هي المرة الأولى التي تستخدم فيها معرف @azure/identity أو Microsoft Entra، فاقرأ استخدام @azure/identity مع معرف Microsoft Entra أولا. يوفر هذا المستند فهما أعمق للنظام الأساسي وكيفية تكوين حساب Azure الخاص بك بشكل صحيح.

وثائق التفويض

بيانات الاعتماد هي فئة تحتوي على البيانات المطلوبة لعميل الخدمة لمصادقة الطلبات أو يمكنها الحصول عليها. يقبل عملاء الخدمة عبر Azure SDK بيانات الاعتماد عند إنشائها. يستخدم عملاء الخدمة بيانات الاعتماد هذه لمصادقة الطلبات إلى الخدمة.

تركز مكتبة Azure Identity على مصادقة OAuth باستخدام معرف Microsoft Entra، وتوفر مجموعة متنوعة من فئات بيانات الاعتماد القادرة على الحصول على رمز Microsoft Entra المميز لمصادقة طلبات الخدمة. جميع فئات بيانات الاعتماد في هذه المكتبة هي تطبيقات TokenCredential فئة مجردة، ويمكن استخدام أي منها من قبل لإنشاء عملاء الخدمة القادرين على المصادقة باستخدام TokenCredential.

راجعفئات بيانات الاعتماد .

DefaultAzureCredential

DefaultAzureCredential مناسب لمعظم السيناريوهات حيث يهدف التطبيق إلى تشغيل في نهاية المطاف في Azure. وذلك لأن DefaultAzureCredential يجمع بين بيانات الاعتماد المستخدمة عادة للمصادقة عند نشرها مع بيانات الاعتماد المستخدمة للمصادقة في بيئة تطوير.

ملاحظة: تهدف DefaultAzureCredential إلى تبسيط بدء استخدام SDK عن طريق التعامل مع السيناريوهات الشائعة مع سلوكيات افتراضية معقولة. يجب على المطورين الذين يريدون المزيد من التحكم أو الذين لا يتم تقديم السيناريو الخاص به بواسطة الإعدادات الافتراضية استخدام أنواع بيانات الاعتماد الأخرى.

إذا تم استخدامه من Node.js، فسيحاول DefaultAzureCredential المصادقة عبر الآليات التالية بالترتيب:

تدفق المصادقة الافتراضيةAzureCredential

  1. البيئة - سيقوم بقراءة معلومات الحساب المحددة عبر متغيرات البيئة واستخدامها للمصادقة.
  2. هوية حمل العمل - إذا تم نشر التطبيق إلى خدمة Azure Kubernetes مع تمكين الهوية المدارة، فستصادق DefaultAzureCredential معها.
  3. الهوية المدارة - إذا تم نشر التطبيق إلى مضيف Azure مع تمكين الهوية المدارة، فستصادق DefaultAzureCredential مع هذا الحساب.
  4. Azure CLI - إذا قام المطور بمصادقة حساب عبر الأمر az login Azure CLI، فستصادق DefaultAzureCredential مع هذا الحساب.
  5. Azure PowerShell - إذا قام المطور بالمصادقة باستخدام الأمر Connect-AzAccount الوحدة النمطية Azure PowerShell، فستصادق DefaultAzureCredential مع هذا الحساب.
  6. Azure Developer CLI - إذا قام المطور بمصادقة حساب عبر الأمر azd auth login Azure Developer CLI، فستصادق DefaultAzureCredential مع هذا الحساب.

نهج المتابعة

اعتبارا من الإصدار 3.3.0، سيحاول DefaultAzureCredential المصادقة مع جميع بيانات اعتماد المطور حتى ينجح أحدها، بغض النظر عن أي أخطاء واجهتها بيانات اعتماد المطور السابقة. على سبيل المثال، قد تحاول بيانات اعتماد المطور الحصول على رمز مميز وفشل، لذلك سيستمر DefaultAzureCredential في بيانات الاعتماد التالية في التدفق. ستوقف بيانات اعتماد الخدمة المنشورة التدفق مع استثناء تم طرحه إذا كانت قادرة على محاولة استرداد الرمز المميز، ولكن لا تتلقى واحدا.

يسمح هذا بتجربة جميع بيانات اعتماد المطور على جهازك مع وجود سلوك منشور يمكن التنبؤ به.

ملاحظة حول VisualStudioCodeCredential

بسبب مشكلة معروفة ، تمت إزالة VisualStudioCodeCredential من سلسلة الرمز المميز DefaultAzureCredential. عند حل المشكلة في إصدار مستقبلي، سيتم إرجاع هذا التغيير.

المكونات الإضافية

توفر Azure Identity ل JavaScript واجهة برمجة تطبيقات مكون إضافي تسمح لنا بتوفير وظائف معينة من خلال حزم مكون إضافي منفصلة. تقوم حزمة @azure/identity بتصدير وظيفة ذات مستوى أعلى (useIdentityPlugin) يمكن استخدامها لتمكين مكون إضافي. نحن نقدم حزمتين إضافيتين:

  • @azure/identity-broker، الذي يوفر دعم مصادقة بوساطة من خلال وسيط أصلي، مثل Web Account Manager.
  • @azure/identity-cache-persistence، الذي يوفر التخزين المؤقت للرمز المميز المستمر في Node.js باستخدام نظام تخزين آمن أصلي يوفره نظام التشغيل الخاص بك. يسمح هذا المكون الإضافي لقيم access_token المخزنة مؤقتا باستمرار عبر الجلسات، ما يعني أن تدفق تسجيل الدخول التفاعلي لا يحتاج إلى التكرار طالما يتوفر رمز مميز مخزن مؤقتا.

امثله

يمكنك العثور على مزيد من الأمثلة على استخدام بيانات الاعتماد المختلفة في صفحة أمثلة هوية Azure

المصادقة باستخدام DefaultAzureCredential

يوضح هذا المثال مصادقة KeyClient من @azure/keyvault-keys مكتبة العميل باستخدام DefaultAzureCredential.

// The default credential first checks environment variables for configuration as described above.
// If environment configuration is incomplete, it will try managed identity.

// Azure Key Vault service to use
import { KeyClient } from "@azure/keyvault-keys";

// Azure authentication library to access Azure Key Vault
import { DefaultAzureCredential } from "@azure/identity";

// Azure SDK clients accept the credential as a parameter
const credential = new DefaultAzureCredential();

// Create authenticated client
const client = new KeyClient(vaultUrl, credential);

حدد هوية مدارة معينة من قبل المستخدم باستخدام DefaultAzureCredential

يتضمن السيناريو الشائع نسبيا المصادقة باستخدام هوية مدارة يعينها المستخدم لمورد Azure. استكشف مثال على مصادقة هوية مدارة معينة من قبل المستخدم باستخدام DefaultAzureCredential لمعرفة كيفية جعل هذا مهمة مباشرة نسبيا يمكن تكوينها باستخدام متغيرات البيئة أو في التعليمات البرمجية.

تعريف تدفق مصادقة مخصص باستخدام ChainedTokenCredential

في حين أن DefaultAzureCredential هو بشكل عام أسرع طريقة للبدء في تطوير التطبيقات ل Azure، قد يرغب المستخدمون الأكثر تقدما في تخصيص بيانات الاعتماد التي يتم أخذها في الاعتبار عند المصادقة. يمكن ChainedTokenCredential المستخدمين من دمج مثيلات بيانات اعتماد متعددة لتعريف سلسلة مخصصة من بيانات الاعتماد. يوضح هذا المثال إنشاء ChainedTokenCredential التي ستحاول المصادقة باستخدام مثيلين تم تكوينهما بشكل مختلف من ClientSecretCredential، ثم مصادقة KeyClient من @azure/keyvault-keys:

import { ClientSecretCredential, ChainedTokenCredential } from "@azure/identity";

// When an access token is requested, the chain will try each
// credential in order, stopping when one provides a token
const firstCredential = new ClientSecretCredential(tenantId, clientId, clientSecret);
const secondCredential = new ClientSecretCredential(tenantId, anotherClientId, anotherSecret);
const credentialChain = new ChainedTokenCredential(firstCredential, secondCredential);

// The chain can be used anywhere a credential is required
import { KeyClient } from "@azure/keyvault-keys";
const client = new KeyClient(vaultUrl, credentialChain);

دعم الهوية المدارة

يتم دعم مصادقة الهوية المدارة إما عبر فئات بيانات الاعتماد أو مباشرة لخدمات Azure التالية:

للحصول على أمثلة حول كيفية استخدام الهوية المدارة للمصادقة، راجع الأمثلة.

تكوين السحابة

بيانات الاعتماد الافتراضية للمصادقة على نقطة نهاية Microsoft Entra ل Azure Public Cloud. للوصول إلى الموارد في السحب الأخرى، مثل Azure Government أو سحابة خاصة، قم بتكوين بيانات الاعتماد باستخدام الوسيطة authorityHost في الدالة الإنشائية. تحدد واجهة AzureAuthorityHosts السلطات للسحب المعروفة. بالنسبة إلى سحابة حكومة الولايات المتحدة، يمكنك إنشاء مثيل لبيانات اعتماد بهذه الطريقة:

import { AzureAuthorityHosts, ClientSecretCredential } from "@azure/identity";
const credential = new ClientSecretCredential(
  "<YOUR_TENANT_ID>",
  "<YOUR_CLIENT_ID>",
  "<YOUR_CLIENT_SECRET>",
  {
    authorityHost: AzureAuthorityHosts.AzureGovernment,
  }
);

لا تتطلب كافة بيانات الاعتماد هذا التكوين. بيانات الاعتماد التي تتم مصادقتها من خلال أداة تطوير، مثل AzureCliCredential، استخدم تكوين تلك الأداة. وبالمثل، يقبل VisualStudioCodeCredential وسيطة authorityHost ولكن يتم تعيينها افتراضيا إلى authorityHost مطابقة Azure في Visual Studio Code: إعداد السحابي.

فئات بيانات الاعتماد

مصادقة التطبيقات المستضافة من Azure

بيانات الاعتماد استخدام مثل
DefaultAzureCredential يوفر تجربة مصادقة مبسطة لبدء تطوير التطبيقات التي تعمل بسرعة في Azure. مثال
ChainedTokenCredential يسمح للمستخدمين بتعريف تدفقات المصادقة المخصصة التي تشكل بيانات اعتماد متعددة. مثال
EnvironmentCredential مصادقة كيان الخدمة أو المستخدم عبر معلومات بيانات الاعتماد المحددة في متغيرات البيئة. مثال
ManagedIdentityCredential مصادقة الهوية المدارة لمورد Azure. مثال
WorkloadIdentityCredential يدعم معرف حمل عمل Microsoft Entra على Kubernetes. مثال

مصادقة كيانات الخدمة

بيانات الاعتماد استخدام مثل مرجع
AzurePipelinesCredential يدعم معرف حمل عمل Microsoft Entra على Azure Pipelines. مثال
ClientAssertionCredential مصادقة كيان خدمة باستخدام تأكيد عميل موقع. مثال المصادقة الأساسية لخدمة
ClientCertificateCredential مصادقة كيان خدمة باستخدام شهادة. مثال المصادقة الأساسية لخدمة
ClientSecretCredential مصادقة كيان خدمة باستخدام سر. مثال المصادقة الأساسية لخدمة

مصادقة المستخدمين

بيانات الاعتماد استخدام مثل مرجع
AuthorizationCodeCredential مصادقة مستخدم برمز تخويل تم الحصول عليه مسبقا. مثال رمز مصادقة OAuth2
DeviceCodeCredential مصادقة مستخدم بشكل تفاعلي على أجهزة ذات واجهة مستخدم محدودة. مثال مصادقة رمز الجهاز
InteractiveBrowserCredential مصادقة مستخدم بشكل تفاعلي باستخدام مستعرض النظام الافتراضي. اقرأ المزيد حول كيفية حدوث هذا هنا. مثال رمز مصادقة OAuth2
OnBehalfOfCredential نشر هوية المستخدم المفوض والأذونات من خلال سلسلة الطلبات المصادقة نيابة عن
UsernamePasswordCredential مصادقة مستخدم باستخدام اسم مستخدم وكلمة مرور. مثال اسم المستخدم + مصادقة كلمة المرور

المصادقة عبر أدوات التطوير

بيانات الاعتماد استخدام مثل مرجع
AzureCliCredential المصادقة في بيئة تطوير باستخدام Azure CLI. مثال مصادقة Azure CLI
AzureDeveloperCliCredential المصادقة في بيئة تطوير مع المستخدم الممكن أو كيان الخدمة في Azure Developer CLI. مرجع Azure Developer CLI
AzurePowerShellCredential المصادقة في بيئة تطوير باستخدام Azure PowerShell. مثال مصادقة Azure PowerShell
VisualStudioCodeCredential يصادق كمستخدم سجل الدخول إلى ملحق حساب Azure Visual Studio Code. ملحق حساب VS Code Azure

متغيرات البيئة

يمكن تكوين DefaultAzureCredentialEnvironmentCredential مع متغيرات البيئة. يتطلب كل نوع من أنواع المصادقة قيما لمتغيرات محددة.

كيان الخدمة مع البيانات السرية

اسم المتغير قيمة
AZURE_CLIENT_ID معرف تطبيق Microsoft Entra
AZURE_TENANT_ID معرف مستأجر Microsoft Entra للتطبيق
AZURE_CLIENT_SECRET أحد أسرار عميل التطبيق

كيان الخدمة مع الشهادة

اسم المتغير قيمة
AZURE_CLIENT_ID معرف تطبيق Microsoft Entra
AZURE_TENANT_ID معرف مستأجر Microsoft Entra للتطبيق
AZURE_CLIENT_CERTIFICATE_PATH المسار إلى ملف شهادة مشفرة من PEM بما في ذلك المفتاح الخاص
AZURE_CLIENT_CERTIFICATE_PASSWORD كلمة مرور ملف الشهادة، إن وجدت

اسم المستخدم وكلمة المرور

اسم المتغير قيمة
AZURE_CLIENT_ID معرف تطبيق Microsoft Entra
AZURE_TENANT_ID معرف مستأجر Microsoft Entra للتطبيق
AZURE_USERNAME اسم مستخدم (عادة ما يكون عنوان بريد إلكتروني)
AZURE_PASSWORD كلمة مرور هذا المستخدم

تتم محاولة التكوين بالترتيب أعلاه. على سبيل المثال، إذا كانت قيم سر العميل والشهادة موجودة، استخدام سر العميل.

تقييم الوصول المستمر

اعتبارا من الإصدار 3.3.0، يمكن الوصول إلى الموارد المحمية بواسطة تقييم الوصول المستمر (CAE) على أساس كل طلب. يمكن تمكين هذا باستخدامواجهة برمجة التطبيقات . CAE غير مدعوم لبيانات اعتماد المطور.

التخزين المؤقت للرمز المميز

التخزين المؤقت للرمز المميز هو ميزة توفرها مكتبة Azure Identity التي تسمح للتطبيقات ب:

  • الرموز المميزة لذاكرة التخزين المؤقت في الذاكرة (افتراضي) وعلى القرص (الاشتراك).
  • تحسين المرونة والأداء.
  • تقليل عدد الطلبات المقدمة إلى معرف Microsoft Entra للحصول على رموز الوصول المميزة.

توفر مكتبة Azure Identity كلا من التخزين المؤقت في الذاكرة والقرص الثابت. لمزيد من التفاصيل، راجع وثائق التخزين المؤقت للرمز المميز .

مصادقة بوساطة

وسيط المصادقة هو تطبيق يعمل على جهاز المستخدم ويدير تأكيدات المصادقة وصيانة الرمز المميز للحسابات المتصلة. حاليا، يتم دعم Windows Web Account Manager (WAM) فقط. لتمكين الدعم، استخدم حزمة @azure/identity-broker. للحصول على تفاصيل حول المصادقة باستخدام WAM، راجع وثائق المكون الإضافي للوسيط .

استكشاف الاخطاء

للحصول على المساعدة في استكشاف الأخطاء وإصلاحها، راجع دليل استكشاف الأخطاء وإصلاحها .

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

قراءة الوثائق

يمكن العثور على وثائق واجهة برمجة التطبيقات لهذه المكتبة على موقع الوثائق .

دعم مكتبة العميل

مكتبات العميل والإدارة المدرجة في صفحة إصدارات Azure SDK التي تدعم مصادقة Microsoft Entra تقبل بيانات الاعتماد من هذه المكتبة. تعرف على المزيد حول استخدام هذه المكتبات في وثائقها، والتي ترتبط من صفحة الإصدارات.

المشاكل المعروفة

دعم Azure AD B2C

لا تدعم هذه المكتبة خدمة Azure AD B2C.

للحصول على مشكلات مفتوحة أخرى، راجع مستودع GitHub الخاص بالمكتبة.

تقديم الملاحظات

إذا واجهت أخطاء أو كان لديك اقتراحات، فيرجى فتح مشكلة.

المساهمه

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

مرات الظهور