Erro clássico de quem tenta acessar o Workbench e esbarra em OAUTH_APP_ACCESS_DENIED. A causa quase nunca é o usuário, é a política de OAuth do Connected App mal configurada. Veja como diagnosticar e corrigir sem abrir buraco de segurança.
Todo consultor Salesforce já passou por isso: usuário pede acesso ao Workbench para rodar uma consulta SOQL rápida ou fazer um data load pontual, você libera o Profile, manda o link, e o cara volta cinco minutos depois com uma mensagem de erro que parece susto de segurança: OAUTH_APP_ACCESS_DENIED: user is not admin approved to access this app.
A primeira reação de quem não conhece o mecanismo por trás é pensar que é bug do Workbench ou problema de senha. Não é. O Workbench é um Connected App registrado no seu org (na prática, um app externo que faz OAuth contra a sua instância), e como qualquer Connected App, ele obedece à política de Permitted Users configurada em OAuth Policies. Quando essa política está como Admin approved users are pre-authorized, só entra quem tiver o Profile ou Permission Set correto explicitamente vinculado ao app. Todo o resto recebe esse erro na cara, mesmo com senha certa e MFA passando limpo.
O que está por trás do erro
Existem duas configurações possíveis de Permitted Users em um Connected App:
- All users may self-authorize: qualquer usuário autenticado no org consegue autorizar o app na primeira vez que acessa. É a opção padrão e mais permissiva.
- Admin approved users are pre-authorized: só quem estiver associado via Profile ou Permission Set consegue entrar, sem tela de autorização, sem margem de negociação. É o modo restritivo, pensado para ambientes que querem controle fino sobre quais apps externos tocam nos dados do org.
Quando alguém troca de "self-authorize" para "admin approved" (às vezes um admin de segurança faz isso numa varredura de hardening sem avisar o time), todo mundo que já usava o Workbench perde acesso instantaneamente, a não ser que já tenha permissão explícita. É basicamente isso que acontece na dúvida relatada: o usuário provavelmente nunca teve o Profile ou Permission Set do Workbench liberado, e a política do Connected App está travada em modo restritivo.
O segundo problema: reset de senha quebrado
Tem um detalhe author que complica ainda mais o cenário: ao tentar resetar a senha numa aba anônima, o usuário recebe "Your account isn't set up yet". Isso é sintoma de outra coisa completamente diferente, não tem relação direta com o Connected App. Geralmente indica que o usuário foi criado mas nunca ativou a conta (o e-mail de ativação não foi processado, ou o usuário está com status "Inactive" no cadastro), ou que o Federation ID / SSO está configurado e a plataforma está tentando redirecionar o fluxo de senha para um provedor externo que não existe para aquele usuário.
São dois problemas de naturezas distintas acontecendo ao mesmo tempo, e é importante não misturar o diagnóstico: um é OAuth policy do Connected App, o outro é o próprio ciclo de vida do usuário no org.
Como corrigir
- Confirme a política do Connected App: vá em Setup > App Manager, procure o Connected App do Workbench (ou Manage Connected Apps > OAuth Usage se ele ainda não aparecer na lista principal), e olhe o campo Permitted Users em Edit Policies.
- Decida entre liberar geral ou por permissão: se o org não tem exigência de compliance que justifique restrição, trocar para "All users may self-authorize" resolve na hora, mas isso reabre a porta para qualquer usuário autorizar o app sozinho. Não é a recomendação padrão para orgs de produção com dados sensíveis.
- Se manter restritivo, associe Profile ou Permission Set: a prática mais sã de arquitetura é criar um Permission Set dedicado (algo como "Workbench Access"), sem nenhuma outra permissão associada, e vincular esse Permission Set ao Connected App na seção Manage Permission Sets. Depois é só atribuir o Permission Set aos usuários que realmente precisam do Workbench.
- Resolva o problema de ativação de conta separadamente: verifique se o usuário está Active, se o e-mail de ativação foi reenviado, e se não há Federation ID configurado apontando para um IdP que o usuário não tem cadastro.
Visão de arquitetura
Esse é um padrão que se repete com qualquer Connected App de terceiros, não só Workbench: Data Loader, Postman configurado com OAuth, integrações via MuleSoft, apps do AppExchange que fazem chamada de API. Toda vez que a política vira "admin approved", o controle de acesso migra de "log in e usa" para "tem que estar no Profile ou Permission Set certo", e isso é bom para governança, mas péssimo para quem esquece de documentar quem precisa de quê.
Em orgs maduros, o recomendável é nunca deixar "All users may self-authorize" como padrão para ferramentas de acesso a dados como Workbench ou Data Loader. Trate cada Connected App sensível com o mesmo rigor que você trataria uma Sharing Rule em Experience Cloud: defina explicitamente quem entra, documente o motivo, e revise periodicamente quem ainda precisa daquele Permission Set. É simples de implementar e evita o susto recorrente de "o Workbench parou de funcionar do nada".
Esse erro aparece toda semana em fóruns porque a maioria dos admins não sabe que Workbench, Data Loader e qualquer app OAuth externo dependem de uma política de Connected App que pode mudar sem aviso. Entender a diferença entre self-authorize e admin approved evita perda de tempo em diagnóstico errado e evita que times de suporte tratem isso como problema de senha.
Análise baseada em documentação oficial de Connected Apps do Salesforce Help e em padrões conhecidos de configuração de OAuth Policies. O cenário relatado combina dois problemas distintos (Connected App e ativação de usuário), e a resolução de cada um segue caminhos de configuração padrão da plataforma.
Antes de mexer em qualquer política, confirme no Setup > App Manager qual é a configuração atual de Permitted Users do Connected App em questão. Se a decisão for manter o modo restritivo, crie um Permission Set dedicado e vazio de permissões, associe ao Connected App via Manage Permission Sets, e distribua para os usuários certos. Trate o problema de reset de senha como um caso separado de ativação de usuário ou configuração de SSO.
Trocar para 'All users may self-authorize' resolve rápido mas remove uma camada de controle que pode ter sido colocada de propósito por segurança. Antes de reverter a política, converse com quem é dono da governança de segurança do org. Vale lembrar também que o aviso da própria Salesforce é claro: mudar de self-authorize para admin approved revoga acesso de quem já usava o app, então qualquer alteração de política deve ser comunicada ao time antes de ser aplicada.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.