Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aprenda a usar a plataforma de identidade da Microsoft e o Microsoft Entra ID para aumentar a resiliência dos aplicativos daemon. Encontre informações sobre processos em segundo plano, serviços, aplicativos de servidor para servidor e aplicativos sem usuários.
Consulte O que é a plataforma de identidade da Microsoft?
O diagrama a seguir ilustra um aplicativo daemon fazendo uma chamada para a plataforma de identidade da Microsoft.
Identidades gerenciadas para recursos do Azure
Se você estiver criando aplicativos daemon no Microsoft Azure, use identidades gerenciadas para recursos do Azure, que lidam com segredos e credenciais. O recurso melhora a resiliência ao lidar com a expiração, rotação ou confiança do certificado.
Consulte O que são identidades gerenciadas para recursos do Azure?
As identidades gerenciadas usam tokens de acesso de longa duração e informações da plataforma de identidade da Microsoft para adquirir novos tokens antes que os tokens expirem. A sua aplicação corre enquanto adquire novos tokens.
As identidades geridas usam endpoints regionais, que ajudam a evitar falhas fora da região, consolidando dependências de serviço. Os pontos finais regionais ajudam a manter o tráfego numa área geográfica. Por exemplo, se o recurso do Azure estiver no WestUS2, todo o tráfego permanecerá no WestUS2.
Biblioteca de Autenticação da Microsoft
Se você desenvolver aplicativos daemon e não usar identidades gerenciadas, use a Biblioteca de Autenticação da Microsoft (MSAL) para autenticação e autorização. O MSAL facilita o processo de fornecimento de credenciais de cliente. Por exemplo, seu aplicativo não precisa criar e assinar asserções de token da Web JSON com credenciais baseadas em certificado.
Consulte Visão geral da Biblioteca de Autenticação da Microsoft (MSAL)
Microsoft.Identity.Web para desenvolvedores .NET
Se desenvolves aplicações daemon no ASP.NET Core, usa a biblioteca Microsoft.Identity.Web para facilitar a autorização. Inclui estratégias de cache de token distribuído para aplicações distribuídas que são executadas em várias regiões.
Saiba mais:
Guardar e armazenar tokens em cache
Se não utilizar o MSAL para autenticação e autorização, existem práticas recomendadas para cache e armazenamento de tokens. A MSAL implementa e segue estas práticas recomendadas.
Um aplicativo adquire tokens de um provedor de identidade (IdP) para autorizar o aplicativo a chamar APIs protegidas. Quando seu aplicativo recebe tokens, a resposta com os tokens contém uma expires\_in propriedade que informa ao aplicativo por quanto tempo armazenar em cache e reutilizar o token. Certifique-se de que os aplicativos usem a propriedade para determinar a vida útil do expires\_in token. Confirme se o aplicativo não tenta decodificar um token de acesso à API. O uso do token armazenado em cache evita o tráfego desnecessário entre um aplicativo e a plataforma de identidade da Microsoft. Os usuários estão conectados ao seu aplicativo durante o tempo de vida do token.
O sistema de autenticação de backup do Microsoft Entra ID fornece resiliência a aplicativos que usam protocolos e fluxos suportados. Para obter mais informações sobre os requisitos do aplicativo para se beneficiar da autenticação de backup, consulte Requisitos do aplicativo para o sistema de autenticação de backup.
Códigos de erro HTTP 429 e 5xx
Use as seções a seguir para saber mais sobre os códigos de erro HTTP 429 e 5xx
HTTP 429
Existem erros HTTP que afetam a resiliência. Se seu aplicativo receber um código de erro HTTP 429, Solicitações Demais, a plataforma de identidade da Microsoft está limitando suas solicitações, o que impede que seu aplicativo receba tokens. Certifique-se de que seus aplicativos não tentem adquirir um token até que o tempo no campo de resposta Repetir após expire. O erro 429 geralmente indica que o aplicativo não armazena em cache e reutiliza tokens corretamente.
HTTP 5xx
Se um aplicativo receber um código de erro HTTP 5x, o aplicativo não deverá entrar em um loop de repetição rápida. Certifique-se de que os aplicativos esperem até que o campo Repetir depois expire. Se a resposta não fornecer nenhum cabeçalho Retry-After, use uma nova tentativa usando o método de tentativas exponenciais, com a primeira nova tentativa a ocorrer pelo menos 5 segundos após a resposta.
Quando uma solicitação expira, verifique se os aplicativos não tentam novamente de imediato. Utilizar a estratégia de back-off exponencial mencionada anteriormente.