Permissões delegadas vs. permissões de aplicativo no Microsoft Entra ID: o que os administradores precisam saber

By Mirko Peters · 2026-10-28

Conheça as diferenças essenciais entre permissões delegadas e permissões de aplicativo no Microsoft Entra ID, incluindo boas práticas de segurança e as regras de privilégio mínimo.

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

Ao integrar ferramentas de terceiros ou aplicativos personalizados ao seu ambiente Microsoft 365, entender a diferença entre permissões delegadas e de aplicativo é essencial para manter a segurança na nuvem, evitar vazamentos de dados e aplicar o princípio do privilégio mínimo em todo o Microsoft Entra ID.

Principais conclusões

As permissões delegadas exigem um usuário conectado e atuam em nome dele, o que significa que o aplicativo só pode acessar os dados que o usuário tem direito de ver.
As permissões de aplicativo funcionam sem um usuário humano, concedendo amplo acesso a todo o locatário e exigindo aprovação de um administrador.
O princípio do privilégio mínimo determina que os aplicativos devem sempre receber o menor conjunto de permissões necessário para concluir sua tarefa.
O Microsoft Graph atua como a porta de entrada unificada para acessar os dados do Microsoft 365, dependendo fortemente desses modelos de permissão.
Entender essa distinção evita lacunas graves de segurança, como conceder acesso não intencional a todo o locatário para aplicativos de terceiros.

Entendendo as permissões OAuth na nuvem da Microsoft

Quando você conecta uma ferramenta externa de produtividade ou um script de automação interno ao seu ambiente Microsoft 365, dispara um fluxo OAuth 2.0 por trás dos panos. No entanto, obter um token de acesso é só metade da batalha. O verdadeiro limite de segurança é definido pelo que esse token efetivamente pode fazer. No ecossistema de identidade da Microsoft, centrado no Microsoft Entra ID (antigo Azure Active Directory), as permissões se dividem em dois tipos fundamentalmente diferentes: permissões delegadas e permissões de aplicativo.

Confundir esses dois modelos é uma das armadilhas mais comuns para administradores de TI, desenvolvedores e usuários avançados. Escolher o tipo de permissão errado pode expor dados de toda a empresa sem querer ou quebrar totalmente o funcionamento de um aplicativo. Vamos detalhar como cada tipo funciona, onde ele se aplica e como governá-los corretamente.

Permissões delegadas: agir em nome de um usuário

As permissões delegadas são feitas para aplicativos que têm um usuário humano do outro lado. Quando você entra em um aplicativo móvel ou em um serviço web com sua conta Microsoft, o aplicativo toma emprestada a sua identidade para um conjunto específico de tarefas. Isso é chamado de permissão delegada.

Nesse cenário, o aplicativo age como você. Ele só consegue acessar os dados que você já tem permissão para acessar, nem mais nem menos. Se a sua conta não tiver acesso de leitura a uma pasta específica do SharePoint ou ao calendário de um colega, o aplicativo também não terá. Como o raio de impacto fica naturalmente limitado pelas permissões do usuário individual, a Microsoft recomenda usar permissões delegadas sempre que houver uma pessoa envolvida no fluxo de trabalho.

Como as permissões delegadas aparecem na prática

Você interage com permissões delegadas toda vez que clica em uma janela de consentimento. Um assistente de agendamento pode exibir uma tela informando que quer ler o seu calendário. Essa solicitação representa um escopo OAuth específico. Como você está presente para aprovar ou negar o pedido, atua como o proprietário do recurso, controlando exatamente o que o aplicativo cliente pode tomar emprestado do seu perfil.

Permissões de aplicativo: serviços em segundo plano e acesso em todo o locatário

As permissões de aplicativo funcionam em um paradigma completamente diferente. Elas são projetadas para daemons em segundo plano, scripts de sincronização automatizados e serviços de backend que rodam às três da manhã, quando nenhum usuário está conectado. Pense em uma ferramenta de relatórios automatizada que agrega dados de todas as caixas de correio da organização.

Como não há um usuário presente para fornecer contexto de identidade, o aplicativo se autentica usando as próprias credenciais (como um ID de cliente e um segredo de cliente, por meio do fluxo de credenciais de cliente). Consequentemente, as permissões de aplicativo concedem à ferramenta a capacidade de agir em nome próprio em toda a organização. Se um aplicativo tiver permissões de aplicativo para ler e-mails, ele poderá ler o e-mail de cada usuário do locatário.

