Configure la autenticación sin certificados con Microsoft. Identity.Web

En este artículo se muestra cómo configurar la autenticación sin certificados para que la aplicación se autentique con Microsoft Entra ID sin administrar certificados ni secretos de cliente. La aplicación usa una credencial de identidad federada (FIC) respaldada por una identidad administrada Azure para obtener tokens, lo que elimina la rotación de credenciales, reduce la expansión de secretos y simplifica las implementaciones de Azure.

Microsoft. Identity.Web admite la autenticación sin certificados a través del tipo de origen de credenciales de SignedAssertionFromManagedIdentity, disponible en la versión 2.12.0 y posteriores.

Descripción de la autenticación sin certificados

En esta sección se explica cómo funciona la autenticación sin certificados y cuándo usarla.

Tradicionalmente, las aplicaciones cliente confidenciales demuestran su identidad para Microsoft Entra ID mediante la presentación de un secreto de cliente o un certificado. Ambos enfoques requieren administrar el ciclo de vida de las credenciales: rotar secretos antes de que expiren, renovar certificados y almacenarlos de forma segura.

Las credenciales de identidad federada (FIC) cambian este modelo. Con FIC, configura una relación de confianza entre el registro de la aplicación y una identidad administrada. Cuando la aplicación necesita autenticarse:

1. Microsoft.Identity.Web solicita un token desde el punto de conexión de la Identidad Administrada en el host de Azure.
2. La biblioteca usa el token de identidad administrada como aserción firmada para autenticarse con Microsoft Entra ID.
3. Microsoft Entra ID valida la aserción firmada contra la configuración de credenciales federadas en el registro de la aplicación.
4. Microsoft Entra ID emite un token de acceso para el recurso solicitado.

El resultado es una implementación totalmente sin credenciales en la que no existen secretos ni certificados en la configuración, el código o las variables de entorno.

Elección del enfoque de autenticación adecuado

La tabla siguiente le ayuda a decidir cuándo la autenticación sin certificado es la opción correcta.

Prerrequisitos

Compruebe que tiene los siguientes recursos y herramientas antes de empezar:

• Una suscripción Azure. Si no tiene una, cree una cuenta gratuita.
• Un registro de aplicación en Microsoft Entra ID con los permisos de API necesarios para su contexto.
• Una Managed Identity en Azure, ya sea asignada por el sistema a su recurso de cómputo o una Managed Identity independiente asignada por el usuario.
• Microsoft. Identity.Web versión 2.12.0 o posterior instalada en el proyecto.
• Un recurso de proceso de Azure que admite identidad administrada, como Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps o Azure Virtual Machines.

Paso 1: Crear o identificar una identidad administrada

Puede usar una identidad administrada asignada por el sistema o asignada por el usuario. Si aún no ha creado uno, siga las instrucciones para su escenario.

Opción A: Usar una identidad administrada asignada por el sistema

Las identidades administradas asignadas por el sistema están vinculadas al ciclo de vida de un recurso de Azure. Al habilitar una identidad asignada por el sistema en un recurso como App Service, Azure crea automáticamente una identidad.

1. En el portal Azure, navegue hasta su recurso de cómputo (por ejemplo, su App Service).
2. Seleccione Identidad en el menú de navegación izquierdo.
3. En la pestaña Sistema asignado, establezca el estado en Activado.
4. Seleccione Guardar y confirme la acción.
5. Una vez creada la identidad, copie el identificador de objeto (principal). Necesita este valor al configurar la credencial federada.

Opción B: Crear una identidad administrada asignada por el usuario

Las identidades administradas asignadas por el usuario son recursos independientes Azure que puede asignar a uno o varios recursos de proceso.

1. En el portal Azure, busque Managed Identities y selecciónelo.
2. Selecciona Crear.
3. Elija la suscripción, el grupo de recursos, la región y escriba un nombre para la identidad.
4. Seleccione Revisar y crear y, a continuación, Crear.
5. Una vez completada la implementación, abra el nuevo recurso de identidad administrada.
6. Copie el identificador de cliente de la página Información general . Necesita este valor para la configuración de la aplicación.

Paso 2: Configuración de una credencial de identidad federada en el portal de Azure

Una credencial de identidad federada establece una relación de confianza entre el registro de la aplicación y la identidad administrada. Siga estos pasos para crear uno:

1. En el portal Azure, vaya a Microsoft Entra ID>Registros de aplicaciones.

2. Seleccione el registro de aplicaciones que usa la aplicación.

3. En el menú de navegación izquierdo, seleccione Certificados y secretos.

4. Seleccione la pestaña Credenciales federadas .

5. Seleccione Agregar credencial.

