Autenticación de aplicaciones javaScript en servicios de Azure mediante el SDK de Azure para JavaScript

Cuando una aplicación necesita acceder a un recurso de Azure (como Storage, Key Vault o Cognitive Services), la aplicación debe autenticarse en Azure. Esto es cierto para todas las aplicaciones, ya sea implementadas en Azure, implementadas localmente o en desarrollo en una estación de trabajo para desarrolladores local. En este artículo se describen los enfoques recomendados para autenticar una aplicación en Azure al usar El SDK de Azure para JavaScript.

El proceso recomendado es hacer que las aplicaciones usen la autenticación basada en tokens, en lugar de cadena de conexión o claves, al autenticarse en recursos de Azure. El SDK de Azure proporciona autenticación basada en tokens y permite que las aplicaciones se autentiquen sin problemas en los recursos de Azure, tanto si la aplicación está en desarrollo local, se implementa en Azure o se implementa en un servidor local.

El tipo específico de autenticación basada en tokens que una aplicación debe usar para autenticarse en los recursos de Azure depende de dónde se ejecuta la aplicación y se muestra en el diagrama siguiente.

Entorno Autenticación
Local Cuando un desarrollador ejecuta una aplicación durante el desarrollo local: La aplicación puede autenticarse en Azure mediante una entidad de servicio de aplicación para el desarrollo local o mediante las credenciales de Azure del desarrollador. Cada una de estas opciones se describe con más detalle en la sección autenticación durante el desarrollo local.
Azure Cuando una aplicación se hospeda en Azure: La aplicación debe autenticarse en recursos de Azure mediante una identidad administrada. Esta opción se describe con más detalle a continuación en la sección autenticación en entornos de servidor.
Local Cuando una aplicación se hospeda e implementa en el entorno local: La aplicación debe autenticarse en recursos de Azure mediante una entidad de servicio de la aplicación. Esta opción se describe con más detalle a continuación en la sección autenticación en entornos de servidor.

Un diagrama mostrando las estrategias de autenticación basadas en tokens para una aplicación dependiendo de dónde se está ejecutando.

Ventajas de la autenticación basadas en token

Al compilar aplicaciones para Azure, se recomienda encarecidamente la autenticación basada en tokens sobre secretos (cadena de conexión o claves). La autenticación basada en tokens se proporciona con DefaultAzureCredential.

Autenticación basada en tokens Secretos (claves y cadena de conexión)
Principio de privilegios mínimos, establezca los permisos específicos necesarios para la aplicación en el recurso de Azure. Una clave o cadena de conexión concede derechos completos al recurso de Azure.
No hay ningún secreto de aplicación que almacenar. Debe almacenar y rotar secretos en la configuración de la aplicación o la variable de entorno.
El SDK de Identidad de Azure administra los tokens automáticamente en segundo plano. Esto hace que el uso de la autenticación basada en tokens sea tan fácil de usar como cadena de conexión. Los secretos no se administran.

El uso de cadenas de conexión debe limitarse a la prueba inicial de aplicaciones de concepto o prototipos de desarrollo que no tienen acceso a datos confidenciales o de producción. De lo contrario, siempre se deben preferir las clases de autenticación basadas en tokens disponibles en el SDK de Azure al autenticarse en los recursos de Azure.

Use el SIGUIENTE SDK:

DefaultAzureCredential

El método DefaultAzureCredential del SDK de Azure permite a las aplicaciones usar diferentes métodos de autenticación en función del entorno en el que se ejecutan. Esto permite que las aplicaciones se implementen en entornos locales, de prueba y de producción sin cambios en el código. Configure el método de autenticación adecuado para cada entorno y DefaultAzureCredential detecte y use automáticamente ese método de autenticación. El uso de DefaultAzureCredential se prefiere sobre la codificación manual de la lógica condicional o las marcas de características para usar diferentes métodos de autenticación en distintos entornos.

Los detalles sobre el uso de la clase DefaultAzureCredential se tratan más adelante en este artículo en la sección Uso de DefaultAzureCredential en una aplicación.

Autenticación en entornos de servidor

Al hospedar en un entorno de servidor, a cada aplicación se le debe asignar una identidad de aplicación única por entorno. En Azure, una identidad de aplicación se representa mediante una entidad de servicio, un tipo especial de entidad de seguridad destinada a identificar y autenticar aplicaciones en Azure. El tipo de entidad de servicio que se va a usar para la aplicación depende de dónde se esté ejecutando la aplicación.

Autenticación durante el desarrollo local

Cuando una aplicación se ejecuta en la estación de trabajo de un desarrollador durante el desarrollo local, el entorno local todavía debe autenticarse en los servicios de Azure usados por la aplicación.

