Configure autenticação sem certificado com a Microsoft. Identity.Web

Este artigo mostra-lhe como configurar a autenticação sem certificado para que a sua aplicação se autentique com o Microsoft Entra ID sem gerir certificados ou segredos do cliente. A sua aplicação utiliza uma Credencial de Identidade Federada (FIC) apoiada por uma Identidade Gerida do Azure para obter tokens, o que elimina a rotação de credenciais, reduz a expansão secreta e simplifica as implementações do Azure.

Microsoft. O Identity.Web suporta autenticação sem certificado através do tipo fonte de credencial SignedAssertionFromManagedIdentity, disponível na versão 2.12.0 e posteriores.


Compreender autenticação sem certificado

Esta secção explica como funciona a autenticação sem certificado e quando a utilizar.

Tradicionalmente, aplicações cliente confidenciais provam a sua identidade ao Microsoft Entra ID apresentando um segredo do cliente ou um certificado. Ambas as abordagens exigem que gere o ciclo de vida das credenciais—rodar chaves antes de expirarem, renovar certificados e armazená-las com segurança.

As Credenciais de Identidade Federada (FIC) alteram este modelo. Com o FIC, configura uma relação de confiança entre o registo da sua aplicação e uma Identidade Gerida. Quando a sua candidatura precisa de autenticação:

  1. Microsoft.Identity.Web solicita um token do endpoint de Identidade Gerida no host do Azure.
  2. A biblioteca utiliza o token de Identidade Gerida como uma asserção assinada para autenticar com o Microsoft Entra ID.
  3. O Microsoft Entra ID valida a afirmação assinada contra a configuração federada de credenciais no registo da aplicação.
  4. O Microsoft Entra ID emite um token de acesso para o recurso solicitado.

O resultado é uma implementação totalmente livre de credenciais, onde não existem segredos ou certificados na sua configuração, código ou variáveis de ambiente.

Escolha a abordagem de autenticação correta

A tabela seguinte ajuda-o a decidir quando a autenticação sem certificado é a escolha certa.

Scenario Abordagem recomendada
A aplicação corre no Azure e não quer qualquer gestão de credenciais Sem necessidade de certificado com FIC
A aplicação corre no Azure mas precisa de oferecer suporte a uma solução local Credenciais baseadas em certificados com FIC como principal
A aplicação corre fora do Azure (on-premises, outras clouds) Certificados ou segredos do cliente
Desenvolvimento e testes em máquinas locais Segredos do cliente ou certificado de uma loja local

Pré-requisitos

Verifique se possui os seguintes recursos e ferramentas antes de começar:

  • Uma subscrição Azure. Se não tiveres, cria uma conta gratuita.
  • Um registo de aplicação em Microsoft Entra ID com as permissões de API necessárias para o seu cenário.
  • Uma Identidade Gerida em Azure — seja atribuída pelo sistema ao seu recurso de computação ou uma Identidade Gerida autónoma atribuída pelo utilizador.
  • Microsoft. Identity.Web versão 2.12.0 ou posterior instalada no seu projeto.
  • Um recurso computacional Azure que suporta Identidade Gerida, como Serviço de Aplicações do Azure, Azure Kubernetes Service (AKS), Azure Container Apps ou Máquinas Virtuais do Azure.

Passo 1: Criar ou identificar uma Identidade Gerida

Pode usar uma Identidade Gerida atribuída pelo próprio sistema ou pelo utilizador. Se ainda não criaste um, segue as instruções do teu cenário.

Opção A: Usar uma Identidade Gerida atribuída pelo sistema

As Identidades Geridas atribuídas ao sistema estão ligadas ao ciclo de vida de um recurso Azure. Quando ativas uma identidade atribuída pelo sistema num recurso como um App Service, o Azure cria automaticamente uma identidade.

  1. No portal Azure, navegue até ao seu recurso de computação (por exemplo, o seu Serviço de Aplicações).
  2. Selecione Identidade no menu de navegação à esquerda.
  3. Na guia Sistema atribuído, defina Estado como Ligado.
  4. Seleciona Guardar e confirma a ação.
  5. Depois de criada a identidade, copie o ID do Objeto (principal). Precisas deste valor ao configurar a credencial federada.