6. En Escenario de credenciales federadas, seleccione Claves administradas por el cliente u Otro emisor (las opciones disponibles dependen de la versión del portal).

7. Configure los campos siguientes:

   Campo	Importancia
   Emisor	https://login.microsoftonline.com/{tenant-id}/v2.0: reemplace {tenant-id} por el identificador de inquilino de Microsoft Entra.
   Identificador de sujeto	Identificador de objeto (entidad principal) de la identidad administrada. En el caso de asignados por el sistema, busque esto en la página de Identidad del recurso. Para los usuarios asignados, busque esto en la página de Información general de la Identidad Administrada en Id. de entidad principal.
   Nombre	Un nombre descriptivo, por ejemplo fic-managed-identity-prod, .
   Audiencia	api://AzureADTokenExchange (el valor predeterminado).

8. Selecciona Agregar.

Configuración de una credencial de identidad federada con CLI de Azure

Como alternativa, cree la credencial federada con el CLI de Azure. El comando siguiente crea una credencial en el registro de la aplicación:

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

Direcciones URL del emisor por servicio de Azure

La dirección URL del emisor de la credencial federada depende del servicio Azure que hospeda la aplicación:

Formato de identificador del sujeto

El formato del identificador del firmante depende del tipo de identidad administrada:

Identidad administrada asignada por el sistema — Use el ID de objeto (entidad de seguridad) de la página Identidad del recurso. Se trata de un valor GUID, por ejemplo a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Identidad administrada asignada por el usuario: use el ID principal (también denominado Id. de objeto) desde la página Información general del recurso de identidad administrada. También es un valor GUID.

Paso 3: Configuración de la aplicación

Actualizar appsettings.json

Agregue la ClientCredentials sección a la AzureAd configuración. Establezca el SourceType en SignedAssertionFromManagedIdentity:

Para la identidad administrada asignada por el usuario

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Reemplace los siguientes marcadores de posición:

Para una identidad administrada asignada por el sistema

Al usar una identidad administrada asignada por el sistema, omita la ManagedIdentityClientId propiedad . Microsoft. Identity.Web usa automáticamente la identidad asignada por el sistema del host:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Registro de servicios en Program.cs

No se requieren cambios de código especiales en la configuración de inicio. Los métodos de registro estándar de Microsoft.Identity.Web leen automáticamente la sección ClientCredentials.

En el ejemplo siguiente se registra la autenticación de una aplicación web que inicia sesión para los usuarios y llama a las API subordinadas.

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

En el ejemplo siguiente se registra la autenticación de una API web que llama a las API de bajada:

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

En el ejemplo siguiente, se registra la autenticación para una aplicación de daemon sin interacción del usuario.

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web detecta el tipo de origen SignedAssertionFromManagedIdentity y controla el intercambio de tokens de forma transparente.

Comparación entre la Identidad Administrada asignada por el sistema y por el usuario

Elija el tipo de identidad administrada que mejor se adapte a la arquitectura. En las secciones siguientes se describen los inconvenientes.

Identidad administrada asignada por el sistema

Se crea y elimina automáticamente una identidad asignada por el sistema con el recurso Azure al que pertenece.

Ventajas:

• No hay recurso independiente para administrar; el ciclo de vida de la identidad coincide con el recurso de cómputo.
• Configuración más sencilla para implementaciones de recursos únicos.
• Ningún ManagedIdentityClientId es necesario en la configuración.

Considerations:

• No se puede compartir la identidad entre varios recursos.
• Si elimina y vuelve a crear el recurso, la identidad cambia; debe actualizar la credencial de identidad federada.

Lo mejor para: Implementaciones de instancia única optimizadas para que un recurso de cómputo se asigne a un registro de aplicación.

Identidad administrada asignada por el usuario

Una identidad asignada por el usuario es un recurso independiente Azure con su propio ciclo de vida.

Ventajas:

• Comparta una sola identidad en varios recursos de proceso (por ejemplo, varias instancias de App Service en regiones diferentes).
• La identidad persiste independientemente del ciclo de vida de los recursos de proceso.
• Precrear y preconfigurar antes de implementar el recurso de cómputo.

Considerations:

• Un recurso adicional de Azure para administrar.
• Debe especificar la configuración ManagedIdentityClientId.

Lo mejor para: Implementaciones de varias instancias o de varias regiones, patrones de implementación azul-verde y escenarios en los que los recursos de proceso se vuelven a crear con frecuencia.

Despliegue en los servicios de proceso de Azure

Después de configurar la aplicación, impleméntela en un servicio de proceso de Azure que admita identidad administrada.

Azure App Service

1. Habilite la identidad administrada en App Service (consulte el paso 1).

2. Implemente la aplicación en App Service mediante el método preferido (Visual Studio, CLI de Azure, Acciones de GitHub).

