Cenário: Aplicativo daemon que chama APIs Web

Saiba tudo o que você precisa para 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

Aqui estão alguns exemplos de casos de uso para aplicativos daemon:

  • 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 eles atuam em nome dos usuários, eles precisam acessar uma API Web ou um recurso sob sua 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.

Observação

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, de modo que um ator mal-intencionado não possa acessar um segredo do cliente ou um token no 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 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:

  • São aplicativos clientes confidenciais. Esses aplicativos, considerando que acessam recursos independentemente dos usuários, devem comprovar sua identidade. Eles também são preferivelmente aplicativos confidenciais. Eles precisam ser aprovados pelos administradores de locatários do Azure Active Directory (AAD).
  • Registrou um segredo (certificado ou senha de aplicativo) com o Azure AD. Esse segredo é passado durante a chamada ao Azure AD para obter um token.

Especificações

Usuários não podem interagir com um aplicativo daemon. Um aplicativo daemon exige sua 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 Azure AD. 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 podem funcionar apenas em locatários do Azure AD. 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 precisará fornecer consentimento.
  • Durante o registro do aplicativo, o URI de resposta não é necessário. Compartilhe segredos ou certificados ou declarações assinadas com o Azure AD. 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 Azure AD 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.

Próximas etapas

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