Opção B: Criar uma Identidade Gerida atribuída a um utilizador

As Identidades Geridas atribuídas pelo utilizador são recursos Azure autónomos que pode atribuir a um ou mais recursos de computação.

  1. No portal Azure, procure por Managed Identities e selecione-o.
  2. Selecione Criar.
  3. Escolha a sua Subscrição, Grupo de Recursos, Região e insira um Nome para a identidade.
  4. Selecione Rever + criar e, em seguida , Criar.
  5. Após a conclusão da implementação, abra o novo recurso de Identidade Gerida.
  6. Copie o ID do Cliente da página de Visão Geral . Precisa deste valor para a configuração da sua aplicação.

Passo 2: Configurar uma credencial de Identidade Federada no portal Azure

Uma Credencial de Identidade Federada estabelece uma relação de confiança entre o registo da sua aplicação e a Identidade Gerida. Siga estes passos para criar um:

  1. No portal Azure, vá a Microsoft Entra ID>Registos de aplicações.

  2. Selecione o registo da aplicação que a sua candidatura utiliza.

  3. No menu de navegação à esquerda, selecione Certificados e segredos.

  4. Selecione o separador Credenciais federadas.

  5. Selecione Adicionar credencial.

  6. No cenário de credencial federada, selecione chaves geridas pelo cliente ou Outro emissor (as opções disponíveis dependem da versão do seu portal).

  7. Configure os seguintes campos:

    Campo Valor
    Emissor https://login.microsoftonline.com/{tenant-id}/v2.0 — Substitua {tenant-id} pelo seu ID de inquilino Microsoft Entra.
    Identificador do assunto O ID do Objeto (principal) da Identidade Gerida. Para identidade atribuída pelo sistema, localize isto na página de Identidade do recurso. Para o utilizador atribuído, encontre isto na página de Visão Geral da Identidade Gerida, em Principal ID.
    Nome Um nome descritivo, por exemplo fic-managed-identity-prod.
    Audiência api://AzureADTokenExchange (o valor padrão).
  8. Selecione Adicionar.

Importante

O identificador do Sujeito deve corresponder exatamente ao ID do Objeto (principal) da Identidade Gerida. Uma incompatibilidade faz com que a autenticação falhe com um AADSTS70021 erro.

Configure uma credencial de Identidade Federada com CLI do Azure

Alternativamente, crie a credencial federada com a CLI do Azure. O comando seguinte cria uma credencial no registo da sua aplicação:

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"
    }'

URLs dos emissores pelo serviço Azure

A URL do emissor na credencial federada depende do serviço Azure que hospeda a sua aplicação:

Serviço do Azure URL do emissor
Serviço de Aplicações do Azure / Funções do Azure https://login.microsoftonline.com/{tenant-id}/v2.0
Azure Container Apps https://login.microsoftonline.com/{tenant-id}/v2.0
Serviço de Kubernetes do Azure (AKS) O URL do emissor OIDC para o seu cluster pode ser recuperado com az aks show --query oidcIssuerProfile.issuerUrl
Máquinas Virtuais do Azure https://login.microsoftonline.com/{tenant-id}/v2.0

Formato do identificador de assunto

O formato do identificador de sujeito depende do tipo de Identidade Gerida:

Identidade Gerida Atribuída pelo Sistema — Use o ID do Objeto (principal) da página de Identidade do recurso. Isto é um valor GUID, por exemplo, a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Identidade Gerida atribuída pelo Utilizador — Use o ID Principal (também chamado ID de Objeto) na página de Visão Geral do recurso de Identidade Gerida. Isto também é um valor GUID.

Observação

Para AKS com identidade de carga de trabalho, o identificador de sujeito utiliza um formato diferente: system:serviceaccount:{namespace}:{service-account-name}. Este valor deve corresponder à conta de serviço Kubernetes que o seu pod utiliza.


Passo 3: Configure a sua aplicação

Atualize o appsettings.json