3. Asegúrese de que la AzureAd sección de la configuración implementada coincide con las opciones del paso 3.

4. Si usa una identidad administrada asignada por el usuario, asígnela a App Service:

   az webapp identity assign \
     --resource-group <resource-group> \
     --name <app-service-name> \
     --identities <managed-identity-resource-id>
   

5. Reinicie App Service para seleccionar la asignación de identidad.

Azure Kubernetes Service (AKS)

Para AKS, use la identidad de carga de trabajo para asociar una cuenta de servicio de Kubernetes a la identidad administrada. Complete los pasos siguientes:

1. Habilite la característica de identidad de carga de trabajo en el clúster de AKS:

   az aks update \
     --resource-group <resource-group> \
     --name <aks-cluster-name> \
     --enable-oidc-issuer \
     --enable-workload-identity
   

2. Cree una cuenta de servicio de Kubernetes anotada con el identificador de cliente de identidad administrada:

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-app-sa
     namespace: default
     annotations:
       azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"
   

3. Cree una credencial federada que vincule el emisor de OIDC de AKS a la identidad administrada.

4. Configure el pod para usar la cuenta de servicio:

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-app
     namespace: default
     labels:
       azure.workload.identity/use: "true"
   spec:
     serviceAccountName: my-app-sa
     containers:
       - name: my-app
         image: <your-container-image>
   

5. Despliegue el pod. El webhook de identidad de carga de trabajo inserta las variables de entorno necesarias para el punto de conexión del token de identidad administrada.

Azure Container Apps (Aplicaciones de Contenedores de Azure)

1. Crea o actualiza tu aplicación de contenedor con una identidad administrada:

   az containerapp identity assign \
     --resource-group <resource-group> \
     --name <container-app-name> \
     --user-assigned <managed-identity-resource-id>
   

2. Despliegue la imagen de contenedor con la configuración adecuada AzureAd .

3. El punto de conexión del token de identidad administrada está disponible automáticamente dentro del contenedor.

Migración de certificados a autenticación sin certificados

Si la aplicación usa actualmente la autenticación basada en certificados, puede migrar a la autenticación sin certificados con cambios mínimos de configuración.

Completar los pasos de migración

1. Crear una identidad administrada para el recurso de proceso de Azure (consulte Step 1).

2. Agregue una credencial de identidad federada al registro de la aplicación (consulte el paso 2).

3. Actualice la configuración para agregar la SignedAssertionFromManagedIdentity credencial. Puede mantener la credencial de certificado existente como reserva durante la migración:

   {
     "AzureAd": {
       "Instance": "https://login.microsoftonline.com/",
       "TenantId": "YOUR_TENANT_ID",
       "ClientId": "YOUR_CLIENT_ID",
       "ClientCredentials": [
         {
           "SourceType": "SignedAssertionFromManagedIdentity",
           "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
         },
         {
           "SourceType": "KeyVault",
           "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
           "KeyVaultCertificateName": "your-cert-name"
         }
       ]
     }
   }
   

   Microsoft.Identity.Web intenta las fuentes de credenciales en orden. Cuando se ejecuta en Azure, la primera credencial (SignedAssertionFromManagedIdentity) tiene éxito. Si falla (por ejemplo, durante el desarrollo local), la biblioteca recurre al certificado.

4. Implemente y valide en un entorno de ensayo antes de aplicarlo a producción.

5. Quite la credencial de certificado de la configuración después de confirmar que la autenticación sin certificado funciona en producción.

6. Delete el certificado desde Azure Key Vault y el registro de la aplicación cuando ya no sea necesario.

Comparar antes y después de la configuración

En los ejemplos siguientes se muestra el cambio de configuración de la autenticación basada en certificados a sin certificados.

Antes (basado en certificados):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Después (sin certificado):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Solución de errores comunes

Use las instrucciones siguientes para diagnosticar y resolver problemas con la autenticación sin certificados.

AADSTS70021: no se encontró ningún registro de identidad federado coincidente

Causa: El identificador de sujeto en la credencial de identidad federada no coincide con el identificador de objeto (principal) de la entidad administrada.

Resolución:

1. En el portal de Azure, vaya al recurso Identidad administrada y copie el Id. deprincipal (también denominado Id. de objeto) desde la página Overview.
2. Vaya a >Certificados y secretos>Credenciales federadas en el registro de su aplicación.
3. Compruebe que el campo Identificador del sujeto coincide exactamente con el ID del principal.
4. Si los valores no coinciden, elimine la credencial y vuelva a crearla con el identificador de asunto correcto.

AADSTS700024: La aserción del cliente no se encuentra dentro de su intervalo de tiempo válido

