Por que seu produto precisa de OAuth 2.0 e OIDC — Especialmente na era da IA

Desde o início, o Logto foi construído com uma forte crença em padrões abertos. Escolhemos seguir protocolos como OIDC, OAuth 2.0 e SAML — não apenas porque são amplamente utilizados, mas porque representam práticas bem estabelecidas e seguras, confiáveis em toda a indústria. A segurança sempre foi uma prioridade para nós. Assim como permanecer fiel ao espírito de código aberto e aderir às melhores práticas em Gerenciamento de Identidade do Cliente e autenticação moderna.

Mas também aprendemos algo ao longo do caminho:

OAuth 2.0 e OIDC não são fáceis para todos. Para desenvolvedores que são novos nesses protocolos, os conceitos podem parecer estranhos e, às vezes, até contraditórios. Isso levou a desafios reais enquanto trabalhávamos para simplificar a experiência do desenvolvedor sem comprometer a segurança.

Duas coisas se destacaram:

1. Mesmo que tenhamos trabalhado arduamente para tornar a integração o mais suave possível, ainda há uma curva de aprendizado em torno da compreensão de conceitos básicos como tokens de ID, tokens de acesso e como eles funcionam.
2. Uma pergunta comum que recebemos é: “Posso pular o redirecionamento na tela de login?” Infelizmente, o redirecionamento é uma parte essencial de como o OIDC funciona e é necessário para a autenticação segura.

Uma pergunta comum dos nossos usuários do Discord (com seu ID e avatar obfuscados para privacidade).

Toda decisão vem com trade-offs — mas às vezes, uma escolha que você fez no início acaba sendo especialmente valiosa à medida que novos casos de uso surgem. E agora estamos entrando em uma nova era: a era da IA.

Neste artigo, explorarei quando seu produto deve usar OIDC e OAuth 2.0, quando talvez não precise deles, e por que sempre defendi a adoção desses padrões abertos desde o início — especialmente se você está construindo um negócio real e escolhendo uma solução CIAM. Também explicarei por que o surgimento da IA torna essa decisão mais importante do que nunca.

O que o OAuth 2.0 realmente faz (com uma analogia simples)#

Para leitores que não estão muito familiarizados com o OAuth 2.0, deixe-me aproveitar um momento para revisar brevemente alguns dos conceitos básicos novamente — só para tornar as coisas mais claras.

OAuth 2.0 é para autorização delegada: OAuth 2.0 é um protocolo padrão da indústria para autorização — permite que um serviço acesse recursos em nome de outro serviço com o consentimento do proprietário do recurso.

Em um cenário OAuth, o usuário (proprietário do recurso) concede a um aplicativo cliente acesso limitado (permissões específicas) a uma API ou servidor de recursos, sem compartilhar sua senha. O OAuth define como solicitar e emitir tokens de acesso que o cliente pode usar para chamar APIs protegidas. Isso foi um divisor de águas em comparação aos primeiros dias, quando os aplicativos poderiam pedir suas credenciais para acessar outro serviço (um sério risco de segurança). Com o OAuth 2.0, os usuários aprovam acessos específicos e o cliente recebe um token com apenas as permissões e duração necessárias — nenhuma senha é trocada, melhorando drasticamente a segurança.

Pense no OAuth 2.0 como fazer check-in em um hotel.

Você (o usuário) é o proprietário do quarto (seus dados). Mas, em vez de dar a alguém a chave do seu quarto (sua senha), você vai até a recepção e pede um cartão de acesso temporário (um token de acesso) que só funciona para seu hóspede ou amigo entrar na academia ou piscina — não no quarto todo.

A equipe do hotel (sistema OAuth) emite este cartão limitado com regras específicas:

• Ele só funciona para a academia (recurso específico).
• É válido por um curto período de tempo.
• Não permite que ninguém entre no seu quarto.

Dessa forma, você não precisa entregar sua chave mestra — e o sistema permanece seguro, mesmo que alguém mais consiga aquele cartão limitado.

