Permissões delegadas vs. permissões de aplicativo

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Compare permissões delegadas e permissões de aplicativo no Microsoft Entra ID e escolha o modelo de acesso certo para APIs seguras, automação e desenvolvimento de aplicativos.

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

Quando você trabalha com o Microsoft Entra ID, entender quem pode fazer o quê, e em quais circunstâncias, é mais do que um detalhe técnico. Isso é a base do desenvolvimento seguro de aplicativos, da automação e da gestão de identidades na nuvem da Microsoft. Há uma diferença enorme entre permitir que usuários concedam acesso apenas o suficiente para que o seu aplicativo atue em nome deles (permissões delegadas) e dar ao aplicativo as chaves para executar tarefas de forma independente (permissões de aplicativo).

Errar nessa escolha pode abrir espaço para exposição indevida de dados, problemas de conformidade ou até incidentes de segurança. Acertar, por outro lado, traz automação mais fluida, governança mais clara e auditores mais satisfeitos. Este guia apresenta o panorama completo: os fundamentos desses tipos de permissão, como eles se aplicam na prática e todos os aspectos de segurança, governança e operação que você precisa considerar para tomar a decisão mais inteligente para o seu ambiente. Vamos colocar as permissões no devido lugar, porque com grande acesso vem uma grande responsabilidade.

Contexto e introdução aos modelos de permissão na identidade da Microsoft

As permissões no Microsoft Entra ID não são apenas caixas de seleção para marcar. Elas formam uma estrutura fundamental incorporada à forma como aplicativos e usuários interagem no Microsoft 365, no Azure e em outros serviços. Quando a Microsoft levou a identidade para a nuvem, era preciso um jeito de permitir que serviços e ferramentas de terceiros interagissem com segurança, sem conceder tudo a todos de forma irrestrita. Foi aí que surgiram as permissões delegadas e as permissões de aplicativo.

Esses modelos possibilitam gerenciar com precisão quem pode acessar o quê, estabelecendo limites claros entre o que um usuário individual pode aprovar e o que somente um administrador deve permitir. Eles são resultado de anos de aprendizado, às vezes da forma mais difícil, com as contas de serviço clássicas do AD e com acessos rígidos do tipo tudo ou nada. Entender esses modelos não é apenas uma boa prática: é essencial para atender a requisitos de conformidade, aplicar o Zero Trust e garantir que as operações do dia a dia não sejam interrompidas por configurações incorretas de segurança.

Permissões de aplicativo vs. permissões delegadas: conceitos centrais e cenários reais

Vamos explicar a diferença entre permissões delegadas e permissões de aplicativo em termos simples. Pense nas permissões delegadas como seu aplicativo atuando como um assistente: ele só tem acesso enquanto um usuário específico está conectado, e fica limitado ao que esse usuário poderia fazer. Já as permissões de aplicativo permitem que o aplicativo atue de forma independente, como um gerente sem supervisão com o próprio conjunto de chaves. Ele não precisa que um usuário esteja presente.

Com as permissões delegadas, a autenticação sempre envolve um usuário. Isso significa que, quando alguém entra, por exemplo em um aplicativo que precisa acessar seus e-mails ou sua agenda, ele concede ao aplicativo uma janela temporária para operar com a autoridade dessa pessoa. Se o usuário sair, essa janela se fecha. Isso é ideal para aplicativos que executam tarefas a pedido do usuário, como interfaces web, bots do Teams ou aplicativos móveis de produtividade.

Com as permissões de aplicativo, o próprio aplicativo se autentica com a sua identidade (uma entidade de serviço) e recebe o próprio token. É isso que viabiliza a automação e os trabalhos em segundo plano, como uma integração de sistemas que sincroniza dados entre o SharePoint e o seu CRM durante a noite. Não há interação do usuário: o aplicativo executa as tarefas no próprio cronograma e com o próprio nível de acesso, sempre sujeito ao que um administrador aprovar.

Imagine que você precise automatizar o provisionamento de usuários: um serviço em segundo plano atualizando silenciosamente as contas de usuário todas as noites. Nesse caso, as permissões delegadas não servem para nada, já que ninguém está disponível para aprovar o acesso. Mas quando a sua solução precisa oferecer recursos personalizados enquanto o usuário está ativo, como um aplicativo de assinatura de documentos vinculado ao OneDrive, é aí que as permissões delegadas se destacam.

