Cenário: Aplicativo daemon que chama APIs Web

  • Artigo

Esse cenário orientará você a criar um aplicativo daemon que chama APIs Web.

Visão geral

Seu aplicativo pode adquirir um token para chamar uma API Web em seu próprio nome (não em nome de um usuário). Esse cenário é útil para aplicativos daemon. Ele usa a concessão das credenciais de cliente padrão do OAuth 2.0.

Daemon apps

Alguns exemplos de casos de uso para aplicativos daemon incluem:

  • Aplicativos Web que são usados para provisionar ou administrar usuários ou executar processos em lotes em um diretório
  • Aplicativos de área de trabalho (como serviços do Windows no Windows ou processos daemon no Linux) que executam trabalhos em lotes ou um serviço do sistema operacional executado em segundo plano
  • APIs Web que precisam manipular diretórios, não usuários específicos

Há outro caso comum em que aplicativos não daemon usam credenciais de cliente, mesmo quando atuam em nome de usuários. Isso ocorre quando eles precisam acessar uma API Web ou um recurso com a própria identidade por motivos técnicos. Um exemplo é o acesso a segredos no Azure Key Vault ou no Banco de Dados SQL do Azure para um cache.

Você não pode implantar um aplicativo daemon no dispositivo de um usuário normal e um usuário normal não pode acessar um aplicativo daemon. Somente um conjunto limitado de administradores de TI pode acessar dispositivos que têm aplicativos daemon em execução. Isso é feito para que um ator mal-intencionado não possa acessar um segredo do cliente ou um token do tráfego de dispositivo e atuar em nome do aplicativo daemon. O cenário do aplicativo daemon não substitui a autenticação do dispositivo.

Exemplos de aplicativos não daemon:

  • Um aplicativo móvel que acessa um serviço Web em nome de um aplicativo, mas não em nome de um usuário.
  • Um dispositivo IoT que acessa um serviço Web em nome de um dispositivo, mas não em nome de um usuário.

Aplicativos que adquirem um token para suas próprias identidades:

  • Aplicativos cliente confidenciais, considerando que acessam recursos independentemente dos usuários, devem comprovar sua identidade. Os administradores de locatários do Microsoft Entra precisam conceder aprovação a esses aplicativos bastante confidenciais.
  • Registrou um segredo (certificado ou senha de aplicativo) com o Microsoft Entra ID. Esse segredo é passado durante a chamada ao Microsoft Entra ID para obter um token.

Especificações

Os usuários não podem interagir com um aplicativo daemon porque ele requer a própria identidade. Esse tipo de aplicativo solicita um token de acesso usando sua identidade de aplicativo e apresentando sua ID de aplicativo, credenciais (senha ou certificado) e URI de ID do aplicativo para o Microsoft Entra ID. Após a autenticação bem-sucedida, o daemon recebe um token de acesso (e um token de atualização) da plataforma de identidade da Microsoft. Esse token é usado para chamar a API Web (e é atualizado conforme necessário).

Como os usuários não podem interagir com aplicativos daemon, o consentimento incremental não é possível. Todas as permissões de API necessárias precisam ser configuradas no registro de aplicativo. O código do aplicativo solicita apenas permissões definidas estaticamente. Isso também significa que os aplicativos daemon não oferecerão suporte a consentimento incremental.

Para desenvolvedores, a experiência de ponta a ponta para esse cenário tem os seguintes aspectos:

  • Os aplicativos daemon somente podem funcionar nos locatários do Microsoft Entra. Não faria sentido criar um aplicativo daemon que tente manipular contas pessoais da Microsoft. Se você for um desenvolvedor de aplicativos de linha de negócios (LOB), criará seu aplicativo daemon em seu locatário. Se você for um ISV, talvez queira criar um aplicativo daemon multilocatário. Cada administrador de locatários precisa fornecer consentimento.
  • Durante o registro do aplicativo, o URI de resposta não é necessário. Compartilhe segredos, certificados ou declarações assinadas com o Microsoft Entra ID. Você também precisa solicitar permissões de aplicativo e conceder consentimento do administrador para usar essas permissões de aplicativo.
  • A configuração do aplicativo precisa fornecer credenciais de cliente como compartilhadas com o Microsoft Entra ID durante o registro do aplicativo.
  • O escopo usado para adquirir um token com o fluxo de credenciais do cliente precisa ser um escopo estático.

Se você é novo no gerenciamento de identidades e acesso (IAM) com o OAuth 2.0 e o OpenID Connect, ou até mesmo apenas no IAM na plataforma de identidade da Microsoft, o seguinte conjunto de artigos deve ter destaque na sua lista de leitura.

Embora não seja obrigatório ler antes de concluir seu primeiro início rápido ou tutorial, eles abrangem os tópicos integrantes da plataforma e a familiaridade com eles o ajudará no seu caminho à medida que você criar cenários mais complexos.

Autenticação e autorização

Plataforma de identidade da Microsoft

Próximas etapas

Vá para o próximo artigo neste cenário, Registro de aplicativo.