Adiciona a ClientCredentials secção à tua AzureAd configuração. Defina o SourceType para SignedAssertionFromManagedIdentity:

Para Identidade Gerida atribuída pelo utilizador

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

Substitua os seguintes espaços reservados:

Placeholder Descrição
YOUR_TENANT_ID O seu ID de inquilino Microsoft Entra.
YOUR_CLIENT_ID O ID da aplicação (cliente) do registo da sua aplicação.
USER_ASSIGNED_MSI_CLIENT_ID O ID do Cliente da Identidade Gerida atribuída pelo utilizador (da página de Visão Geral da identidade).

Para Identidade Gerida atribuída ao sistema

Ao utilizar uma Identidade Gerida atribuída pelo sistema, omita a propriedade ManagedIdentityClientId. Microsoft. O Identity.Web utiliza automaticamente a identidade atribuída pelo sistema ao anfitrião:

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

Registo de serviços em Program.cs

Não são necessárias alterações especiais de código na configuração de arranque. Os métodos de registo padrão do Microsoft.Identity.Web leem automaticamente a secção ClientCredentials.

O exemplo seguinte regista autenticação para uma aplicação web que faz login com utilizadores e chama APIs a jusante:

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

O exemplo seguinte regista autenticação para uma API web que invoca APIs downstream:

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

O exemplo seguinte regista autenticação para uma aplicação daemon sem interação do utilizador:

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

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

Microsoft. O Identity.Web deteta o tipo de origem SignedAssertionFromManagedIdentity e gere a troca de tokens de forma transparente.


Compare a Identidade Gerida atribuída pelo sistema e atribuída pelo utilizador

Escolha o tipo de Identidade Gerida que melhor se adequa à sua arquitetura. As secções seguintes descrevem os trade-offs.

Identidade Gerida Atribuída ao Sistema

Uma identidade atribuída ao sistema é criada e eliminada automaticamente com o recurso Azure ao qual pertence.

Vantagens:

  • Não há um recurso separado para gerir — o ciclo de vida da identidade corresponde ao recurso de computação.
  • Configuração mais simples para implementações de recurso único.
  • Na configuração, ManagedIdentityClientId não é necessário.

Considerations:

  • Não podes partilhar a identidade entre vários recursos.
  • Se eliminar e recriar o recurso, a identidade muda — deve atualizar a Credencial de Identidade Federada.

Melhor para: Implementações de instância única onde um recurso de computação corresponde a um registo de uma aplicação.

Identidade gerenciada atribuída pelo usuário

Uma identidade atribuída pelo utilizador é um recurso Azure autónomo com o seu próprio ciclo de vida.

Vantagens:

  • Partilhe uma única identidade entre múltiplos recursos de computação (por exemplo, múltiplas instâncias de Serviços de Aplicações em diferentes regiões).
  • A identidade persiste independentemente do ciclo de vida dos recursos de computação.
  • Pré-criar e pré-configurar antes de implementar o recurso de computação.

Considerations:

  • Um recurso adicional do Azure para gerir.
  • Tem de especificar o ManagedIdentityClientId na configuração.

Melhor para: Implementações multi-instância ou multi-região, padrões de implementação azul-esverdeados e cenários onde os recursos computacionais são frequentemente recriados.


Implementar nos serviços de computação Azure

Depois de configurar a sua aplicação, implemente-a num serviço de computação do Azure que suporte Managed Identity.

Serviço de Aplicações do Azure

  1. Ative a Identidade Gerida no seu Serviço de Aplicação (ver Passo 1).

  2. Implemente a sua aplicação no App Service usando o método preferido (Visual Studio, CLI do Azure, GitHub Actions).

  3. Assegure que a AzureAd secção na sua configuração implementada corresponde às definições do Passo 3.

  4. Se usar uma Identidade Gerida atribuída pelo utilizador, atribui-a ao Serviço de Aplicações:

    az webapp identity assign \
      --resource-group <resource-group> \
      --name <app-service-name> \
      --identities <managed-identity-resource-id>
    
  5. Reinicie o Serviço de Aplicação para captar a atribuição de identidade.

