Consentimento OAuth: quando uma autorização abre espaço para o risco

O que a Microsoft documentou

Em 29 de maio de 2025, a Microsoft publicou “Defending against evolving identity attack techniques”. A pesquisa descreve consent phishing: a vítima é induzida a autorizar uma aplicação, permitindo que o atacante obtenha tokens com os escopos concedidos. Também relata uma campanha que redirecionava a vítima para outra tentativa de phishing mesmo após cancelar o consentimento.

Referências: Microsoft Security Blog — Defending against evolving identity attack techniques · 29/05/2025

Uma lição recente sobre confiança em integrações

Em 13 de julho de 2026, outra pesquisa da Microsoft detalhou campanhas de abuso de OAuth em ambientes Salesforce, com técnicas associadas a ShinyHunters. O relato inclui engenharia social para autorizar aplicações maliciosas e comprometimento de integrações confiáveis. A Microsoft diferencia esse abuso de confiança de uma vulnerabilidade inerente ao Salesforce.

Esse caso é de Salesforce. A aplicação prática que propomos para o Entra ID é revisar as relações de confiança das integrações; não afirmar que o mesmo incidente ocorreu em todos os ambientes Microsoft 365.

Referências: Microsoft Security Blog — Defending SaaS-based applications against ShinyHunters OAuth abuse · 13/07/2026

O caso investigado pela Red Canary

A Red Canary relata uma investigação em que uma aplicação OAuth maliciosa usou acesso à caixa de correio durante cerca de 90 dias antes de uma campanha de phishing interno. A empresa apresenta o provável convite inicial a uma aplicação de IA como hipótese de sua análise, e não como uma etapa comprovada.

Para a governança, o caso reforça uma pergunta prática: um acesso autorizado continua adequado ao longo do tempo? A revisão deve considerar o que foi concedido e como a identidade se comporta, não apenas a aparência da solicitação inicial.

Referências: Red Canary — Understanding OAuth application attacks and defenses · relato da equipe de investigação

Delegada ou de aplicação: a diferença precisa estar clara

Permissões delegadas permitem agir em nome do usuário, dentro do acesso autorizado para ele e para a aplicação. Permissões de aplicação permitem operar sem usuário conectado. Automações podem precisar desse segundo modelo; a decisão depende da finalidade e do menor acesso necessário.

Consentimento administrativo não significa automaticamente acesso sem usuário: permissões delegadas também podem exigir um administrador. Por isso, o relatório deve mostrar o tipo de permissão concedida, e não inferi-lo apenas pela existência de consentimento.

Referências: Microsoft Learn — Overview of permissions and consent

O que revisar antes e depois de autorizar

• Confirme a origem da solicitação por um canal conhecido e valide a necessidade com o responsável pelo processo.
• Traduza as permissões para o negócio: ler documentos, enviar mensagens ou alterar dados têm impactos diferentes.
• Revise as políticas de consentimento e oriente usuários a reconhecer solicitações inesperadas. Um publicador verificado não dispensa a avaliação da necessidade de acesso.
• Registre o acesso aprovado e estabeleça uma data para revisar sua necessidade.
• Investigue mudanças de permissões e credenciais fora do fluxo esperado de aprovação.

Referências: Microsoft Learn — Security operations guide for applications · Microsoft Learn — Protect against consent phishing

Transforme o achado em uma conversa objetiva

Em vez de apresentar apenas “OAuth detectado”, uma recomendação útil explica a capacidade concedida e pede a validação correspondente. Exemplo de abordagem: “Esta identidade pode acessar dados corporativos. Confirme a finalidade, o responsável e se o escopo ainda é necessário”.

Um painel de governança ajuda a organizar essa revisão. A presença de uma permissão, isoladamente, não comprova comprometimento; um incidente exige investigação com as evidências e ferramentas apropriadas.