Vamos dar uma olhada em outro exemplo. O OAuth 2.0 é amplamente utilizado no cenário de login social.

Vamos supor que você está se inscrevendo em um novo aplicativo como o Notion e, em vez de criar um novo nome de usuário e senha, você clica em “Continuar com o Google.”

Aqui está o que acontece por trás dos bastidores com o OAuth 2.0:

1. Você é redirecionado para a página de login do Google, onde você faz login (se ainda não estiver logado).

2. O Google pergunta:

   “Você permite que este aplicativo visualize seu perfil básico e endereço de e-mail?”

3. Você clica em “Permitir”, e o Google envia ao aplicativo um token de acesso.

4. O aplicativo usa esse token para:

   • Confirmar sua identidade (por meio do seu e-mail e informações de perfil).
   • Criar ou fazer login em uma conta — sem nunca ver sua senha do Google.

O que o OIDC realmente faz (com uma analogia simples)#

Agora vamos dar uma olhada no OIDC — um padrão mais recente e avançado. OpenID Connect visa Identidade e Autenticação: é uma camada de autenticação construída sobre o OAuth 2.0. Enquanto o OAuth 2.0 sozinho não informa ao aplicativo quem é o usuário (é apenas sobre tokens de acesso e escopos), o OIDC adiciona uma maneira padrão de lidar com o login e identidade do usuário.

Ao usar o OIDC, o servidor de autorização também atua como um Provedor OpenID (um Provedor de Identidade) que autentica o usuário e emite um token de ID contendo informações sobre o usuário (as “declarações de identidade”).

Em resumo, OAuth 2.0 responde a “Este cliente pode acessar este recurso?” e OIDC responde a “Quem é o usuário que acabou de fazer login?”. Juntos, eles permitem que seu aplicativo verifique a identidade do usuário e use tokens autorizados para acessar APIs em nome do usuário.

Vamos usar a Analogía do Hotel para entender melhor o OAuth 2.0 vs. OIDC novamente.

Imagine que você está fazendo check-in em um hotel.

• OAuth 2.0 é como pedir ao hotel para permitir que seu amigo use a academia e a piscina em seu nome.

  Você vai até a recepção, dá permissão, e o hotel dá ao seu amigo um passe de hóspede.

  O hotel não se importa quem é o amigo — apenas que ele está autorizado a usar as instalações.

  👉 Isso é OAuth: “Este aplicativo pode acessar alguns dos meus dados ou serviços.”

• OIDC é como pedir ao hotel para verificar quem é a pessoa antes de conceder acesso a ela.

  Então, seu amigo também mostra um cartão de identificação — e agora o hotel sabe seu nome, status e que ele é um hóspede verificado.

  👉 Isso é OIDC: “Aqui está quem é o usuário, e ele já está logado.”

Como o Logto usa OAuth 2.0 e OpenID Connect (OIDC)#

As funcionalidades principais de autenticação do Logto são construídas sobre o OIDC (OpenID Connect)#

Em sua essência, o Logto é um provedor OpenID Connect (OIDC) — um padrão construído sobre o OAuth 2.0 que foca em autenticação de usuário segura e moderna. O Logto é uma solução CIAM profissional, onde as identidades são os blocos de construção principais que gerenciamos.

Projetamos o Logto com a segurança como fundação. Isso significa impor PKCE por padrão, bloquear fluxos inseguros como o fluxo implícito e confiar em redirecionamento para lidar com logins de forma segura.

Por que redirecionar?#

OIDC é destinado para autenticação baseada em navegador. Não é apenas uma escolha técnica — trata-se de oferecer aos usuários uma experiência segura e consistente em todas as plataformas. Redirecionar o usuário ao provedor de identidade (como Logto, Google ou Microsoft) ajuda a tornar isso possível.

Veja como é o fluxo típico:

1. Usuário clica em “Entrar”

   → Seu aplicativo os envia para a página de login do Logto.

2. Eles fazem login com segurança

   → É aqui que ocorrem coisas como MFA, biometria ou logins sociais.

