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

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

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

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

الشروع في العمل

الترحيل من v1 إلى v2 من @azure/identity

إذا كنت تستخدم الإصدار 1 من @azure/identity، فشاهد دليل الترحيل للتحديث إلى v2.

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

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

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

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

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

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

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

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

للمصادقة باستخدام [Azure Developer CLI][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. بشكل افتراضي، ike the 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 ID، فاقرأ استخدام @azure/identity مع Microsoft Entra ID أولا. يوفر هذا المستند فهما أعمق للنظام الأساسي وكيفية تكوين حساب Azure الخاص بك بشكل صحيح.

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

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

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

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

DefaultAzureCredential

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

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

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

DefaultAzureCredential authentication flow

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

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

يتم دعم مصادقة الهوية المدارة إما عبر DefaultAzureCredential فئات بيانات الاعتماد أو ManagedIdentityCredential مباشرة لخدمات 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 إلى authorityHostAzure: إعداد السحابة ل Visual Studio Code المطابق.

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

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

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

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

بيانات اعتماد الاستخدام مثال ‏‏المرجع
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 المصادقة كمستخدم سجل الدخول إلى ملحق حساب Visual Studio Code Azure. ملحق حساب VS Code Azure

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

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

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

اسم المتغير القيمة
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) على أساس كل طلب. يمكن تمكين هذا باستخدام GetTokenOptions.enableCae(boolean) واجهة برمجة التطبيقات. CAE غير مدعوم لبيانات اعتماد المطور.

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

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

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

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

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

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

استكشاف الأخطاء وإصلاحها

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

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

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

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

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

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

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

دعم Azure AD B2C

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

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

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

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

المساهمة

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

مرات الظهور