Permissões delegadas vs. de aplicativo: como escolher o modelo certo para o seu app

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

Bem-vindo de volta ao podcast e à nossa série contínua para ajudar você a dominar o Microsoft 365, o Azure e as ferramentas de desenvolvimento que sustentam o ecossistema de nuvem moderno. Se você já criou uma integração, escreveu um script ou implantou uma automação corporativa usando a API do Microsoft Graph, com certeza já bateu na barreira das permissões. Proteger o seu locatário enquanto constrói aplicativos funcionais é um dos equilíbrios mais críticos que você vai enfrentar como administrador ou desenvolvedor. A escolha entre os diferentes modelos de permissão afeta diretamente a sua postura de segurança, a velocidade de implantação e a arquitetura geral do sistema.

Para aprofundar esse assunto complexo, gravamos recentemente um episódio com mais detalhes. Não deixe de conferir a discussão completa em áudio em Microsoft Graph Permissions and Consent Models Explained. Neste post complementar, vamos expandir esses conceitos, examinando as diferenças essenciais entre permissões delegadas e de aplicativo, revisando os modelos de consentimento, explorando as melhores práticas e apresentando um framework completo para garantir que os seus apps continuem seguros e em conformidade.

Visão geral das permissões da API do Microsoft Graph

Antes de entrar nas nuances de fluxos de autorização específicos, vale entender o que são, de fato, as permissões da API do Microsoft Graph. Em essência, o Microsoft Graph funciona como um gateway unificado para os dados armazenados nos serviços do Microsoft 365, incluindo Exchange Online, SharePoint, Microsoft Teams, OneDrive e Azure Active Directory (Microsoft Entra ID). Em vez de obrigar os desenvolvedores a se autenticar em vários endpoints isolados, o Microsoft Graph oferece um único endpoint de API REST. No entanto, como essa API dá acesso a praticamente todos os cantos do patrimônio digital de uma organização, proteger essa API exige um framework de permissões robusto e granular.

Permissões delegadas vs. de aplicativo

Ao registrar um aplicativo na plataforma de identidade da Microsoft, você precisa declarar explicitamente como ele pretende interagir com os recursos. Isso se resume, basicamente, à escolha entre dois tipos principais de permissão: permissões delegadas e permissões de aplicativo. Essas escolhas determinam como o seu aplicativo se autentica, quem ou o que ele representa e os limites dos dados que pode recuperar.

Permissões delegadas são projetadas para aplicativos do lado do cliente ou voltados ao usuário, como apps de página única, aplicativos móveis ou utilitários de desktop, nos quais há um usuário conectado e ativo. Nesse modelo, o seu app opera *em nome do* usuário. O aplicativo só pode acessar dados e executar ações que o próprio usuário tem direito de realizar. Quando um usuário abre o app, ele é solicitado a entrar e conceder consentimento explicitamente, o que gera um token de acesso OAuth 2.0 contendo tanto a identidade do usuário quanto os escopos consentidos.

Permissões de aplicativo, por outro lado, são usadas por serviços em segundo plano, daemons, web jobs e runbooks automatizados que funcionam independentemente de qualquer contexto de usuário. Aqui, o app atua com a sua própria identidade. Ele utiliza credenciais de cliente, como um segredo de cliente, um par de chaves de certificado público/privado ou uma identidade gerenciada, para obter do Azure AD um token de acesso somente de aplicativo. Como nenhum usuário humano está diante do teclado para se autenticar, essas permissões abrangem recursos de todo o locatário. Consequentemente, carregam riscos de segurança significativamente maiores e sempre exigem consentimento explícito de um administrador do locatário.

Principais diferenças e casos de uso

Entender quando aplicar cada modelo de permissão evita gargalos arquiteturais e vulnerabilidades de segurança. Vamos ver um resumo comparativo rápido:

Permissões delegadas: o app trabalha em nome de um usuário. O usuário precisa entrar e consentir. O app só pode ver o que o usuário pode ver. Esse modelo é ideal para aplicativos cliente que leem ou gravam dados pessoais, como calendários ou e-mails individuais.
Permissões de aplicativo: o app trabalha como ele mesmo. Nenhum usuário precisa entrar. Um administrador precisa consentir. O app pode visualizar e modificar dados em todo o locatário. Esse modelo é ideal para sincronização em segundo plano, relatórios administrativos e tarefas automatizadas de governança.

