Você está pagando aluguel pela porta de entrada do seu produto. Esse aluguel aumenta aos poucos. O proprietário troca as fechaduras. E quando o prédio fica no escuro, você também fica. Com a Cloudflare ampliando as opções de OAuth autogerenciado e as passkeys agora nativas em quase todos os dispositivos que seus clientes usam, 2026 é a primeira janela sensata para retomar o controle da sua camada de identidade—sem acionar o PagerDuty.
Por que agora: três forças de pressão que você não pode ignorar
- Volatilidade de fornecedores e lock-in são reais. Os preços de CIAM têm subido, recursos corporativos estão cada vez mais atrás de paywalls e as indisponibilidades continuam acontecendo. Se sua tela de login é um widget de terceiros, seu uptime e seu roadmap não são seus. Você precisa de uma estratégia de saída do IdP.
- A Cloudflare baixou a barreira de entrada. Com seu anúncio recente tornando OAuth/OIDC autogerenciado acessível a mais times, o edge agora também funciona como ponto de controle de identidade. Quer você termine o OAuth no edge ou encaminhe para o seu próprio IdP, a sustentação operacional ficou mais simples.
- Passkeys finalmente se tornaram mainstream. Autenticadores de plataforma estão amplamente disponíveis em iOS, Android, macOS e Windows. O suporte a FIDO/WebAuthn cobre agora a grande maioria de navegadores e dispositivos modernos. Isso se traduz em menos tickets de suporte e menos contas comprometidas—se você realmente lançar isso.
Em outras palavras: o gap tecnológico que justificava terceirizar identidade para a maioria dos produtos B2B/B2C diminuiu. O risco de negócio de continuar alugando a superfície mais estratégica do seu stack aumentou.
Você deve internalizar o OAuth em 2026? Um framework de decisão
Internalizar identidade não é dogma. Use este filtro para decidir.
Sinal verde (considere fortemente internalizar) se você tem:
- Consumer em grande escala ou B2B para SMB (≥ 200k MAU) em que preços por usuário ativo ou bloqueio de recursos prejudicam a economia unitária.
- SaaS multi-tenant com bring-your-own-IdP (OIDC/SAML) e necessidades de autorização de granulação fina. Você vai querer controle de primeira parte sobre scopes, claims e tempos de vida de tokens.
- Requisitos de postura de segurança além dos padrões do fornecedor (DPoP, PAR, rotação de refresh tokens, autenticação step-up). Se você é regulado, acabará assumindo essa responsabilidade de qualquer forma.
- Capacidade interna para dedicar 0,5–1,0 FTE de engenheiro sênior para operar o IdP e 0,25–0,5 FTE de SRE para HA/DR após o go-live. Esse é o estado estável realista.
Sinal amarelo (híbrido recomendado) se você tem:
- Requisitos de SSO corporativo em dezenas de IdPs de clientes (Okta, Entra, Ping), mas tráfego self-serve modesto. Mantenha um fornecedor para brokers SAML; assuma a autenticação do cliente para self-serve e tokens.
- Clientes fortemente mobile em que você não consegue migrar SDKs de uma vez. Use um proxy no edge para uma transição gradual.
Sinal vermelho (compre e siga em frente) se você tem:
- Certificações complexas (FedRAMP High, PCI L1 como merchant, residência de dados por região por tenant) sem apetite para operar HSMs/KMS por região.
- Sem banda para operar um datastore de identidade seguro e em HA (Postgres multi-região ou CockroachDB + KMS + rotação de segredos). Identidade ou é entediante ou é um incêndio. Não existe meio-termo.
Opções de arquitetura que não vão explodir seu roadmap
Opção A: OAuth terminado no edge com um core autogerenciado
Use o edge (por exemplo, Cloudflare) como o limite de política e sessão. O edge:
- Lida com redirects OAuth/OIDC, mitigação de bots, pontuação de risco/geo e sinais de dispositivo.
- Injeta headers de identidade verificada ou um token de sessão assinado no seu app.
- Encaminha emissão/validação de tokens para o seu IdP (Keycloak, ZITADEL, ORY) nos bastidores.
Por que isso funciona: você mantém o código do app simples (procura por headers ou um cookie assinado), ganha benefícios de latência (checagens de token no edge) e pode trocar o IdP core depois sem alterar os contratos dos apps.
Opção B: IdP open source como sua fonte da verdade
Execute um IdP moderno sob seu controle:
- Keycloak para OIDC/SAML amplamente testado em produção, UI de administração e SCIM. Pesado, mas cheio de recursos.
- ZITADEL para CIAM multi-tenant, amigável à auditoria, com uma boa experiência para desenvolvedores.
- ORY Hydra/Kratos para fluxos componíveis se você quiser controlar o UX de perto.
- Authentik para times menores e setups mais simples.
Coloque-o atrás do seu edge com mTLS. Use Postgres gerenciado com réplicas de leitura entre regiões. Armazene chaves de assinatura em um KMS da nuvem. Publique JWKS em uma URL estável.
Opção C: Híbrido (mantenha o SSO de workforce, assuma a identidade de clientes)
Para SaaS B2B que vende para enterprises, mantenha o SSO da sua força de trabalho em um fornecedor. Internalizar identidade de workforce raramente tem ROI positivo. Mas assuma a identidade do seu cliente—tokens, scopes e passkeys—onde economia unitária e UX importam.
Como é o “bom” em 2026: um design de referência
Protocolos e fluxos
- OIDC com PKCE para todos os clients públicos (mobile, SPAs). Nunca use o implicit flow. Veja RFC 7636.
- DPoP para vincular tokens à chave do cliente e reduzir roubo de bearer. Veja RFC 9449. Já está maduro o suficiente para pilotar em APIs de alto risco.
- Pushed Authorization Requests (PAR) para manter parâmetros de requisição fora do front channel e endurecer contra mix-up e adulteração. Veja RFC 9126.
- Tokens de acesso curtos (5–10 min) com refresh tokens rotativos. Revogue em caso de reutilização.
- Logout por back-channel para apps server-side; front-channel para SPAs como melhor esforço. Planeje a invalidação de cache.
Passkeys e MFA
- Passkeys primeiro, senhas opcionais. Use credenciais detectáveis e verificação de usuário obrigatória. Veja WebAuthn L3.
- TOTP como único fallback. Elimine SMS. Mantenha magic links por e-mail apenas para recuperação de conta, com TTLs apertados (≤10 minutos) e vinculação ao dispositivo.
- Inscrição progressiva: aborde usuários de alta intenção durante fluxos de sucesso (pós-login, pós-compra), não aleatoriamente no sign-in.
- Step-up para ações de risco (pagamentos, rotação de chaves, mudanças de RBAC) exigindo uma asserção WebAuthn recente.
Multi-tenant e claims
- Clients OAuth por tenant com URIs de redirect e scopes isolados. Evite clients globais para SaaS B2B.
- Claims com namespace em ID tokens (por exemplo,
https://yourco.com/roles,https://yourco.com/tenant). Mantenha access tokens com escopo de audience. - SCIM + provisionamento JIT para tenants enterprise, mas deixe isso atrás de planos enterprise para manter o raio de explosão pequeno.
Operações e segurança
- HA/DR: primário multi-AZ, failover entre regiões testado trimestralmente. Chaves no KMS com réplicas por região. Gire chaves de assinatura a cada 90 dias; mantenha chaves antigas no JWKS com 7 dias de carência.
- Observabilidade: emita eventos de auth em JSON estruturado para seu SIEM. Acompanhe taxa de sucesso de login, latência mediana de autenticação de ponta a ponta, % de inscrição em passkeys, taxa de reutilização de refresh tokens e tempo de configuração de SSO por tenant.
- Test harness: uma suíte de navegador headless que executa fluxos comuns (login, vincular contas, inscrever passkey, revogar sessão) contra staging a cada deploy.
Um plano de migração pragmático que não quebra usuários
1) Faça o inventário e modele o raio de impacto
- Enumere cada client OAuth/OIDC: nome do app, tipo (SPA/nativo/web), URIs de redirect, scopes, audiences, versões de SDK, padrões de armazenamento de tokens.
- Mapeie dados de identidade: o que está nos perfis de usuário, onde vivem, quem escreve neles (marketing vs produto vs suporte) e o que você precisa preencher retroativamente.
- Estabeleça o baseline de KPIs: tentativas diárias de login, taxa de sucesso, tempo médio de autenticação de ponta a ponta, volume de reset de senha, incidentes de tomada de contas, tempo de vida do SSO.
2) Levante o novo IdP em paralelo
- Faça o deploy do IdP escolhido atrás do edge com um novo issuer versionado (por exemplo,
https://id-v2.yourco.com). - Espelhe conexões essenciais (e-mail, SMS se você ainda precisar para recuperação, WebAuthn, SCIM). Semear um pequeno conjunto de tenants piloto e suas próprias contas de workforce.
- Implemente vinculação de contas: quando o mesmo usuário faz login via o IdP antigo, emita um token de primeira parte e crie/vincule a identidade silenciosamente no novo IdP. Isso permite rodar em paralelo.
3) Lance passkeys como um “upgrade”, não como exigência
- Controle com feature flags. Comece com 5–10% do tráfego onde o suporte de dispositivo é maior (Chrome/Safari mais recentes em desktop/mobile).
- Ofereça uma inscrição com um clique após um sign-in bem-sucedido. Não bloqueie a tela de login com uma exigência de inscrição.
- Acompanhe a taxa de inscrição e os deltas de tempo de login. Espere que 20–40% dos usuários ativos inscrevam em até 90 dias se você pedir na hora certa e explicar o benefício.
4) Corte por estrangulamento, app por app
- Para apps server-rendered: mude o edge para validar contra o novo issuer, mantendo o IdP antigo como caminho de fallback por 1–2 semanas com logs.
- Para SPAs e mobile: envie atualizações de configuração de SDK para apontar para o novo issuer e exigir PKCE. Dê suporte a ambos os formatos de token durante um período de carência fazendo com que as APIs aceitem qualquer issuer no middleware de validação.
- Gire URIs de redirect por client e, em seguida, revogue o client antigo no IdP do fornecedor quando o volume de logs cair abaixo de 1% do baseline.
Os números: onde o ROI realmente aparece
- Latência: terminar checagens de auth no edge tipicamente corta 100–200 ms em relação a ir e voltar para um IdP em uma única região nos EUA para usuários globais. Isso gera aumento mensurável de conversão nos fluxos de login e checkout.
- Carga de suporte: com passkeys, espere uma queda material em tickets de “não consigo entrar”. Times reportam 20–50% menos pedidos de reset de senha após ampla adoção de passkeys. Seu delta exato depende da audiência e do quão agressivo você é ao remover senhas.
- Fraude e tomada de contas: passkeys mais DPoP reduzem significativamente credential stuffing e replay de bearer tokens. Mesmo uma pequena redução em ATO já paga a migração.
- Velocidade com enterprise: clients por tenant e claims com namespace reduzem o onboarding de SSO de semanas para dias. Se você fechar um negócio enterprise extra por trimestre, o projeto se paga.
Riscos e como contê-los
- Bloqueios de acesso: o risco existencial. Rode dark launches com tráfego espelhado e falhas simuladas. Mantenha um runbook para desabilitar DPoP/PAR por client se SDKs tiverem problemas.
- Gestão de chaves: perder chaves é perder o negócio. Armazene chaves de assinatura em KMS da nuvem com duplo controle, faça backup e documente rotação de emergência. Publique JWKS com TTLs controlados por cache.
- Proliferação de fallbacks: cada fallback é uma futura violação. Mantenha exatamente um fallback (TOTP). Trate magic links por e-mail apenas como recuperação.
- Superfície regulatória: internalizar significa que você é operador e controlador de mais campos. Minimize campos de perfil, defina TTLs de dados e logue acessos. Se você prometer residência de dados, verifique se o datastore do seu IdP e seus backups a impõem.
Build vs buy: uma comparação sóbria de TCO
Considere um SaaS B2B em estágio de crescimento com 300k MAU e SSO enterprise.
- Comprar (status quo): integração previsível, ganhos rápidos de SSO, mas custos por MAU/recurso crescentes e controle limitado sobre tokens, claims e UX. Você carrega risco de indisponibilidade do fornecedor e lock-in.
- Autogerir: espere 0,5–1,0 FTE de engenheiro sênior para operar o IdP e 0,25–0,5 FTE de SRE para HA/DR. Infra: duas instâncias médias de Postgres entre regiões, edge workers, métricas/alertas. Após estabilização, a velocidade contínua vira recursos que você quer (passkeys, step-up, DPoP) em vez de esperar um roadmap.
Vimos equipes atingirem o ponto de equilíbrio (breakeven) em 9–15 meses quando já têm infraestrutura de edge—e mais rápido se a economia unitária for sensível a taxas por usuário ativo. Se seu login é crítico para conversão (mídia consumer, onboarding em fintech), os ganhos de UX e latência sozinhos podem justificar a mudança.
O que entregar ao seu time na segunda-feira
- Escolha sua postura: Edge-terminated + core autogerenciado (A) ou híbrido (C) para a maioria dos SaaS B2B. Evite fluxos sob medida; fique com OIDC + PKCE.
- Escolha um IdP: ZITADEL para CIAM multi-tenant, Keycloak para amplitude de recursos, ORY se precisar de componibilidade. Decida esta semana; você pode trocar depois atrás do edge.
- Defina a política de tokens: tokens de acesso de 5–10 min, refresh tokens rotativos, audience scoping, claims com namespace, DPoP para APIs de alto risco, PAR para todos os clients confidenciais.
- Levante o staging: IdP + edge + Postgres em HA + KMS. Publique JWKS. Direcione logs para seu SIEM. Construa uma suíte de testes headless para auth.
- Adicione passkeys: implemente WebAuthn com credenciais detectáveis e verificação de usuário estrita. Mantenha TOTP como fallback. Planeje o UX de inscrição progressiva.
- Entregue uma ponte de vinculação de contas: aceite tokens do IdP antigo, emita sessões de primeira parte, crie identidades vinculadas no novo IdP em background.
- Pilote com contas internas e 1–2 tenants parceiros: meça latência de login, taxa de sucesso e inscrição. Corrija os incômodos.
- Migre apps de baixo risco primeiro: UI de admin server-rendered, depois SPA, depois mobile. Mantenha duas semanas de dupla aceitação de issuers na camada de API.
- Elimine fallbacks deliberadamente: remova senhas para coortes que já inscreveram passkeys. Aplique step-up em fluxos sensíveis.
- Escreva o runbook: rotação de chaves, rollback de emergência, checklist de cutover por tenant e um script de on-call para falhas generalizadas de login.
“E os logins sociais e o SSO enterprise?”
Mantenha-os. Seu IdP deve atuar como broker para provedores OIDC/SAML/sociais. Para B2C, social é um caminho de conveniência para trazer usuários; converta-os para passkeys no primeiro dia pós-login. Para B2B, o SSO corporativo permanece, mas faça da conexão de cada tenant um client de primeira classe com URIs de redirect e scopes isolados, para que a má configuração de um tenant não bloqueie os usuários de outro.
Alavancagem nearshore: como executar sem travar o produto core
É aqui que um pod nearshore experiente mostra seu valor. Dê a uma equipe de plataforma baseada no Brasil um charter claro: endurecer o edge, levantar o IdP, ligar passkeys e entregar o harness de migração sem rewrites de apps. Você preserva seus squads de produto core para o roadmap. Com 6–8 horas de overlap e menor TCO, você obtém um IdP seu sem um trimestre de congelamento de features.
Por onde começar a ler (e o que copiar, não inventar)
- O anúncio da Cloudflare expandindo o suporte a OAuth/OIDC autogerenciado para mais times é um sinal: o edge é seu novo limite de identidade. Use-o.
- Copie as especificações, não as reinterprete: PKCE, PAR, DPoP e WebAuthn.
- Escolha um IdP e entregue. Keycloak e ZITADEL têm defaults sensatos para OIDC, passkeys e multi-tenant.
Em resumo
Identidade é uma superfície de produto que você deveria possuir. Em 2026, as ferramentas, o suporte de navegador e as primitivas de edge finalmente estão boas o suficiente para que você possa. Se você ainda está alugando sua tela de login, comece a construir uma saída agora—antes que mudanças de preço ou uma indisponibilidade forcem sua mão.
Pontos-chave
- OAuth autogerenciado agora é prático: use o edge como limite de identidade e mantenha os apps simples.
- Lance passkeys como padrão; mantenha exatamente um fallback (TOTP). Espere menos resets e menos ATOs.
- Adote PKCE, PAR e DPoP. Tokens de acesso curtos com refresh tokens rotativos são o básico.
- Migre por estrangulamento por app, rode emissores em paralelo com logs e teste fluxos de ponta a ponta com navegadores headless.
- Assuma a identidade de clientes (CIAM); mantenha o SSO da força de trabalho em um fornecedor a menos que haja um forte motivo para não fazê-lo.
- Pods nearshore podem entregar o IdP e a integração no edge sem congelar as equipes de produto core.