Azure Kubernetes service (AKS)

Para AKS, use a identidade da carga de trabalho para associar uma conta de serviço Kubernetes à Identidade Gerida. Conclua as seguintes etapas:

  1. Ative a funcionalidade de identidade da carga de trabalho no seu cluster AKS:

    az aks update \
      --resource-group <resource-group> \
      --name <aks-cluster-name> \
      --enable-oidc-issuer \
      --enable-workload-identity
    
  2. Crie uma conta de serviço Kubernetes anotada com o ID do cliente de Identidade Gerida:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: my-app-sa
      namespace: default
      annotations:
        azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"
    
  3. Crie uma credencial federada que ligue o emissor OIDC do AKS à Identidade Gerida.

  4. Configure o seu pod para usar a conta de serviço:

    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. Desdobre o pod. O webhook de identidade de carga de trabalho injeta as variáveis de ambiente necessárias para o endpoint do token de Identidade Gerida.

Azure Container Apps

  1. Crie ou atualize a sua Aplicação de Contêiner com uma Identidade Gerida:

    az containerapp identity assign \
      --resource-group <resource-group> \
      --name <container-app-name> \
      --user-assigned <managed-identity-resource-id>
    
  2. Implemente a imagem do seu container com a configuração adequada AzureAd.

  3. O endpoint do token de Identidade Gerida está automaticamente disponível dentro do contentor.


Migrar de certificados para autenticação sem certificado

Se a sua aplicação utilizar atualmente autenticação baseada em certificado, pode migrar para autenticação sem certificado com alterações mínimas na configuração.

