Noções básicas sobre acesso somente a aplicativos
Quando um aplicativo acessa diretamente um recurso, como o Microsoft Graph, seu acesso não se limita aos arquivos ou operações disponíveis para um único usuário. O aplicativo chama APIs diretamente usando sua própria identidade, e um usuário ou aplicativo com direitos de administrador deve autorizá-lo a acessar os recursos. Este cenário é o acesso somente do aplicativo.
Quando devo usar o acesso somente para aplicativos?
Na maioria dos casos, o acesso somente ao aplicativo é mais amplo e poderoso do que o acesso delegado, portanto, você só deve usar o acesso somente do aplicativo quando necessário. Geralmente é a escolha certa se:
- O aplicativo precisa ser executado de forma automatizada, sem a entrada do usuário. Por exemplo, um script diário que verifica e-mails de determinados contatos e envia respostas automatizadas.
- O aplicativo precisa acessar recursos pertencentes a vários usuários diferentes. Por exemplo, um aplicativo de backup ou prevenção de perda de dados pode precisar recuperar mensagens de vários canais de bate-papo diferentes, cada um com participantes diferentes.
- Você se sente tentado a armazenar credenciais localmente e permitir que o aplicativo entre "como" o usuário ou administrador.
Por outro lado, você nunca deve usar o acesso somente ao aplicativo onde um usuário normalmente entraria para gerenciar seus próprios recursos. Esses tipos de cenários devem usar acesso delegado para serem menos privilegiados.
Autorizando um aplicativo a fazer chamadas somente de aplicativo
Para fazer chamadas somente para aplicativos, você precisa atribuir ao aplicativo cliente as funções apropriadas do aplicativo. As funções do aplicativo também são chamadas de permissões somente de aplicativo. Eles são funções de aplicativo porque concedem acesso somente no contexto do aplicativo de recurso que define a função.
Por exemplo, para ler uma lista de todas as equipes criadas em uma organização, você precisa atribuir ao seu aplicativo a função de aplicativo Microsoft Graph Team.ReadBasic.All . Esta função de aplicativo concede a capacidade de ler esses dados quando o Microsoft Graph é o aplicativo de recurso. Essa atribuição não atribui seu aplicativo cliente a uma função do Teams que possa permitir que ele exiba esses dados por meio de outros serviços.
Como desenvolvedor, você precisa configurar todas as permissões necessárias somente para aplicativos, também conhecidas como funções de aplicativo no registro do aplicativo. Você pode configurar as permissões solicitadas somente para aplicativos do seu aplicativo por meio do portal do Azure ou do Microsoft Graph. O acesso somente ao aplicativo não oferece suporte ao consentimento dinâmico, portanto, você não pode solicitar permissões individuais ou conjuntos de permissões em tempo de execução.
Depois de configurar todas as permissões de que seu aplicativo precisa, ele deve obter o consentimento do administrador para acessar os recursos. Por exemplo, somente usuários com a função de Administrador Global podem conceder permissões somente de aplicativo (funções de aplicativo) para a API do Microsoft Graph. Os usuários com outras funções de administrador, como Administrador de Aplicativos e Administrador de Aplicativos na Nuvem, podem conceder permissões somente para aplicativos para outros recursos.
Os usuários administradores podem conceder permissões somente para aplicativos usando o portal do Azure ou criando concessões programaticamente por meio da API do Microsoft Graph. Você também pode solicitar o consentimento interativo de dentro do seu aplicativo, mas essa opção não é preferível, já que o acesso somente ao aplicativo não requer um usuário.
Os utilizadores consumidores com Contas Microsoft, como contas Outlook.com ou Xbox Live, nunca podem autorizar o acesso apenas a aplicações.
Siga sempre o princípio do menor privilégio: nunca deve solicitar funções de aplicação de que a sua aplicação não necessita. Este princípio ajuda a limitar o risco de segurança se a sua aplicação estiver comprometida e torna mais fácil para os administradores concederem acesso à sua aplicação. Por exemplo, se o seu aplicativo precisar identificar usuários sem ler as informações detalhadas do perfil, você deverá solicitar a função de aplicativo Microsoft Graph User.ReadBasic.All mais limitada em vez de User.Read.All.
Projetando e publicando funções de aplicativo para um serviço de recursos
Se você estiver criando um serviço no Microsoft Entra ID que exponha APIs para outros clientes chamarem, convém oferecer suporte ao acesso automatizado com funções de aplicativo (permissões somente de aplicativo). Você pode definir as funções do aplicativo para seu aplicativo na seção Funções do aplicativo do registro do aplicativo no Centro de administração do Microsoft Entra. Para obter mais informações sobre como criar funções de aplicativo, consulte Declarar funções para um aplicativo.
Ao expor funções de aplicativo para outras pessoas usarem, forneça descrições claras do cenário ao administrador que as atribuirá. As funções do aplicativo geralmente devem ser o mais restritas possível e oferecer suporte a cenários funcionais específicos, já que o acesso somente ao aplicativo não é restrito pelos direitos do usuário. Evite expor uma única função que conceda acesso total read ou total read/write a todas as APIs e recursos contidos no seu serviço.
Nota
As funções do aplicativo (permissões somente de aplicativo) também podem ser configuradas para dar suporte à atribuição a usuários e grupos. Certifique-se de configurar as funções do aplicativo corretamente para o cenário de acesso pretendido. Se você pretende que as funções de aplicativo da API sejam usadas para acesso somente ao aplicativo, selecione aplicativos como os únicos tipos de membros permitidos ao criar as funções do aplicativo.
Como funciona o acesso somente ao aplicativo?
A coisa mais importante a lembrar sobre o acesso somente ao aplicativo é que o aplicativo de chamada age em seu próprio nome e como sua própria identidade. Não há interação do usuário. Se o aplicativo tiver sido atribuído a uma determinada função de aplicativo para um recurso, o aplicativo terá acesso totalmente irrestrito a todos os recursos e operações regidos por essa função de aplicativo.
Depois que um aplicativo tiver sido atribuído a uma ou mais funções de aplicativo (permissões somente de aplicativo), ele poderá solicitar um token somente de aplicativo da ID do Microsoft Entra usando o fluxo de credenciais do cliente ou qualquer outro fluxo de autenticação com suporte. As funções atribuídas são adicionadas à roles declaração do token de acesso do aplicativo.
Em alguns cenários, a identidade do aplicativo pode determinar se o acesso é concedido, da mesma forma que os direitos de usuário em uma chamada delegada. Por exemplo, a Application.ReadWrite.OwnedBy função de aplicativo concede a um aplicativo a capacidade de gerenciar entidades de serviço que o próprio aplicativo possui.
Exemplo de acesso somente aplicativo - Notificação por e-mail automatizada via Microsoft Graph
O exemplo a seguir ilustra um cenário de automação realista.
Alice quer notificar uma equipe por e-mail toda vez que a pasta de relatórios da divisão que reside em um compartilhamento de arquivos do Windows registra um novo documento. Alice cria uma tarefa agendada que executa um script do PowerShell para examinar a pasta e localizar novos arquivos. Em seguida, o script envia um email usando uma caixa de correio protegida por uma API de recurso, o Microsoft Graph.
O script é executado sem qualquer interação do usuário, portanto, o sistema de autorização verifica apenas a autorização do aplicativo. O Exchange Online verifica se o cliente que faz a chamada recebeu a permissão do aplicativo (função de aplicativo) Mail.Send pelo administrador. Se Mail.Send não for concedido ao aplicativo, o Exchange Online falhará na solicitação.
| POST /users/{id}/{userPrincipalName}/sendMail | Aplicativo cliente concedido Mail.Send | Aplicativo cliente não concedido Mail.Send |
|---|---|---|
| O script usa a caixa de correio de Alice para enviar e-mails. | 200 – Acesso concedido. O administrador permitiu que o aplicativo enviasse e-mails como qualquer usuário. | 403 - Não autorizado. O administrador não permitiu que este cliente enviasse e-mails. |
| O script cria uma caixa de correio dedicada para enviar e-mails. | 200 – Acesso concedido. O administrador permitiu que o aplicativo enviasse e-mails como qualquer usuário. | 403 - Não autorizado. O administrador não permitiu que este cliente enviasse e-mails. |
O exemplo dado é uma ilustração simples da autorização do pedido. O serviço Exchange Online de produção oferece suporte a muitos outros cenários de acesso, como limitar permissões de aplicativo a caixas de correio específicas do Exchange Online.