Cenário: aplicativo Daemon que chama APIs da Web

  • Artigo

Este cenário irá guiá-lo para criar um aplicativo daemon que chama APIs da Web.

Descrição geral

Seu aplicativo pode adquirir um token para chamar uma API da Web em nome de si mesmo (não em nome de um usuário). Este cenário é útil para aplicações daemon. Ele usa a concessão de credenciais de cliente OAuth 2.0 padrão.

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 fazer processos em lote em um diretório
  • Aplicativos de área de trabalho (como serviços do Windows no Windows ou processos de daemon no Linux) que executam trabalhos em lote ou um serviço do sistema operacional que é executado em segundo plano
  • APIs da 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 agem em nome de usuários. Isso ocorre quando eles precisam acessar uma API da Web ou um recurso sob sua própria identidade por motivos técnicos. Um exemplo é o acesso a segredos no Cofre da Chave do Azure 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 regular e um usuário regular não pode acessar um aplicativo daemon. Apenas um conjunto limitado de administradores de TI pode acessar dispositivos que têm aplicativos daemon em execução. Isso é para que um agente mal-intencionado não possa acessar um segredo de cliente ou token do tráfego do dispositivo e agir em nome do aplicativo daemon. O cenário do aplicativo daemon não substitui a autenticação do dispositivo.

Exemplos de aplicações 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:

  • Os aplicativos clientes confidenciais, dado que acessam recursos independentemente dos usuários, precisam provar sua identidade. Os administradores de locatários do Microsoft Entra precisam conceder aprovação a esses aplicativos bastante confidenciais.
  • Ter registado um segredo (palavra-passe ou certificado de aplicação) com o Microsoft Entra ID. Este segredo é passado durante a chamada para o Microsoft Entra ID para obter um token.

Especificidades

Os usuários não podem interagir com um aplicativo daemon porque ele requer sua própria identidade. Esse tipo de aplicativo solicita um token de acesso usando sua identidade de aplicativo e apresentando sua ID de aplicativo, credencial (senha ou certificado) e URI de ID de aplicativo para 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 da 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 do aplicativo. O código do aplicativo apenas solicita permissões definidas estaticamente. Isso também significa que os aplicativos daemon não suportarão consentimento incremental.

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

  • Os aplicativos Daemon só podem funcionar em locatários do Microsoft Entra. Não faria sentido criar um aplicativo daemon que tenta 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, convém criar um aplicativo daemon multilocatário. Cada administrador de locatário precisa fornecer consentimento.
  • Durante o registro do aplicativo, o URI de resposta não é necessário. Compartilhe segredos ou certificados ou asserções assinadas com o Microsoft Entra ID. Você também precisa solicitar permissões de aplicativo e conceder consentimento de administrador para usar essas permissões de aplicativo.
  • A configuração do aplicativo precisa fornecer credenciais de cliente conforme 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 identidade e acesso (IAM) com OAuth 2.0 e OpenID Connect, ou até mesmo é novo no IAM na plataforma de identidade da Microsoft, o conjunto de artigos a seguir deve estar no topo da sua lista de leitura.

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

Autenticação e autorização

Plataforma de identidade da Microsoft

Próximos passos

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