A escolha do modelo correto depende totalmente da arquitetura da sua aplicação. Por exemplo, se você estiver criando um painel interativo que exibe o perfil de um usuário e a caixa de entrada pessoal dele, deve usar permissões delegadas. Por outro lado, se estiver desenvolvendo um script automatizado que verifica todas as caixas de correio da organização à meia-noite para auditorias de conformidade, são necessárias permissões de aplicativo.

Permissões delegadas no Microsoft Graph

Como funcionam as permissões delegadas

O acesso delegado está profundamente ligado à identidade do usuário. Quando sua aplicação solicita uma permissão delegada, ela essencialmente pede ao servidor de autorização permissão para se passar pelo usuário conectado, dentro de limites definidos. O token de acesso retornado pelo fluxo de código de autorização do OAuth contém declarações de escopo específicas que refletem tanto os direitos intrínsecos do usuário quanto as permissões solicitadas pela aplicação.

O acesso delegado significa que sua aplicação atua diretamente como o usuário.
Tanto o registro da aplicação quanto o usuário individual precisam ter os direitos adequados subjacentes.
Os escopos definem o limite exato do que sua aplicação pode fazer em nome do usuário.
O token de acesso resultante vincula a identidade da aplicação e o contexto do usuário em um só.

Cenários comuns para permissões delegadas

As permissões delegadas sustentam a maioria das integrações de produtividade do dia a dia. Por exemplo, se um aplicativo corporativo de anotações precisa sincronizar arquivos com o OneDrive de um usuário, ele solicita o escopo Files.ReadWrite. Se o usuário não tiver permissão para acessar um documento específico, a API do Graph rejeitará a solicitação, mesmo que o escopo do aplicativo, tecnicamente, permita o acesso. Da mesma forma, aplicativos que usam o SDK do Microsoft Graph para enviar notificações automáticas por e-mail em nome de um usuário utilizam escopos delegados como Mail.Send.

Considerações de segurança e consentimento

Embora as permissões delegadas sejam, por natureza, mais seguras do que as permissões de aplicativo em todo o locatário, porque são limitadas pelas restrições do usuário, elas ainda apresentam desafios de segurança próprios. Se um aplicativo solicitar escopos excessivamente amplos, como acesso total à caixa de correio inteira e ao perfil do diretório de um usuário, um ataque de phishing bem-sucedido ou o comprometimento do aplicativo poderia expor dados pessoais sensíveis. Os desenvolvedores devem seguir rigorosamente o princípio do menor privilégio, solicitando apenas os escopos específicos necessários para a funcionalidade imediata.

Permissões de aplicativo no Microsoft Graph

Como funcionam as permissões de aplicativo

As permissões de aplicativo eliminam o elemento humano da equação de autenticação. Em vez de interagir com uma solicitação de login, a aplicação se autentica diretamente no Microsoft Entra ID usando credenciais de cliente. O token resultante contém funções de aplicativo em vez de escopos delegados, concedendo à entidade de serviço acesso amplo e irrestrito aos recursos de todo o locatário.

As permissões de aplicativo funcionam totalmente sem um usuário conectado.
A aplicação obtém um token somente de aplicativo para consultar os recursos.
O acesso é regido pelas funções de aplicativo atribuídas à entidade de serviço, e não pelos privilégios individuais de usuários.

Quando usar permissões de aplicativo

Você deve restringir as permissões de aplicativo estritamente a cargas de trabalho de backend, daemons não supervisionados e integrações sistema a sistema. Exemplos incluem mecanismos automatizados de provisionamento de usuários, sistemas centralizados de backup, ferramentas de resposta a incidentes de segurança e scripts de migração de locatários.

Consentimento de administrador e implicações de segurança

Como as permissões de aplicativo ignoram as restrições individuais dos usuários e concedem acesso em todo o locatário, usuários comuns não podem consentir com elas. Somente um administrador com privilégios pode conceder o consentimento de aplicativo. Permissões de aplicativo mal configuradas, como conceder Directory.ReadWrite.All ou Mail.ReadWrite.All a um aplicativo em segundo plano não confiável ou mal codificado, podem deixar todo o locatário do Microsoft 365 vulnerável a um comprometimento total. Audite regularmente as entidades de serviço dos seus aplicativos corporativos.

Prós e contras das permissões da API do Microsoft Graph

Prós

Modelo de permissões unificado: uma estrutura de autorização única e consistente em todos os serviços do Microsoft 365 simplifica a administração.
Escopos granulares: escopos delegados e de aplicativo detalhados permitem arquiteturas de menor privilégio precisas.
OAuth2/OpenID Connect padrão: utiliza protocolos de segurança padrão do setor para uma integração de identidade direta.
Integração com RBAC: Integra-se perfeitamente às funções do Azure AD e às políticas de acesso condicional para conformidade centralizada.
Consentimento incremental: Permite que os aplicativos solicitem permissões adicionais ao longo do tempo, em vez de exigir tudo logo no início.