Causa: El token de identidad administrada que se usa como aserción firmada ha expirado o el reloj del sistema está sesgado.

Resolución:

• Compruebe que el reloj del sistema de su recurso de Azure es preciso.
• Reinicie la aplicación para forzar una nueva solicitud de token de identidad administrada.
• Si se ejecuta en un contenedor, asegúrese de que el reloj del contenedor esté sincronizado con el host.

ManagedIdentityException: Punto de conexión de identidad administrada no disponible

Cause: La aplicación no puede acceder al servicio de metadatos de instancia (IMDS) de Azure ni al punto de conexión del token de identidad administrada.

Resolución:

• Confirme que la aplicación se está ejecutando en un recurso de proceso de Azure que admita identidad administrada.
• Compruebe que la Identidad Administrada está habilitada y asignada al recurso de computación.
• Para AKS, compruebe que el webhook de identidad de carga de trabajo se está ejecutando y que el pod tenga la anotación correcta de la cuenta de servicio.
• Para el desarrollo local, se espera este error. Utilice una fuente de credenciales alternativa (consulte Pasos de migración).

AADSTS700016: no se encuentra la aplicación en el directorio

Causa: El ClientId de su configuración no coincide con un registro de aplicación válido en el inquilino especificado.

Resolución:

• Compruebe que el ClientId coincide con el identificador de aplicación (cliente) del registro de la aplicación.
• Compruebe que TenantId coincide con el inquilino donde está registrada la aplicación.

Habilitar el registro de depuración

Causa: El orden de origen de credenciales o la falta de coincidencia de configuración pueden provocar que la biblioteca omita la credencial FIC.

Resolución:

1. Habilite el registro en Microsoft. Identity.Web para ver los pasos detallados de adquisición de tokens. El código siguiente configura el registro de nivel de depuración para las bibliotecas de identidad:

   builder.Services.AddLogging(logging =>
   {
       logging.AddConsole();
       logging.SetMinimumLevel(LogLevel.Debug);
       logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
   });
   

2. Revise los registros en busca de mensajes acerca de cuál fuente de credenciales intentó utilizar la biblioteca y cualquier error devuelto.

Identidad administrada asignada por el usuario no reconocida

Causa: Cuando se asignan varias identidades administradas asignadas por el usuario a un recurso de proceso, la biblioteca podría usar el incorrecto si ManagedIdentityClientId no se especifica.

Resolución:

• Especifique siempre la ManagedIdentityClientId propiedad cuando use una identidad administrada asignada por el usuario.
• Compruebe que el identificador de cliente coincide con la identidad para la que configuró la credencial de identidad federada.

Revisión de las ventajas de seguridad

La autenticación sin certificados con FIC proporciona importantes ventajas de seguridad sobre los enfoques tradicionales basados en credenciales:

Sin secretos que se van a filtrar

Dado que no existen archivos de certificado, contraseñas PFX ni secretos de cliente en los artefactos de configuración o implementación, no hay nada para que un atacante extraiga. Incluso si un atacante obtiene acceso de lectura a los archivos de configuración, no puede suplantar la aplicación desde fuera de Azure.

Sin rotación de credenciales

Los tokens de identidad administrada son de corta duración y se actualizan automáticamente mediante la plataforma Azure. No es necesario implementar programaciones de rotación, supervisar las fechas de expiración ni coordinar las actualizaciones de credenciales entre implementaciones.

Superficie de ataque reducida

El punto de conexión del token de identidad administrada solo es accesible desde el recurso de Azure específico al que está asignada la identidad. Un atacante no puede usar la credencial de un host, una red o un entorno en la nube diferentes.

Simplificación del cumplimiento

Sin credenciales de larga duración, elimina varias categorías de problemas de cumplimiento:

• No hay secretos almacenados en el control de código fuente, las variables de entorno ni los archivos de configuración.
• No hay material clave para auditar, rotar ni revocar.
• No hay ninguna infraestructura de certificados (CA, procesos de renovación) que se mantenga.

Defensa en profundidad

Combine la autenticación sin certificados con otras características de seguridad de Azure para la protección por capas:

• Azure RBAC: controlar qué identidades pueden acceder a los recursos.
• Acceso condicional: aplique directivas basadas en el riesgo de identidad, la ubicación y el estado del dispositivo.
• Puntos de conexión privados: Restringen el acceso de red a los recursos de Azure.
• Microsoft Defender para la nube: Supervisión de patrones de autenticación sospechosos.

Contenido relacionado

• Introducción a las credenciales
• Certificados
• Secretos de cliente
• Documentación de Identidades Gestionadas de Azure
• Documentación de credenciales de identidad federada
• Repositorio GitHub de Microsoft.Identity.Web