Por que o consentimento do administrador é obrigatório

Dado o enorme poder associado às permissões de aplicativo, usuários comuns não podem consentir com elas. Enquanto um funcionário padrão pode aprovar uma permissão delegada para o próprio calendário, as permissões de aplicativo exigem aprovação explícita de um administrador global ou de um administrador de função privilegiada. Esse controle rigoroso impede que aplicativos mal-intencionados ou mal programados extraiam, silenciosamente, dados de toda a organização.

Microsoft Graph e o papel dos escopos OAuth

Seja qual for o tipo de permissão, delegada ou de aplicativo, a aplicação acaba direcionando suas solicitações para um único e poderoso ponto de acesso: o Microsoft Graph. Todo chat de equipe, documento do SharePoint, arquivo do OneDrive e e-mail do Outlook pode ser acessado por meio do Microsoft Graph, desde que o aplicativo que faz a chamada apresente um token de acesso OAuth válido.

As barreiras que mantêm esses tokens sob controle são chamadas de escopos. Um escopo é um rótulo preciso incorporado ao token que define limites exatos, como ler um calendário em vez de enviar um e-mail. Quando desenvolvedores solicitam escopos amplos demais (por exemplo, pedir acesso de leitura e gravação quando um simples acesso de leitura seria suficiente), eles violam práticas básicas de segurança. Os administradores devem auditar esses escopos com cuidado durante as revisões de registro de aplicativos.

Como aplicar o privilégio mínimo no seu locatário

As melhores práticas de segurança no Microsoft Entra ID sempre voltam a uma regra de ouro: o princípio do privilégio mínimo. Cada aplicativo, entidade de serviço e script de automação deve receber o nível absoluto de acesso necessário para cumprir sua função.

Sempre prefira permissões delegadas a permissões de aplicativo sempre que um usuário humano interagir com o aplicativo.
Examine com atenção as solicitações de consentimento para garantir que os aplicativos não peçam escopos desnecessários.
Revise regularmente os aplicativos empresariais registrados no Microsoft Entra ID para revogar tokens órfãos ou registros de aplicativos não utilizados.
Garanta supervisão administrativa para qualquer fluxo de credenciais de cliente que opere em ambientes sem interface.

Conclusão

Entender a mecânica da identidade moderna na nuvem exige ir além dos simples botões de login e examinar as estruturas de permissão por trás deles. Seja você quem gerencia aplicativos móveis voltados ao usuário com escopos delegados ou grandes automações empresariais que dependem de permissões de aplicativo, compreender esses limites é essencial para um ambiente seguro do Microsoft 365.

Para aprofundar os fundamentos de como essas trocas de autenticação funcionam, ouça o episódio completo do podcast, com uma explicação sem jargões sobre OAuth 2.0, ciclos de vida de tokens e os quatro participantes de cada troca de autenticação.

Perguntas frequentes

Usuários comuns podem aprovar permissões de aplicativo no Microsoft Entra ID?

Não. As permissões de aplicativo funcionam sem um usuário conectado e têm alcance em todo o locatário. Por isso, somente um administrador com os direitos adequados no locatário pode conceder permissões de aplicativo.

O que acontece se um usuário tentar acessar um arquivo por meio de um aplicativo com permissões delegadas para o qual ele não tem direitos?

O aplicativo também será bloqueado e não conseguirá acessar esse arquivo. As permissões delegadas usam a identidade do usuário, o que significa que o aplicativo nunca pode ultrapassar os limites de acesso pessoais desse usuário.

Qual é o principal risco de segurança das permissões de aplicativo?

Como as permissões de aplicativo executam serviços em segundo plano sem supervisão humana, uma credencial de aplicativo comprometida pode conceder a um invasor acesso irrestrito às caixas de correio, arquivos e recursos de toda a empresa.

Como o Microsoft Graph interage com tokens OAuth e permissões?

O Microsoft Graph funciona como o gateway de API do Microsoft 365. Toda requisição ao Graph precisa carregar um token de acesso OAuth que incorpora escopos específicos, definindo permissões delegadas ou de aplicativo.