Desvantagens

Complexidade: Entender a interseção entre escopos delegados, funções de aplicativo e modelos de consentimento do administrador pode sobrecarregar quem está começando.
Riscos de privilégios elevados: Configurar incorretamente permissões amplas (como Sites.FullControl.All) pode expor grandes volumes de dados corporativos.
Gargalos no consentimento do administrador: Exigir aprovação administrativa para permissões de alto impacto pode desacelerar os ciclos de desenvolvimento ágeis.
Documentação fragmentada: Desenvolvedores frequentemente precisam consultar vários repositórios de documentação da Microsoft para mapear o comportamento exato das APIs.

Modelos de consentimento e melhores práticas

Consentimento do usuário versus do administrador no Microsoft Graph

Gerenciar como o consentimento é obtido é essencial para a governança organizacional. O consentimento do usuário permite que indivíduos autorizem aplicativos a acessar seus dados pessoais. O consentimento do administrador transfere o ponto de aprovação para os administradores de TI, que avaliam as solicitações de aplicativos em nome de toda a organização. Linhas de base de segurança corporativas modernas frequentemente desabilitam totalmente o consentimento do usuário, obrigando todo o onboarding de aplicativos a passar por fluxos formais de pré-aprovação pelo administrador.

Impacto das políticas do locatário nas permissões

As políticas de locatário corporativo podem alterar fundamentalmente o comportamento do seu aplicativo em tempo de execução. Se um administrador tiver imposto políticas rigorosas de Acesso Condicional, como exigir autenticação multifator (MFA) ou dispositivos ingressados no Azure AD híbrido e em conformidade, um aplicativo que tente obter um token do Graph sem atender a esses critérios será bloqueado. Os desenvolvedores devem projetar seus aplicativos para tratar falhas na obtenção de tokens de forma elegante e fornecer etapas claras de correção de erros.

Estratégias para um fluxo de consentimento tranquilo

Para evitar atritos com o usuário e bloqueios administrativos, planeje sua estratégia de permissões antes de escrever o código. Implemente padrões de consentimento incremental em que seu aplicativo solicita escopos básicos de identidade logo no início e pede permissões de recursos específicos somente quando o usuário acessa esses recursos. Use fluxos automatizados de pré-aprovação no Microsoft Entra ID para agilizar o desenvolvimento, mantendo rigorosa supervisão de segurança.

Erros comuns que as pessoas cometem com as permissões da API do Microsoft Graph

Confundir permissões delegadas e de aplicativo e não compreender os requisitos de contexto do usuário.
Solicitar permissões excessivas logo no início, em vez de adotar uma abordagem de privilégio mínimo.
Não considerar os requisitos de consentimento do administrador ao implantar serviços em segundo plano.
Presumir que alterações de permissão no portal do Azure têm efeito imediato, sem a renovação do token.
Apresentar um token de acesso delegado quando é necessário um token de credenciais de cliente.
Ignorar políticas de Acesso Condicional que bloqueiam solicitações à API do Graph em tempo de execução.
Negligenciar a validação das declarações de escopo no código do aplicativo em tempo de execução.
Não auditar, ao longo do tempo, as permissões de aplicativo concedidas e as entidades de serviço.

Lista de verificação de permissões da API do Microsoft Graph

Use esta lista de verificação prática para orientar sua equipe na criação, implementação e auditoria das permissões da API do Microsoft Graph com segurança:

Conclusão

Entender as permissões da API do Microsoft Graph não precisa ser uma fonte de frustração. Ao compreender com clareza as diferenças operacionais entre permissões delegadas (que exigem um usuário conectado e operam dentro das restrições do usuário) e permissões de aplicativo (que são executadas sem restrições em segundo plano e exigem consentimento do administrador), você pode arquitetar soluções seguras e escaláveis. Adotar o princípio do privilégio mínimo, aplicar auditorias rigorosas e utilizar as ferramentas de governança corporativa manterá seu ambiente do Microsoft 365 seguro sem desacelerar a inovação.

Para mais orientações especializadas, estratégias práticas e análises aprofundadas sobre a segurança do seu ambiente em nuvem, não deixe de ouvir nossa análise em áudio completa no episódio relacionado: Microsoft Graph Permissions and Consent Models Explained. Mantenha suas permissões restritas, suas credenciais seguras e bons códigos!