aio Paquet

Informations d’identification pour les clients asynchrones du Kit de développement logiciel (SDK) Azure.

Classes

AuthorizationCodeCredential	S’authentifie en échangeant un code d’autorisation précédemment obtenu à partir d’Azure Active Directory. Pour plus d’informations sur le flux d’authentification, consultez la documentation Azure Active Directory .
AzureCliCredential	S’authentifie en demandant un jeton auprès d’Azure CLI. Cela nécessite une connexion à Azure via « az login » et utilise l’identité actuellement connectée de l’interface CLI.
AzureDeveloperCliCredential	S’authentifie en demandant un jeton à l’Azure Developer CLI. Azure Developer CLI est un outil d’interface en ligne de commande qui permet aux développeurs de créer, gérer et déployer des ressources dans Azure. Il s’appuie sur Azure CLI et fournit des fonctionnalités supplémentaires spécifiques aux développeurs Azure. Il permet aux utilisateurs de s’authentifier en tant qu’utilisateur et/ou principal de service auprès d’Azure Active Directory (Azure AD). AzureDeveloperCliCredential s’authentifie dans un environnement de développement et acquiert un jeton pour le compte de l’utilisateur ou du principal de service connecté dans Azure Developer CLI. Il agit en tant qu’utilisateur ou principal de service connecté Azure Developer CLI et exécute une commande Azure CLI en dessous pour authentifier l’application auprès d’Azure Active Directory. Pour utiliser ces informations d’identification, le développeur doit s’authentifier localement dans Azure Developer CLI à l’aide de l’une des commandes ci-dessous : Exécutez « azd auth login » dans Azure Developer CLI pour vous authentifier de manière interactive en tant qu’utilisateur. Exécutez « azd auth login –client-id 'client_id' –client-secret 'client_secret' –tenant-id 'tenant_id' » pour vous authentifier en tant que principal de service. Vous devrez peut-être répéter ce processus au bout d’un certain temps, en fonction de la validité du jeton d’actualisation dans votre organisation. En règle générale, la période de validité du jeton d’actualisation est de quelques semaines à quelques mois. AzureDeveloperCliCredential vous invite à vous reconnecter.
AzurePowerShellCredential	S’authentifie en demandant un jeton à Azure PowerShell. Pour cela, vous devez vous connecter à Azure via « Connect-AzAccount » et utiliser l’identité actuellement connectée.
CertificateCredential	S’authentifie en tant que principal de service à l’aide d’un certificat. Le certificat doit avoir une clé privée RSA, car ces informations d’identification signent des assertions à l’aide de RS256. Pour plus d’informations sur la configuration de l’authentification par certificat, consultez la documentation Azure Active Directory .
ChainedTokenCredential	Séquence d’informations d’identification qui est elle-même des informations d’identification. Sa get_token méthode appelle get_token chaque informations d’identification dans la séquence, dans l’ordre, en retournant le premier jeton valide reçu.
ClientAssertionCredential	Authentifie un principal de service avec une assertion JWT. Ces informations d’identification sont destinées aux scénarios avancés. CertificateCredential dispose d’une API plus pratique pour le scénario d’assertion le plus courant, l’authentification d’un principal de service avec un certificat.
ClientSecretCredential	S’authentifie en tant que principal de service à l’aide d’une clé secrète client.
DefaultAzureCredential	Informations d’identification par défaut capables de gérer la plupart des scénarios d’authentification du Kit de développement logiciel (SDK) Azure. L’identité qu’il utilise dépend de l’environnement. Lorsqu’un jeton d’accès est nécessaire, il en demande un à l’aide de ces identités à son tour, en s’arrêtant lorsque l’on fournit un jeton : Un principal de service configuré par des variables d’environnement. Consultez EnvironmentCredential pour plus d’informations. WorkloadIdentityCredential si la configuration de la variable d’environnement est définie par le webhook d’identité de charge de travail Azure. Une identité managée Azure. Consultez ManagedIdentityCredential pour plus d’informations. Sur Windows uniquement : un utilisateur qui s’est connecté avec une application Microsoft, telle que Visual Studio. Si plusieurs identités se trouvent dans le cache, la valeur de la variable AZURE_USERNAME d’environnement est utilisée pour sélectionner l’identité à utiliser. Consultez SharedTokenCacheCredential pour plus d’informations. Identité actuellement connectée à Azure CLI. Identité actuellement connectée à Azure PowerShell. Identité actuellement connectée au Azure Developer CLI. Ce comportement par défaut est configurable avec mot clé arguments.
EnvironmentCredential	Informations d’identification configurées par des variables d’environnement. Ces informations d’identification sont capables de s’authentifier en tant que principal de service à l’aide d’une clé secrète client ou d’un certificat, ou en tant qu’utilisateur avec un nom d’utilisateur et un mot de passe. La configuration est tentée dans cet ordre, à l’aide des variables d’environnement suivantes : Principal de service avec secret : AZURE_TENANT_ID : ID du locataire du principal du service. Également appelé son ID « répertoire ». AZURE_CLIENT_ID : ID client du principal de service AZURE_CLIENT_SECRET : l’une des clés secrètes client du principal de service AZURE_AUTHORITY_HOST : autorité d’un point de terminaison Azure Active Directory, par exemple « login.microsoftonline.com », l’autorité pour le cloud public Azure, qui est la valeur par défaut lorsqu’aucune valeur n’est donnée. Principal de service avec certificat : AZURE_TENANT_ID : ID du locataire du principal du service. Également appelé son ID « répertoire ». AZURE_CLIENT_ID : ID client du principal de service AZURE_CLIENT_CERTIFICATE_PATH : chemin d’accès à un fichier de certificat PEM ou PKCS12 incluant la clé privée. AZURE_CLIENT_CERTIFICATE_PASSWORD : mot de passe (facultatif) du fichier de certificat, le cas échéant. AZURE_AUTHORITY_HOST : autorité d’un point de terminaison Azure Active Directory, par exemple « login.microsoftonline.com », l’autorité pour le cloud public Azure, qui est la valeur par défaut lorsqu’aucune valeur n’est donnée.
ManagedIdentityCredential	S’authentifie avec une identité managée Azure dans n’importe quel environnement d’hébergement prenant en charge les identités managées. Par défaut, ces informations d’identification utilisent une identité affectée par le système. Pour configurer une identité affectée par l’utilisateur, utilisez l’un des arguments mot clé. Pour plus d’informations sur la configuration de l’identité managée pour les applications, consultez la documentation Azure Active Directory .
OnBehalfOfCredential	Authentifie un principal de service via le flux on-behalf-of. Ce flux est généralement utilisé par les services de niveau intermédiaire qui autorisent les demandes adressées à d’autres services avec une identité d’utilisateur déléguée. Étant donné qu’il ne s’agit pas d’un flux d’authentification interactif, une application qui l’utilise doit disposer du consentement de l’administrateur pour toutes les autorisations déléguées avant de demander des jetons pour celles-ci. Consultez la documentation Azure Active Directory pour obtenir une description plus détaillée du flux on-behalf-of.
SharedTokenCacheCredential	Procède à l’authentification à l’aide de jetons dans le cache local partagé entre les applications Microsoft.
VisualStudioCodeCredential	S’authentifie en tant qu’utilisateur Azure connecté à Visual Studio Code via l’extension « Compte Azure ». Il est connu que ces informations d’identification ne fonctionnent pas avec les versions d’extension de compte Azure plus récentes que 0.9.11. Une solution à long terme à ce problème est en cours. En attendant, envisagez de vous authentifier auprès AzureCliCredentialde .
WorkloadIdentityCredential	S’authentifie à l’aide d’une identité de charge de travail Azure Active Directory. L’authentification d’identité de charge de travail est une fonctionnalité dans Azure qui permet aux applications s’exécutant sur des machines virtuelles d’accéder à d’autres ressources Azure sans avoir besoin d’un principal de service ou d’une identité managée. Avec l’authentification d’identité de charge de travail, les applications s’authentifient à l’aide de leur propre identité, plutôt que d’utiliser un principal de service partagé ou une identité managée. Sous le capot, l’authentification d’identité de charge de travail utilise le concept d’informations d’identification du compte de service (SAC), qui sont automatiquement créées par Azure et stockées de manière sécurisée dans la machine virtuelle. En utilisant l’authentification d’identité de charge de travail, vous pouvez éviter d’avoir à gérer et à faire pivoter des principaux de service ou des identités managées pour chaque application sur chaque machine virtuelle. En outre, étant donné que les sacs sont créés automatiquement et gérés par Azure, vous n’avez pas besoin de vous soucier du stockage et de la sécurisation des informations d’identification sensibles elles-mêmes. WorkloadIdentityCredential prend en charge l’authentification d’identité de charge de travail Azure sur Azure Kubernetes et acquiert un jeton à l’aide des informations d’identification du compte de service disponibles dans l’environnement Azure Kubernetes. Pour plus d’informations, reportez-vous à cette vue d’ensemble de l’identité de charge de travail .