Noções básicas sobre o acesso somente ao aplicativo
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 qualquer 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. Esse cenário é o acesso somente ao aplicativo.
Quando devo usar o acesso somente ao aplicativo?
Na maioria dos casos, o acesso somente ao aplicativo é mais amplo e mais eficiente do que o acesso delegado, portanto, você só deve usar o acesso somente ao aplicativo quando necessário. Geralmente, é a escolha certa se:
- O aplicativo precisa ser executado de maneira automatizada, sem a entrada do usuário. Por exemplo, um script diário que verifica emails de determinados contatos e envia respostas automatizadas.
- O aplicativo precisa acessar recursos pertencentes a vários usuários diferentes. Por exemplo, um aplicativo de prevenção contra perda de dados ou backup pode precisar recuperar mensagens de muitos canais de chat diferentes, cada um com participantes diferentes.
- Você se vê tentado a armazenar credenciais localmente e permitir que o aplicativo entre "como" o usuário ou o 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 o acesso delegado para ter menos privilégios.
Autorizar um aplicativo a fazer chamadas somente de aplicativo
Para fazer chamadas somente de aplicativo, você precisa atribuir ao aplicativo cliente as funções de aplicativo apropriadas. As funções de aplicativo também são chamadas de permissões somente de aplicativo. Elas são funções de aplicativo porque concedem acesso somente no contexto do aplicativo de recursos que define a função.
Por exemplo, para ler uma lista de todas as equipes criadas em uma organização, você precisa atribuir ao aplicativo a função de aplicativo Team.ReadBasic.All do Microsoft Graph. Essa função de aplicativo concede a capacidade de ler esses dados quando o Microsoft Graph é o aplicativo de recursos. Essa atribuição não atribui seu aplicativo cliente a uma função do Teams que permita a exibição desses dados por meio de outros serviços.
Como desenvolvedor, você precisa configurar todas as permissões somente de aplicativo necessárias, também conhecidas como funções de aplicativo no registro de aplicativo. Você pode configurar as permissões somente de aplicativo solicitadas do aplicativo por meio do portal do Azure ou do Microsoft Graph. O acesso somente ao aplicativo não dá suporte ao consentimento dinâmico, portanto, você não pode solicitar permissões individuais ou conjuntos de permissões em runtime.
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 de funções com privilégios podem conceder permissões somente de aplicativo (funções de aplicativo) para a API do Microsoft Graph. Usuários com outras funções de administrador, como Administrador de Aplicativos e Administrador de Aplicativos de Nuvem, podem conceder permissões somente de aplicativo para outros recursos.
Usuário 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 consentimento interativo de dentro de seu aplicativo, mas essa opção não é preferível, pois o acesso somente ao aplicativo não requer um usuário.
Os usuários consumidores com contas da Microsoft, como contas Outlook.com ou Xbox Live, nunca podem autorizar o acesso somente ao aplicativo.
Siga sempre o princípio de privilégios mínimos: você nunca deve solicitar funções de que o seu aplicativo não precisa. Esse princípio ajuda a limitar o risco de segurança caso o aplicativo seja comprometido e facilita a permissão de acesso ao aplicativo pelos administradores. Por exemplo, se o aplicativo precisar apenas identificar usuários sem ler as informações detalhadas do perfil, você deverá solicitar a função de aplicativo mais limitada do Microsoft Graph User.ReadBasic.All em vez de User.Read.All.
Como projetar e publicar escopos para um serviço de recurso
Se você estiver criando um serviço no Microsoft Entra ID que expõe APIs para outros clientes chamarem, convém dar suporte ao acesso automatizado com funções de aplicativo (permissões somente de aplicativo). Você pode definir as funções de aplicativo do seu aplicativo na seção Funções de 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 de aplicativo geralmente devem ser o mais exatas possível e dar suporte a cenários funcionais específicos, uma vez que o acesso somente ao aplicativo não é restrito pelos direitos do usuário. Evite expor uma única função que conceda acesso completo read ou completo read/write a todas as APIs e recursos que seu serviço contém.
Observação
As funções de 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 suas funções de 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 membro permitidos ao criar as funções de aplicativo.
Como funciona o acesso somente ao aplicativo?
O mais importante a lembrar sobre o acesso somente ao aplicativo é que o aplicativo de chamada atua em seu próprio nome e como sua própria identidade. Não há nenhuma interação com o 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 do Microsoft Entra ID usando o fluxo de credenciais do cliente ou qualquer outro fluxo de autenticação com suporte. As funções atribuídas são adicionadas à declaração roles do token de acesso do aplicativo.
Em alguns cenários, a identidade do aplicativo pode determinar se o acesso é concedido, de forma semelhante aos direitos do usuário em uma chamada delegada. Por exemplo, a função de aplicativo Application.ReadWrite.OwnedBy concede a um aplicativo a capacidade de gerenciar entidades de serviço que o próprio aplicativo possui.
Exemplo de acesso somente ao aplicativo – Notificação por email automatizada por meio do Microsoft Graph
O exemplo a seguir ilustra um cenário de automação realista.
Alice deseja notificar uma equipe por email sempre que a pasta de relatórios de divisão que reside em um compartilhamento de arquivos do Windows registrar um novo documento. Alice cria uma tarefa agendada que executa um script do PowerShell para examinar a pasta e encontrar 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 nenhuma interação do usuário. O sistema de autorização verifica apenas a autorização do aplicativo. O Exchange Online verifica se o cliente que está fazendo a chamada recebeu a permissão de 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 emails. | 200 – Acesso permitido. A Administração permitiu que o aplicativo enviasse emails como qualquer usuário. | 403 – Não Autorizado. A administração não permitiu que esse cliente enviasse emails. |
| O script cria uma caixa de correio dedicada para enviar emails. | 200 – Acesso permitido. A Administração permitiu que o aplicativo enviasse emails como qualquer usuário. | 403 – Não Autorizado. A administração não permitiu que esse cliente enviasse emails. |
O exemplo dado é uma ilustração simples da autorização do aplicativo. O serviço de Exchange Online de produção dá suporte a muitos outros cenários de acesso, como limitar permissões de aplicativo a caixas de correio Exchange Online específicas.