Completar os passos de migração

  1. Crie uma Identidade Gerida para o seu recurso computacional Azure (ver Step 1).

  2. Adicione uma Credencial de Identidade Federada ao registo da sua candidatura (ver Passo 2).

  3. Atualiza a tua configuração para adicionar a SignedAssertionFromManagedIdentity credencial. Pode manter a credencial de certificado existente como plano B durante a migração:

    {
      "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 tenta as fontes de credenciais por ordem. Ao executar na Azure, a primeira credencial (SignedAssertionFromManagedIdentity) é bem-sucedida. Se houver falhas (por exemplo, durante o desenvolvimento local), a biblioteca utiliza o certificado como recurso alternativo.

  4. Implemente e valide num ambiente de teste antes de mover para produção.

  5. Remova a credencial de certificado da configuração depois de confirmar que a autenticação sem certificado funciona em produção.

  6. Apaga o certificado da Azure Key Vault e do registo da aplicação quando já não for necessário.

Compare a configuração antes e depois

Os exemplos seguintes mostram a mudança de configuração da autenticação baseada em certificados para a autenticação sem certificado.

Antes (baseado em certificados):

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

Depois (sem certificado):

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

Solucionar erros comuns

Use as seguintes orientações para diagnosticar e resolver problemas com a autenticação sem certificado.

AADSTS70021: Não foi encontrado registo de identidade federada correspondente

Causa: O identificador de assunto na Credencial de Identidade Federada não corresponde ao ID do objeto (principal) da Identidade Gerida.

Resolution:

  1. No portal Azure, navegue até ao recurso de Identidade Gerida e copie o Principal ID (também chamado de ID de Objeto) da página Overview.
  2. Navegue até ao registo > da sua aplicação Certificados & segredos>Credenciais federadas.
  3. Verifique se o campo Identificador de Sujeito corresponde exatamente ao ID principal.
  4. Se os valores não coincidirem, apague a credencial e recrie-a com o identificador correto do sujeito.

AADSTS700024: A declaração do cliente não está dentro do seu período válido

Causa: O token de Identidade Gerida usado como asserção assinada expirou ou o relógio do sistema está desajustado.

Resolution:

  • Verifica se o relógio do sistema no teu recurso Azure está correto.
  • Reinicie a aplicação para forçar um novo pedido de token de Identidade Gerida.
  • Se correr num container, certifique-se de que o relógio do container está sincronizado com o anfitrião.

ManagedIdentityException: Endpoint de Identidade Gerida não disponível

Cause: A aplicação não consegue aceder ao Serviço de Metadados de Instância Azure (IMDS) nem ao endpoint do token de Identidade Gerida.

Resolution:

  • Confirme que a aplicação está a correr num recurso de computação do Azure que suporta Identidade Gerida.
  • Verifique se a Identidade Gerida está ativada e atribuída ao recurso de computação.
  • Para o AKS, verifique se o webhook de identidade de carga de trabalho está em execução e se o pod tem a anotação correta da conta de serviço.
  • Para o desenvolvimento local, este erro é esperado. Utilize uma fonte de credencial de reserva (ver Passos de migração).

AADSTS700016: Aplicação não encontrada no diretório

Causa: O ClientId na sua configuração não corresponde a um registo válido de aplicação no tenant especificado.

Resolution:

  • Verifique se corresponde ClientId ao ID da Aplicação (cliente) do registo da sua aplicação.
  • Verifica se o TenantId corresponde ao inquilino onde a aplicação está registada.

Ativar o registo de depuração

Causa: A ordem da fonte das credenciais ou a incompatibilidade de configuração pode fazer com que a biblioteca ignore a credencial FIC.

Resolution:

  1. Ative o login na Microsoft. Identity.Web para ver os passos detalhados de aquisição de tokens. O seguinte código configura o registo ao nível de depuração para as bibliotecas de identidade:

    builder.Services.AddLogging(logging =>
    {
        logging.AddConsole();
        logging.SetMinimumLevel(LogLevel.Debug);
        logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
    });
    
  2. Verifique os registos para ver mensagens sobre qual a fonte de credencial foi utilizada pela biblioteca e quaisquer erros reportados.

Identidade gerida atribuída pelo utilizador não detetada

Causa: Quando múltiplas Identidades Geridas atribuídas pelo utilizador são atribuídas a um recurso de computação, a biblioteca pode usar a errada se ManagedIdentityClientId não for especificada.

Resolution:

  • Especifique sempre a ManagedIdentityClientId propriedade quando usar uma Identidade Gerida atribuída pelo utilizador.
  • Verifica se o ID do cliente corresponde à identidade para a qual configuraste a Credencial de Identidade Federada.

Analise os benefícios de segurança

A autenticação sem certificado com FIC oferece vantagens significativas de segurança em relação às abordagens tradicionais baseadas em credenciais:

Sem segredos para revelar

Como não existem ficheiros de certificação, palavras-passe PFX ou segredos de cliente nos artefactos de configuração ou implementação, não há nada que um atacante possa extrair. Mesmo que um atacante obtenha acesso de leitura aos seus ficheiros de configuração, não pode fazer-se passar pela sua aplicação fora do Azure.

Sem rotação de credenciais

Os tokens de Identidade Gerida são de curta duração e são automaticamente atualizados pela plataforma Azure. Não precisa de implementar calendários de rotação, monitorizar datas de validade ou coordenar atualizações de credenciais entre implementações.

Superfície de ataque reduzida

O endpoint do token de Identidade Gerida só é acessível a partir do recurso específico do Azure ao qual a identidade está atribuída. Um atacante não pode usar a credencial de um host, rede ou ambiente cloud diferente.

Simplificação da conformidade

Sem credenciais duradouras, elimina-se várias categorias de preocupações de conformidade:

  • Sem segredos armazenados no controlo de versão, variáveis de ambiente ou ficheiros de configuração.
  • Nenhum material de chave para auditar, rodar ou revogar.
  • Não há infraestrutura de certificados (CA, processos de renovação) para manter.

Defesa em profundidade

Combine a autenticação sem certificado com outras funcionalidades de segurança do Azure para proteção em camadas:

  • Azure RBAC: Controla quais identidades podem aceder a que recursos.
  • Acesso Condicional: Aplicar políticas baseadas no risco de identidade, localização e estado do dispositivo.
  • Endpoints privados: Restringem o acesso à rede a recursos do Azure.
  • Microsoft Defender para a Cloud: Monitorizar padrões de autenticação suspeitos.