Por que o 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 só 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 open source e aderir às melhores práticas em Gestão de Identidade do Cliente e autenticação moderna.

Mas também aprendemos algo pelo 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é contraintuitivos. Isso levou a desafios reais enquanto trabalhávamos para simplificar a experiência do desenvolvedor sem comprometer a segurança.

Dois pontos chamaram a atenção:

1. Mesmo que tenhamos trabalhado arduamente para tornar a integração o mais suave possível, ainda há uma curva de aprendizado para entender 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 fundamental de como o OIDC funciona e é necessário para autenticação segura.

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

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

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

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

Para os leitores que não estão muito familiarizados com o OAuth 2.0, deixe-me reservar um momento para recapitular alguns dos conceitos básicos novamente — apenas 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 restritas) a um servidor de API ou recurso, sem compartilhar sua senha. 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 com os primeiros dias quando os aplicativos podiam 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 apenas com as permissões e duração necessárias – nenhuma senha é trocada, melhorando dramaticamente a segurança.

Pense no OAuth 2.0 como se estivesse fazendo check-in em um hotel.

Você (o usuário) é o proprietário do quarto (seus dados). Mas em vez de dar a alguém sua chave do quarto (sua senha), você vai até a receção e pede um cartão de acesso temporário (um token de acesso) que só funciona para seu convidado ou amigo entrar na academia ou na 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.
• Não permite que ninguém entre no seu quarto.

Dessa forma, você não precisa entregar sua chave mestre — e o sistema permanece seguro, mesmo se alguém conseguir esse cartão limitado.

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

Vamos supor que você esteja 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 das cortinas com o OAuth 2.0:

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

2. O Google pergunta:

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

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

4. O aplicativo usa esse token para:

   • Confirmar sua identidade (através do seu e-mail e informações de perfil).
   • Criar ou entrar em uma conta — sem nunca ver sua senha do Google.

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

Agora vamos dar uma olhada no OIDC — um padrão mais novo 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 diz 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 a 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 “alegações de identidade”).

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

Vamos usar a Analogia 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 deixar seu amigo usar a academia e a piscina em seu nome.

  Você vai até a receção, dá permissão, e o hotel dá ao seu amigo um passe de convidado.

  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 dar a ela acesso.

  Então seu amigo também mostra um cartão de identificação — e agora o hotel conhece o nome dele, status, e que ele é um convidado verificado.

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

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)#

No seu núcleo, o Logto é um provedor de OpenID Connect (OIDC) — um padrão construído sobre o OAuth 2.0 que se concentra na autenticação segura e moderna do usuário. O Logto é uma solução CIAM profissional, onde identidades são os blocos de construção centrais que gerimos.

Desenhamos o Logto com a segurança como base. Isso significa aplicar PKCE por padrão, bloquear fluxos inseguros como o implicit flow, e confiar em redirecionamento para tratar com segurança as entradas.

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 para o 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 o envia para a página de login do Logto.

2. Eles entram com segurança

   → Aqui é onde coisas como MFA, biometria, ou logins sociais acontecem.

3. 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á conectado.

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

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

E se seu produto abrange vários aplicativos, o Redirecionamento permite sign-on único — os usuários entram uma vez e se movem entre 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 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 com segurança identidades de usuários 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 trata da verificação do 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”.

Há dois tipos de aplicativos neste contexto:

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

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

• Ofereça sign-on único (SSO) em todo o seu ecossistema.
• Construa uma plataforma aberta, onde desenvolvedores 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 logins de usuários, emissão de tokens, e integrações com suas APIs ou aplicativos.
2. Autorização M2M: Server-to-server (flow de credenciais de cliente) Máquinas (ou serviços de backend) precisam se comunicar com segurança sem um usuário.
3. Flow de dispositivo: Smart TVs, consoles, dispositivos IoT: Dispositivos como TVs ou impressoras precisam autenticar um usuário. O flow de dispositivo faz parte do OIDC.
4. Você tem necessidades de interação: Você não está apenas autenticando usuários — está criando um ecossistema onde aplicativos externos, parceiros, ou agentes podem se integrar à sua plataforma e acessar dados de usuário 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 das novas necessidades de integração e acesso — especialmente em áreas como agentes autônomos, dispositivos inteligentes, e comunicação sistema-a-sistema. 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 (Protocolo de Contexto de Modelo) 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 isso sem comprometer a confiança do usuário. O OAuth fornece o mecanismo para delegar o 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 gestão de projetos ou uma plataforma de cliente — e deseja permitir que outros produtos ou agentes se integrem a ela. Isso pode significar puxar dados, acionar fluxos de trabalho, ou incorporar seus recursos em outros ambientes. O OAuth 2.0/OIDC permite controle de acesso baseado em tokens, detalhado, sem compartilhar credenciais do 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. O OAuth 2.0 é como o seu agente é autorizado a agir em nome do usuário.

4. A ascensão dos dispositivos inteligentes

   Dispositivos de hardware como tradutores de IA ou tomadores de notas inteligentes estão se tornando mais capazes graças aos LLMs. E com um custo mais baixo e desempenho superior, mais desses dispositivos estão chegando ao mercado. Esses dispositivos frequentemente precisam de uma forma de autenticar usuários e acessar serviços baseados em nuvem — especialmente com interfaces de entrada limitadas. É aqui que fluxos como o flow de autorização de dispositivo do OAuth e a validação de identidade baseada no OIDC tornam-se críticos.

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

Claro, há casos onde você pode não precisar de OAuth 2.0 ou OIDC — pelo menos não agora. Em outras palavras, se o seu caso de uso atual é simples ou totalmente auto-contido, 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 aparente a longo prazo.

1. Aplicativos simples, internos

   Se o seu aplicativo é usado apenas por uma pequena equipe dentro de uma empresa e não precisa integrar-se 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 cookie) pode ser suficiente.

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

   Se seu produto não tem contas de usuário ou recursos sensíveis à identidade — como um site de conteúdo público ou uma ferramenta de servidor a servidor com chaves de API estáticas — OIDC não é necessário.

3. Nenhum acesso delegado necessário

   OAuth brilha 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á integrando com APIs de terceiros ou construindo fluxos de trabalho de múltiplos serviços, 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 a simplicidade e a velocidade superam as necessidades de segurança, você pode adiar a implementação de OAuth/OIDC para mais tarde.

Pensamentos finais sobre escolher a estratégia de autenticação certa#

Você pode não precisar de OAuth 2.0 ou OIDC imediatamente — e isso é completamente normal. Nos estágios iniciais, soluções simples muitas vezes cumprem o papel. 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 algo positivo a mais e mais uma necessidade.

Em vez de jogar para alcançar mais tarde, vale a pena lançar as bases agora. Adotar OAuth 2.0 e OIDC não é apenas sobre resolver problemas de hoje — é sobre estar pronto para o que vem a seguir.