O que é OAuth 2.0 e como conecta aplicações sem compartilhar senhas?
Publicado em 2026-10-20 por frfrand
OAuth 2.0 explicado con un ejemplo de permisos delegados, scopes, redirecciones y diferencias entre autorización e identidad.
OAuth 2.0 é um framework para conceder acesso limitado a um aplicativo sem entregar diretamente as credenciais da sua conta em outro serviço. Por isso aparece quando você quer vincular um calendário, armazenamento ou sistema externo com uma ferramenta que utiliza.
Não é simplesmente um botão de «iniciar sessão com o Google». Também existem fluxos de OAuth utilizados para autorizar acesso a APIs.
O exemplo de um manobrista
Imagine que deixa seu carro em um estacionamento. Em vez de entregar todas as chaves da sua casa ao pessoal, entrega uma chave que serve para uma função específica.
OAuth busca um objetivo similar: autorizar operações específicas durante certo escopo e condições, sem compartilhar a senha principal com o aplicativo que solicita acesso.
A comparação é imperfeita, porque os tokens podem ser copiados se vazarem e cada provedor estabelece suas próprias regras.
Como costuma funcionar?
Um aplicativo quer consultar seu calendário. Ele te redireciona ao serviço que administra a conta. Lá você faz login, se necessário, e revisa qual acesso está sendo solicitado.
Se você autorizar, o aplicativo pode receber um código de autorização e trocá-lo de forma segura por credenciais de acesso de acordo com o fluxo implementado. O token obtido permite chamar uma API dentro das permissões concedidas.
No fluxo moderno de código de autorização, costuma-se utilizar PKCE, que adiciona uma proteção importante, especialmente para clientes públicos.
O que é um escopo?
Um escopo indica um alcance de autorização definido pelo serviço. Por exemplo, uma integração pode solicitar ler eventos de calendário em vez de pedir acesso a todos os recursos.
Pedir menos permissões é uma boa prática. Não faz sentido solicitar capacidade de excluir arquivos quando a integração apenas precisa listar nomes.
Mas os escopos não substituem todas as verificações de segurança da API. Cada provedor deve validar, além disso, quais recursos reais o titular pode consultar.
OAuth não é o mesmo que OpenID Connect
Aqui aparece uma confusão comum. OAuth se concentra em autorização delegada. OpenID Connect utiliza OAuth 2.0 como base e adiciona uma camada de identidade para que um aplicativo possa autenticar o usuário.
Por isso não convém tomar um token de acesso de qualquer serviço e usá-lo como se demonstrasse por si mesmo a identidade de uma pessoa perante seu aplicativo.
Quais riscos existem?
Uma URL de redirecionamento mal validada pode permitir enviar códigos para um destino indevido. Um token roubado pode ser utilizado dentro de seu alcance enquanto estiver válido. Pedir permissões excessivas aumenta o impacto de uma comprometimento.
As implementações modernas precisam proteger state quando for o caso, utilizar PKCE nos fluxos adequados, validar redirecionamentos e armazenar tokens de forma segura. Não basta copiar uma URL de um tutorial.
E o refresh token?
Alguns provedores entregam credenciais que permitem obter novos tokens de acesso sem repetir toda a interação. Nem todos os fluxos as utilizam nem têm as mesmas políticas.
Devem ser protegidas especialmente: se alguém obtiver um refresh token válido, pode prolongar o acesso de acordo com as regras do provedor. Convém verificar revogação, rotação e expiração.
Um caso de uso real
Imagine um assistente que ajuda a organizar reuniões e precisa consultar sua disponibilidade. Com um fluxo correto de OAuth, você pode autorizar acesso à sua agenda sem dar ao assistente sua senha principal.
Se depois você parar de usar esse aplicativo, deverá poder revogar o acesso da conta do provedor quando ele permitir.
Qual a relação com o ArduMaker?
Ao conectar contas externas ou integrar uma ferramenta com serviços gerenciados pelo ArduMaker, o OAuth pode ser uma opção quando o provedor o suportar. O objetivo deve ser conceder apenas as capacidades necessárias, com autorização explícita e revogável.
Em uma frase: OAuth permite delegar acesso limitado. Não elimina a necessidade de proteger tokens nem substitui uma política de permissões bem projetada.
Fontes: RFC 6749, OAuth 2.0 · RFC 7636, PKCE · OpenID Connect.