3. O Logto os envia de volta

   → Junto com um token seguro ou código de autorização.

4. Seu aplicativo completa o login

   → O token é verificado e o usuário está logado.

Este padrão pode parecer simples, mas traz benefícios poderosos:

• Seu aplicativo não lida com credenciais diretamente — o que significa menos riscos.
• É mais fácil adicionar recursos como MFA sem alterar o código do aplicativo.
• Funciona muito bem para dispositivos móveis também:
  • iOS usa ASWebAuthenticationSession
  • Android usa Custom Tabs

E se seu produto abrange vários aplicativos, o Redirecionamento permite single sign-on — usuários fazem login uma vez e se movem entre os aplicativos sem atrito.

O Logto não suporta a coleta de senhas diretamente em seu aplicativo. Isso é intencional. O fluxo ROPC não é recomendado para as melhores práticas de segurança do OAuth 2.0 por boas razões — é menos seguro e mais difícil de escalar com segurança.

O Logto também é um provedor OAuth 2.0/OIDC (Provedor de Identidade)#

O Logto é mais do que apenas um servidor de autenticação — é um completo OAuth 2.0, OpenID Connect (OIDC) e Provedor de Identidade (IdP). Isso significa que ele pode gerenciar identidades de usuário com segurança e emitir tokens que outras aplicações podem confiar.

Além de alimentar experiências de login para seus próprios aplicativos, o Logto também suporta integrações de aplicativos de terceiros, permitindo que serviços externos confiem no Logto como sua fonte de identidade.

O que isso significa na prática?

Como um Provedor de Identidade (IdP), o Logto lida com verificação de usuário, gerencia credenciais e emite tokens de autenticação. Uma vez que um usuário faz login, o Logto pode permitir que ele acesse diferentes aplicativos — mesmo de outros fornecedores — sem precisar fazer login novamente. É o mesmo conceito por trás de “Entrar com o Google” ou “Entrar com a Microsoft”.

Existem dois tipos de aplicativos neste contexto:

• Aplicativos de primeira parte: Aplicativos que você constrói e controla totalmente, integrados diretamente ao Logto.
• Aplicativos de terceiros: Serviços externos construídos por parceiros ou desenvolvedores fora da sua organização.

O Logto permite que seus usuários façam login nesses aplicativos de terceiros usando suas contas Logto existentes — assim como usuários empresariais fazem login em ferramentas como o Slack com suas credenciais do Google Workspace. Isso permite que você:

• Ofereça single sign-on (SSO) em todo o seu ecossistema.
• Construa uma plataforma aberta, onde desenvolvedores de terceiros podem adicionar “Entrar com Logto” aos seus aplicativos.

Quando você realmente precisa de OAuth 2.0 e OIDC?#

1. Se você está usando Auth0 (ou similar): Auth0 já é um provedor OAuth 2.0 e OIDC. Ele gerencia login de usuário, emissão de tokens e se integra aos seus APIs ou aplicativos.
2. Autorização M2M: Servidor para servidor (fluxo de credenciais de cliente) Máquinas (ou serviços de backend) precisam se comunicar com segurança sem um usuário.
3. Fluxo de dispositivo: Smart TVs, consoles, dispositivos IoT: Dispositivos como TVs ou impressoras precisam autenticar um usuário. O fluxo de dispositivo é parte do OIDC.
4. Você tem necessidades de integração: Você não está apenas autenticando usuários — você está criando um ecossistema onde aplicativos externos, parceiros ou agentes podem se integrar à sua plataforma e acessar dados de usuários com segurança.

Por que o OAuth e o OIDC são mais importantes do que nunca na era da IA#

Na era da IA, estamos vendo um aumento de novas necessidades de integração e acesso — especialmente em áreas como agentes autônomos, dispositivos inteligentes e comunicação entre sistemas. Essas tendências estão tornando o OAuth 2.0 e o OIDC mais importantes do que nunca. Aqui estão alguns exemplos:

1. Servidores MCP remotos

   Você constrói um servidor MCP (Model Context Protocol) remoto e deseja que agentes de terceiros se conectem a ele. Esses agentes precisam de acesso seguro para solicitar contexto, realizar ações e trocar dados — tudo sem comprometer a confiança do usuário. OAuth fornece o mecanismo para delegar acesso com segurança.

2. Abrindo seu produto para integrações

   Você gerencia seus próprios serviços de negócios — digamos uma ferramenta de gerenciamento de projetos ou uma plataforma de clientes — e você quer permitir que outros produtos ou agentes se integrem a ela. Isso pode significar puxar dados, disparar fluxos de trabalho ou incorporar suas funcionalidades em outros ambientes. OAuth 2.0/OIDC permite controle de acesso baseado em tokens, sem compartilhar credenciais de usuário.

3. Construindo seu próprio agente

   Você está criando um agente ou assistente de IA e deseja que ele interaja com outros aplicativos e servidores MCP — agendando reuniões, enviando e-mails, postando atualizações ou consultando dados. Isso requer acesso seguro e autenticado a serviços de terceiros. OAuth 2.0 é como seu agente é autorizado a agir em nome do usuário.

4. O surgimento de dispositivos inteligentes

   Dispositivos de hardware como tradutores de IA ou registradores de notas de reuniões inteligentes estão se tornando mais capazes graças aos LLMs. E com menor custo e maior desempenho, mais desses dispositivos estão chegando ao mercado. Esses dispositivos frequentemente precisam de uma maneira de autenticar usuários e acessar serviços em nuvem — especialmente com interfaces de entrada limitadas. É aí que fluxos como o fluxo de autorização de dispositivos do OAuth e a validação de identidade baseada em OIDC se tornam críticos.

Quando você pode não precisar de OAuth 2.0/OIDC#

Claro, há casos em que você pode não precisar de OAuth 2.0 ou OIDC — pelo menos não agora. Em outras palavras, se seu caso de uso atual é simples ou totalmente autônomo, esses protocolos podem não trazer valor imediato.

No entanto, à medida que seu produto cresce ou seu ecossistema se expande, a necessidade de OAuth 2.0 e OIDC muitas vezes se torna muito mais evidente a longo prazo.

1. Aplicativos simples e internos

   Se seu aplicativo é usado apenas por uma pequena equipe dentro de uma empresa e não precisa se integrar com serviços de terceiros ou expor APIs, um sistema básico de autenticação por nome de usuário e senha (por exemplo, sessões de cookies) pode ser suficiente.

2. Nenhuma autenticação do usuário necessária

   Se seu produto não possui contas de usuário ou funcionalidades cientes de identidade — como um site de conteúdo público — ou uma ferramenta de servidor para servidor com chaves de API estáticas — o OIDC não é necessário.

3. Nenhum acesso delegado requerido

   OAuth é ideal quando você precisa que os usuários autorizem seu aplicativo a acessar seus dados em outro sistema (por exemplo, Google Drive). Se você não está se integrando com APIs de terceiros ou construindo fluxos de trabalho multi-serviço, o OAuth adiciona complexidade com pouco valor.

4. Ambiente único, risco mínimo

   Para protótipos de estágio inicial, MVPs ou ferramentas de teste internas, onde simplicidade e velocidade superam as necessidades de segurança, você pode adiar a implementação de OAuth/OIDC para mais tarde.

Considerações finais sobre a escolha da estratégia de autenticação correta#

Você pode não precisar de OAuth 2.0 ou OIDC imediatamente — e está tudo bem. Nos estágios iniciais, soluções simples costumam dar conta do recado. Mas à medida que seu produto cresce, à medida que agentes e IA se tornam mais integrados à forma como construímos, e à medida que seu ecossistema se abre para parceiros e terceiros, a autenticação segura e padronizada se torna menos uma vantagem e mais uma necessidade.

Em vez de correr atrás depois, vale a pena estabelecer a base agora. Adotar OAuth 2.0 e OIDC não é apenas sobre resolver os problemas de hoje — é sobre estar pronto para o que vem a seguir.