Cenários reais frequentemente exigem uma combinação dos dois modelos. Por isso, saber qual modelo se encaixa no seu caso de uso é fundamental para a experiência do usuário, a governança e a segurança. Você não quer entregar mais chaves do que o necessário, mas também não quer que o seu serviço fique bloqueado às 3 da manhã porque ninguém está lá para fazer login.

Permissões delegadas do Microsoft Entra por dentro: fluxo de autenticação e limitações

As permissões delegadas no Microsoft Entra ID seguem um fluxo de autenticação clássico, conduzido pelo usuário. Ele começa quando um usuário entra no seu aplicativo com as credenciais da Microsoft. Nesse momento, o aplicativo solicita permissões específicas, ou escopos, mostrando ao usuário (e, às vezes, a um administrador) exatamente quais tipos de dados ou ações ele quer acessar.

Se as permissões solicitadas exigirem apenas consentimento do usuário, ele as aprova na hora, por meio de uma tela de consentimento. Para permissões mais sensíveis (como ler a caixa de correio de todos na organização), é necessário o consentimento do administrador. Depois do consentimento, seu aplicativo recebe um token de acesso vinculado diretamente à identidade do usuário e às funções atribuídas a ele.

Esse token de acesso é o que permite ao aplicativo chamar o Microsoft Graph ou as APIs do M365, mas ele sempre age com a autoridade do usuário. Assim, se o usuário for um funcionário comum, o aplicativo não consegue, de repente, pular para funcionalidades administrativas. Quando o usuário sai da conta, o acesso do aplicativo se encerra, o que mantém o raio de impacto pequeno.

Mas aqui está a limitação: as permissões delegadas não funcionam em cenários sem supervisão. Se você estiver executando um processo em segundo plano, um job agendado ou uma integração de serviço que não deveria depender de alguém logado no momento, as permissões delegadas simplesmente não atendem. Elas vinculam tudo à presença do usuário, o que significa que suporte, automação e tarefas noturnas esbarram em um muro.

Também há um aspecto de segurança a considerar. Se um usuário com acesso amplo for enganado e conceder consentimento, um aplicativo pode usar indevidamente essas permissões, um dos principais vetores em ataques de phishing por consentimento. Por isso, você precisa de controles rígidos sobre quem pode conceder quais permissões e de treinamento de conscientização sólido sobre o que essas telas de consentimento realmente significam.

Excesso de permissões no acesso de aplicativos e segurança de tokens no Microsoft Entra ID

Quando se trata de permissões, mais nem sempre é melhor. Na verdade, o excesso de permissões, isto é, conceder privilégios desnecessários ou excessivos, especialmente com permissões de aplicativo, pode abrir caminho para vazamentos de dados sensíveis e incidentes graves de segurança. Imagine que você dê a um aplicativo acesso de leitura e gravação a todas as caixas de correio da empresa, quando ele só precisa ler eventos de calendário: você acabou de ampliar bastante a sua superfície de ataque.

Esse perigo não é apenas teórico. Atacantes estão explorando o abuso de consentimento OAuth para contornar até a autenticação multifator. Eles miram usuários ou administradores com telas de consentimento enganosas, levando-os a aprovar permissões arriscadas. Depois de dentro, esses aplicativos maliciosos costumam manter o acesso mesmo quando as senhas são trocadas ou a MFA é imposta. O controle do atacante persiste, o que torna as defesas tradicionais ineficazes. Para uma análise de casos reais, confira esta explicação sobre como atacantes abusam do consentimento OAuth no Entra ID e as melhores formas de bloquear isso.

A conversa não para no excesso de permissões. Tokens e credenciais, incluindo client secrets e certificados, podem se tornar alvos muito valiosos se não forem protegidos. Um client secret vazado de um registro de aplicativo somente com aplicativo é tudo o que um atacante precisa para se passar pelo seu serviço. Por isso, a higiene de credenciais é essencial: use identidades gerenciadas sempre que possível, faça a rotação dos segredos e nunca armazene credenciais de cliente em código ou em arquivos desprotegidos. Para ambientes que dependem de acesso não humano, considere as Microsoft Entra Workload Identities, que permitem acesso sem segredos e auditável, e eliminam as dores de cabeça das contas de serviço legadas. Aqui está um mergulho mais profundo em por que as workload identities são indispensáveis para o Zero Trust.

