Aumentar a resiliência da autenticação e autorização em aplicativos daemon desenvolvidos por você

Saiba como usar a plataforma de identidade da Microsoft e o Microsoft Entra ID para aumentar a resiliência de aplicativos daemon. Encontre informações sobre processos em segundo plano, serviços, aplicativos de servidor para servidor e aplicativos sem usuários.

Confira 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.

A daemon application making a call to Microsoft identity platform.

Identidades gerenciadas dos recursos do Azure

Se você estiver compilando 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 expiração do certificado, rotação ou confiança.

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. Seu aplicativo é executado durante a aquisição de novos tokens.

As identidades gerenciadas usam pontos de extremidade regionais, que ajudam a evitar falhas fora da região com a consolidação de dependências de serviço. Os pontos de extremidade regionais ajudam a manter o tráfego em uma área geográfica. Por exemplo, se seu recurso Azure está em WestUS2, todo o tráfego permanece em WestUS2.

Biblioteca de Autenticação da Microsoft

Se você desenvolver aplicativos Daemon e não usar identidades gerenciadas, use a MSAL (Biblioteca de Autenticação da Microsoft) para autenticação e autorização. A MSAL facilita o processo de fornecimento de credenciais do cliente. Por exemplo, seu aplicativo não precisa criar e assinar declarações de token Web JSON com credenciais baseadas em certificado.

Consulte Visão geral da MSAL (Biblioteca de Autenticação da Microsoft)

Microsoft.Identity.Web para desenvolvedores .NET

Se você desenvolver aplicativos Daemon em ASP.NET Core, use a biblioteca Microsoft.Identity.Web para facilitar a autorização. Ela inclui várias estratégias de cache de token distribuído para aplicativos distribuídos que podem ser executados em várias regiões.

Saiba mais:

Cache e armazenar tokens

Se você não usar a MSAL para autenticação e autorização, haverá práticas recomendadas para armazenar tokens em cache e armazenar tokens. A MSAL implementa e segue essas práticas recomendadas.

Um aplicativo adquire tokens de um provedor de identidade (IdP) para autorizar o aplicativo a chamar APIs protegidas. Quando o aplicativo recebe tokens, a resposta com os tokens contém uma propriedade expires\_in que informa ao aplicativo por quanto tempo armazenar em cache e reutilizar o token. Verifique se os aplicativos usam a propriedade expires\_inpara determinar o tempo de vida do token. Confirme se o aplicativo não tenta decodificar um token de acesso à API. O uso do token armazenado em cache impede o tráfego desnecessário entre um aplicativo e a plataforma de identidade da Microsoft. Os usuários permanecem conectados ao seu aplicativo durante o tempo de vida do token.

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

Há erros HTTP que afetam a resiliência. Se seu aplicativo receber um código de erro HTTP 429, Muitas Solicitações, 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 Retry-After expire. O erro 429 geralmente indica que o aplicativo não armazena em cache e reutiliza tokens corretamente.

HTTP 5xx

Quando um aplicativo recebe um código de erro HTTP 5x, ele não deve entrar em um loop de repetição rápido. Verifique se os aplicativos esperam até que o campo Retry-After expire. Caso nenhum cabeçalho “Retry-After” apareça, implemente uma nova tentativa de retirada exponencial com a primeira tentativa ocorrendo pelo menos 5 segundos após a resposta.

Quando uma solicitação atingir o tempo limite, os aplicativos não devem fazer uma nova tentativa imediatamente. Use a repetição de retirada exponencial citada anteriormente.

Próximas etapas