Uma nova pesquisa da empresa de segurança Semperis revelou que 9% dos aplicativos SaaS que utilizam Microsoft Entra ID continuam vulneráveis à falha conhecida como nOAuth, mesmo dois anos após sua descoberta inicial. Essa revelação é alarmante, considerando o papel central do Entra ID na autenticação moderna de identidades corporativas e o crescimento exponencial do uso de serviços SaaS no ambiente corporativo.
nOAuth: A persistente vulnerabilidade que ainda ameaça aplicativos SaaS com Microsoft Entra ID
Neste artigo, vamos explorar a fundo a vulnerabilidade nOAuth, explicando o que ela é, como funciona, por que ainda representa uma ameaça significativa à segurança de usuários e empresas, e quais medidas devem ser tomadas para mitigar seus riscos. Também discutiremos as responsabilidades dos desenvolvedores e provedores de serviços na adoção de práticas seguras de autenticação e proteção de dados.
Em um cenário cada vez mais dependente de aplicações baseadas em nuvem, falhas de autenticação podem representar portas de entrada para ataques graves, como assunção de contas, acesso não autorizado a dados sensíveis e movimentação lateral em ambientes corporativos. Entender a ameaça do nOAuth é essencial para todos os envolvidos na cadeia de desenvolvimento, uso e administração de aplicativos SaaS.
O que é a vulnerabilidade nOAuth?
A vulnerabilidade nOAuth é uma falha de autenticação que ocorre quando aplicativos SaaS integram o Microsoft Entra ID (antigo Azure Active Directory) de forma inadequada, ignorando princípios fundamentais da especificação OAuth 2.0 e OpenID Connect (OIDC). O problema surge quando o aplicativo confia exclusivamente em atributos mutáveis, como o endereço de e-mail, para identificar usuários autenticados, desconsiderando identificadores únicos e imutáveis.
Essa vulnerabilidade pode ser explorada por agentes maliciosos que manipulam o atributo de e-mail, forçando o sistema a autenticar uma identidade diferente da originalmente validada. Isso possibilita a chamada assunção de conta (account takeover), sem a necessidade de violar senhas ou realizar ataques sofisticados.
A falha na autenticação e a exploração do e-mail não verificado
O núcleo da falha está na confiança excessiva no atributo de e-mail como identificador de usuário. O Microsoft Entra ID permite que contas sejam criadas ou modificadas com endereços de e-mail não verificados. Um atacante pode se autenticar usando um provedor de identidade legítimo (como Gmail ou Outlook.com), alterar o endereço de e-mail retornado pela autenticação OpenID Connect, e explorar um aplicativo que confia apenas nesse e-mail para conceder acesso.
Essa abordagem torna o ataque silencioso, difícil de detectar, e viável mesmo sem qualquer comprometimento prévio de conta ou phishing, representando uma ameaça particularmente grave para ambientes corporativos que integram múltiplos serviços SaaS.
Múltiplos provedores de identidade e a mesclagem de contas
Outra faceta crítica do problema está nos aplicativos que aceitam múltiplos provedores de identidade (IdPs). Muitos desenvolvedores implementam autenticação com suporte para Google, Microsoft, LinkedIn, entre outros, sem normalizar adequadamente os identificadores de usuário entre os diferentes provedores.
Em tais cenários, se dois usuários autenticarem com contas diferentes que possuem o mesmo endereço de e-mail, o sistema pode fundir (merge) essas identidades incorretamente. Essa prática comum, mas arriscada, facilita a exploração da vulnerabilidade nOAuth, ao permitir que um atacante obtenha acesso a recursos que pertencem a outro usuário legítimo com o mesmo e-mail.
O impacto duradouro: por que o nOAuth ainda é uma ameaça?
A mais recente análise da Semperis indica que, mesmo após dois anos de alertas, 9% dos aplicativos SaaS que utilizam Microsoft Entra ID permanecem vulneráveis ao nOAuth. Isso representa milhares de sistemas corporativos em risco — um número inaceitável, dada a gravidade da falha e a clareza das soluções propostas desde sua divulgação original.
A persistência da falha pode ser atribuída à falta de entendimento técnico por parte de alguns desenvolvedores, à ausência de validações rigorosas durante a integração com Entra ID, e à confusão sobre quem é responsável pela segurança da autenticação em ambientes híbridos.
As consequências potenciais de uma exploração bem-sucedida incluem:
- Assunção de conta de administradores ou usuários com acesso privilegiado;
- Exposição de dados corporativos sensíveis;
- Movimentação lateral para outros sistemas interconectados;
- Violação de políticas de conformidade e privacidade, com impactos legais e reputacionais.
A questão da responsabilidade: Microsoft vs. desenvolvedores
A Microsoft, desde a identificação do problema, forneceu diretrizes claras para mitigar a vulnerabilidade, recomendando que desenvolvedores utilizem os atributos “sub” (subject) e “iss” (issuer) como identificadores únicos e imutáveis de usuários autenticados, em vez de confiar no e-mail.
No entanto, a implementação correta dessas diretrizes depende exclusivamente dos desenvolvedores e fornecedores de SaaS, que muitas vezes terceirizam ou subestimam os riscos de segurança. A Microsoft fornece as ferramentas, mas a responsabilidade de usá-las corretamente é de quem integra seus serviços.
Essa divisão de responsabilidades levanta questões críticas sobre governança de identidade e segurança compartilhada, especialmente em ambientes corporativos com grande adoção de soluções terceirizadas.
Como mitigar o risco do nOAuth: um guia para desenvolvedores e empresas
A boa notícia é que a vulnerabilidade nOAuth pode ser mitigada de forma relativamente simples, desde que os desenvolvedores sigam as práticas recomendadas e que os administradores de TI estejam atentos às configurações de autenticação de seus sistemas.
Entre as ações essenciais para proteger seus aplicativos e ambientes estão:
- Evitar o uso do e-mail como identificador principal de usuários autenticados;
- Validar se os e-mails retornados por provedores de identidade são verificados e confiáveis;
- Adotar identificadores únicos e imutáveis (“sub” e “iss”) como base para controle de acesso e persistência de contas;
- Auditar regularmente os aplicativos integrados ao Entra ID para identificar implementações inseguras.
Boas práticas na implementação de OpenID Connect
A autenticação baseada em OpenID Connect (OIDC) é poderosa e segura quando implementada corretamente. Para evitar vulnerabilidades como o nOAuth, os desenvolvedores devem:
- Utilizar a combinação dos campos “sub” (identificador único do usuário) e “iss” (emissor do token) como chave primária para usuários autenticados;
- Evitar depender do e-mail como critério exclusivo de identificação, mesmo quando validado;
- Rejeitar tokens com atributos modificados ou e-mails não verificados;
- Implementar lógica de autenticação resistente à fusão automática de identidades entre múltiplos IdPs.
Empresas também devem exigir de seus fornecedores de SaaS transparência sobre a forma como implementam a autenticação, e revisar os contratos de segurança para garantir conformidade com essas práticas.
Conclusão: a segurança contínua é responsabilidade compartilhada
A vulnerabilidade nOAuth continua a representar um risco real e evitável para milhares de organizações ao redor do mundo. A recente descoberta de que quase 10% dos aplicativos ainda estão vulneráveis é um alerta grave para a indústria de software e para os profissionais de segurança.
A responsabilidade pela segurança da autenticação não pode recair exclusivamente sobre a Microsoft ou qualquer outro provedor de identidade. Cabe aos desenvolvedores implementar corretamente as diretrizes disponíveis, e às empresas usuárias cobrar essa responsabilidade, revisando periodicamente os riscos de seus ecossistemas SaaS.
Segurança é um processo contínuo, que exige vigilância, atualização e compromisso com as melhores práticas. O ataque nOAuth nos lembra que, em um mundo cada vez mais conectado e baseado em identidade digital, um pequeno erro de implementação pode ter consequências catastróficas.
Revisite sua implementação. Questione seus fornecedores. Proteja seus usuários.