Uso de DefaultAzureCredential en una aplicación

Para usar DefaultAzureCredential en una aplicación de JavaScript, agregue el paquete @azure/identity a la aplicación.

npm install @azure/identity

A continuación, en el ejemplo de código siguiente se muestra cómo crear una instancia de un DefaultAzureCredential objeto y usarlo con una clase de cliente de Azure SDK, en este caso, un BlobServiceClient que se usa para acceder a Blob Storage.

// connect-with-default-azure-credential.js
import { BlobServiceClient } from '@azure/storage-blob';
import { DefaultAzureCredential } from '@azure/identity';
import 'dotenv/config'

const accountName = process.env.AZURE_STORAGE_ACCOUNT_NAME;
if (!accountName) throw Error('Azure Storage accountName not found');

const blobServiceClient = new BlobServiceClient(
  `https://${accountName}.blob.core.windows.net`,
  new DefaultAzureCredential()
);

DefaultAzureCredential detectará automáticamente el mecanismo de autenticación configurado para la aplicación y obtendrá los tokens necesarios para autenticar la aplicación en Azure. Si una aplicación usa más de un cliente del SDK, se puede usar el mismo objeto de credencial con cada objeto cliente del SDK.

Secuencia de selección de métodos de autenticación al usar DefaultAzureCredential

Internamente, DefaultAzureCredential implementa una cadena de selección de proveedores de credenciales para autenticar aplicaciones en recursos de Azure. Cada proveedor de credenciales puede detectar si las credenciales de ese tipo están configuradas para la aplicación. DefaultAzureCredential comprueba secuencialmente cada proveedor en orden y usa las credenciales del primer proveedor que tiene las credenciales configuradas.

Si ha configurado más de una credencial, el orden de búsqueda de la credencial a través de la cadena es importante.

El orden en el que DefaultAzureCredential busca credenciales para JavaScript se muestra en el diagrama y la tabla siguiente.

Diagrama que muestra el orden en que DefaultAzureCredential realiza consultas para ver el origen de autenticación que está configurado para una aplicación.

Hay dos rutas de acceso:

  • Servicio implementado (Azure o local): la secuencia comienza con las variables de entorno, la identidad administrada y, a continuación, el resto de las ubicaciones de una credencial (Visual Studio Code, la CLI de Azure, Azure PowerShell).
  • Entorno local del desarrollador: la cadena de la estación de trabajo del desarrollador local comienza con la sesión del usuario de Azure de Visual Studio Code, que se muestra en la barra inferior del IDE y, a continuación, pasa a la CLI de Azure y, a continuación, a Azure PowerShell. Es importante comprender si ha configurado las variables de entorno local, ya sea para todo el entorno o para el entorno virtual de un proyecto (por ejemplo, con DOTENV), estas variables invalidarán la cadena de PowerShell de Visual Studio Code :> CLI de Azure,> ya que son la primera credencial activada en la cadena.
Tipo de credencial Descripción
Entorno DefaultAzureCredential lee un conjunto de variables de entorno para determinar si se ha establecido una entidad de servicio de aplicación (usuario de aplicación) para la aplicación. Si es así, DefaultAzureCredential usa estos valores para autenticar la aplicación en Azure.

Este método se usa con más frecuencia en entornos de servidor, pero también se puede usar al desarrollar localmente.
Identidad administrada Si la aplicación se implementa en un host de Azure con la identidad administrada habilitada, DefaultAzureCredential autenticará la aplicación con esa identidad administrada de Azure. La autenticación mediante una identidad administrada se describe en la sección Autenticación en entornos de servidor de este documento.

Este método solo está disponible cuando una aplicación se hospeda en Azure mediante un servicio habilitado para identidad administrada.
Visual Studio Code Si el desarrollador se ha autenticado en Azure mediante el complemento de Visual Studio Code cuenta de Azure, DefaultAzureCredential autenticará la aplicación en Azure con esa misma cuenta.
Azure CLI Si un desarrollador se ha autenticado en Azure mediante el comando de la az login CLI de Azure, DefaultAzureCredential autenticará la aplicación en Azure con esa misma cuenta.
Azure PowerShell Si un desarrollador se ha autenticado en Azure mediante el Connect-AzAccount cmdlet de Azure PowerShell, DefaultAzureCredential autenticará la aplicación en Azure con esa misma cuenta.
Interactivo Si está habilitado, DefaultAzureCredential autenticará interactivamente al desarrollador a través del explorador predeterminado del sistema actual. Esta opción está deshabilitada de forma predeterminada.