Por fim, o monitoramento adequado é indispensável. Revise regularmente os logs de entrada e as concessões OAuth, configure alertas para consentimentos ou uso de tokens suspeitos e fique atento ao phishing por consentimento e ao roubo de tokens. Os achados de violações reais (como esta cadeia de ataque do Microsoft 365) mostram que os atacantes exploram governança fraca, então quanto mais visibilidade, melhor. Proteja as chaves, reduza as permissões e mantenha seus aplicativos sob controle.

Controles e melhores práticas para gerenciar permissões delegadas e de aplicativo

• Implemente controles integrados do Entra para o gerenciamento de permissõesAproveite os fluxos de consentimento integrados, os processos de aprovação do administrador e as políticas granulares do Microsoft Entra para restringir quais usuários ou grupos podem conceder permissões. Use políticas de consentimento do administrador para garantir que somente aplicativos avaliados recebam escopos de alto risco.
• Aplique o princípio do privilégio mínimoConceda aos aplicativos somente o conjunto mínimo de permissões necessárias para sua função. Revise cada permissão solicitada durante o registro do aplicativo e remova tudo o que for desnecessário. O privilégio mínimo é a sua defesa mais forte contra uso indevido e excesso de acesso.
• Agende revisões e auditorias regulares de permissõesConfigure revisões de acesso periódicas, usando os painéis de permissões e consentimento do Entra, para identificar e revogar permissões não utilizadas ou arriscadas. Automatize essas verificações sempre que possível para uma governança escalável, como descrito em guias avançados de governança, como esta estratégia do Microsoft Purview.
• Monitore e crie alertas para alterações de permissõesEstabeleça monitoramento e alertas para identificar novas concessões OAuth, picos no uso de permissões de aplicativos ou integrações inesperadas de administradores. Relatórios proativos dão tempo para responder antes que incidentes de segurança se agravem.
• Proteja o armazenamento de tokens e credenciaisArmazene segredos de cliente e tokens em cofres seguros, como o Azure Key Vault. Renove as credenciais regularmente, use certificados em vez de segredos compartilhados e prefira identidades de carga de trabalho ao integrar acessos não humanos, pois elas oferecem melhor gerenciamento do ciclo de vida e auditabilidade.
• Adote governança avançada e automação de políticasUse ferramentas como o Microsoft Purview e o Azure Policy para impor controles em todo o locatário, segmentar riscos com a Prevenção de Perda de Dados e projetar para conformidade contínua. Para um exemplo prático de como usar políticas para governança desde o projeto, veja a estratégia de governança empresarial do Azure.

Ao seguir estes passos e usar o ecossistema de ferramentas de governança da Microsoft, você vai capacitar sua organização a gerenciar os riscos de permissões antes que eles se tornem problemas. Eduque os usuários regularmente sobre práticas seguras de consentimento, automatize sempre que possível e lembre-se: o gerenciamento de permissões nunca é uma tarefa única. Mantenha-se atento, continue refinando as políticas e seu ambiente Entra ID permanecerá em boas condições.

Você também deve ouvir

Se você está explorando permissões delegadas versus permissões de aplicativo no Entra ID, estes episódios trazem contexto prático para a adoção segura do Microsoft 365, a proteção de dados, a governança e o gerenciamento de riscos de IA.

• Microsoft Purview – Simply Explained — Veja como classificação, retenção, conformidade e proteção se encaixam em um único modelo de governança de dados da Microsoft.
• Microsoft Defender XDR – Simply Explained — Conecte os controles de proteção de dados com detecção, investigação e resposta.
• Conditional Access – Simply Explained — Entenda como os sinais de identidade e risco adicionam contexto às decisões de acesso.
• Microsoft AI Agent Harness – Simply Explained — Explore os controles que tornam a automação com IA mais confiável, observável e segura.

Estes episódios ajudam a transformar os conceitos do artigo em decisões práticas de projeto e implantação.