Como escolher um provedor de identidade: O framework de avaliação da equipe de engenharia

A maioria dos artigos de comparação entre provedores de identidade são escritos pelos próprios provedores de identidade. Surpreendente, né? Eles listam as funcionalidades que o produto deles possui, pulam as que não tem e chamam isso de "guia objetivo".

Este não é esse caso.

Analisamos dezenas de solicitações de avaliação de empresas reais — as planilhas e documentos RFP que times de compras enviam para fornecedores. O padrão é claro: equipes de engenharia dão peso de menos para os critérios realmente importantes e peso demais para os menos relevantes.

O resultado? As equipes escolhem um IdP baseado numa demo, descobrem seis meses depois que a migração é um pesadelo e voltam a avaliar soluções de novo.

Aqui está o framework de avaliação que gostaríamos que tivessem nos dado antes de começarmos. Ele é feito para equipes de engenharia de empresas SaaS B2B — para quem está construindo produtos, não para quem está comprando SSO corporativo para funcionários.

Resposta rápida: O que define a decisão de um IdP#

Se você está só navegando, aqui vai o resumo:

1. A profundidade de protocolo conta mais que o número de funcionalidades. Dizer que suporta "OAuth2" não quer dizer quase nada. Quais tipos de grant? Dá para personalizar os claims do token? Você pode se tornar um provedor OIDC?
2. A capacidade de migração é o critério mais subestimado. Se você não consegue migrar seus usuários sem forçar reset de senha, o IdP é inutilizável — não importa o quão bom seja o resto.
3. Multi-tenancy tem que ser nativo, não um jeitinho. Se os modelos de organização e as configurações por tenant dependem de gambiarras, você vai lutar contra o sistema para sempre.
4. Prontidão para IA não é planejamento futuro — é necessidade para o próximo ano. Troca de tokens, identidade de agente, escopos delegados. Se o IdP não suporta isso, você estará reavaliando tudo de novo ano que vem.

O restante deste guia detalha cada dimensão de avaliação, com perguntas que você deve fazer e sinais de alerta para observar.

Para quem é este guia (e para quem não é)#

Este guia é para você se:

• Você é CTO, VP de Engenharia ou arquiteto de plataforma de uma empresa SaaS B2B com 50-300 pessoas
• Você tem mais de 100 mil usuários existentes e não pode se dar ao luxo de uma migração disruptiva
• Você está indo para o mercado enterprise, que exige SSO, modelos de organização e logs de auditoria
• Você precisa escrever um relatório técnico de avaliação e quer um framework que não venha de um fornecedor

Este guia NÃO é para você se:

• Você busca IAM corporativo (SSO de funcionários para ferramentas internas) — trata-se de outra decisão de compra
• Você lidera uma startup com 500 usuários e sem clientes enterprise — escolha qualquer um com o melhor SDK e siga em frente
• Você precisa de verificação de identidade (KYC/KYB) — é uma categoria totalmente separada

Dimensão 1: Capacidade de protocolos — Não é só "suporta OAuth2"#

Todo IdP do mercado vai dizer que suporta OAuth2 e OIDC. Isso é o básico. As perguntas reais são sobre profundidade.

Tipos de grant: Quais são e por que importam?#

Essenciais:

• Authorization Code + PKCE — O único fluxo que se deve usar para apps web e mobile. Se um fornecedor ainda recomenda Implicit Flow, fuja. PKCE não é opcional — é exigência de segurança.
• Client Credentials — Para comunicação entre serviços. Serviços de backend autenticam uns com os outros sem usuário presente.
• Refresh Token — Parece simples, mas os detalhes de implementação mudam muito. Dá para configurar rotação? Expiração? Dá para revogar um refresh token específico sem interromper toda a sessão?

Cada vez mais crítico:

• Token Exchange (RFC 8693) — É o grant que habilita autenticação de agentes IA, fluxos de impersonação e delegação. Se faltar hoje, pergunte sobre o roadmap. Se não houver roadmap, sinal de alerta.

Capacidade de prover OIDC#

Aqui vai a pergunta que poucos fazem: Dá para usar este IdP como um Provedor OIDC — e não só como consumidor?

Por que importa: conforme seu SaaS cresce, parceiros e clientes podem querer usar seu sistema de identidade para entrar nos próprios sistemas. Você precisa emitir tokens, gerenciar consentimento e lidar com registros de apps de terceiros. Se seu IdP só consome provedores externos, mas não atua como um, você vai bater num muro na hora de federar para fora.

Pergunte:

• O IdP disponibiliza um endpoint OpenID Discovery que pode ser white-label?
• Dá para registrar apps first-party e third-party com níveis de confiança diferentes?
• Apps internos podem pular a tela de consentimento, mas os externos são obrigados?

Personalização de JWT#

O token é o contrato entre seu IdP e seus serviços. Se você não pode personalizá-lo, todo serviço downstream terá de fazer chamadas extras para saber o que o usuário pode fazer.

Pergunte:

• Dá para adicionar claims customizados a access tokens e ID tokens?
• Dá para incluir o contexto da organização (qual tenant o usuário está usando) diretamente no token?
• Dá para definir escopos customizados que mapeiam o modelo de permissão do app?
• Os claims são computados na emissão do token ou podem ser preenchidos dinamicamente via webhook ou script?

Um token que carrega { "org_id": "org_123", "role": "admin", "auth_level": 2 } permite que seu middleware de API tome decisão de autorização em uma linha. Um token que só carrega { "sub": "user_456" } obriga todo serviço a consultar IdP ou banco de dados para descobrir o restante. Em escala, essa diferença representa de 2ms a 200ms por requisição.

Dimensão 2: Fluxos de autenticação — Os detalhes que complicam#

Todo IdP suporta e-mail/senha e login social. Parabéns, você reduziu o universo a... todos eles.

A diferenciação está nos detalhes que a maioria das demos ignora.

O fluxo de cadastro#

• Auto-login pós-cadastro: Após registrar, o usuário já está logado? Ou vê a tela de login de novo? Forçar login logo após cadastro mata conversão. Você ficaria surpreso com quantos IdPs erram aqui.
• Campos personalizados de registro: Dá para captar cargo, nome da empresa ou use case no cadastro? Ou precisa de onboarding separado depois?
• Profile progressivo: Dá para pedir mais informações em sessões futuras, não exigindo tudo de uma vez?

O fluxo de login#

• login_hint suportado: Quando um usuário clica num link do e-mail marketing, dá para pré-preencher o e-mail? Parece trivial, mas não é. É a diferença entre 40% e 60% de conversão.
• Políticas de autenticação por organização: A Org A pode exigir SAML SSO enquanto Org B usa e-mail/senha? Dá para exigir MFA só para enterprise? Se políticas precisam de código — e não só configuração — toda onboard de enterprise vira trabalho de engenharia.
• Customização da marca: Dá para customizar a experiência de login por tenant? Não só logo e cor — CSS completo, domínios customizados e e-mails white-label. "Hosted UI vs. bring your own UI" deve ser sua escolha, não uma limitação.

O que a maioria dos checklists ignora#

• Autenticação silenciosa: Quando o token expira, o app consegue renovar silenciosamente sem redirecionar o usuário? E se o refresh token também expirar — há fallback (tipo sessão deslizante via iframe)?
• Vinculação de contas: Usuário se cadastra com Google e depois tenta entrar por e-mail. São duas contas ou uma? Como o IdP lida com junção de identidades? Se errar, vai ter contas duplicadas para sempre.
• Opções sem senha: Magic links, passkeys, WebAuthn. Não porque todo mundo precisa hoje, mas clientes enterprise vão pedir em seis meses.

Dimensão 3: Gestão de sessão e tokens — Onde mora o perigo#

Aqui sua avaliação se separa da demo. Gestão de sessão e token é chato até quebrar — aí todo mundo se desloga de uma vez só.

Segurança de Cookie#

Nada glamouroso. Absolutamente crítico.

• HttpOnly, Secure, SameSite: Os três devem ser configurados corretamente. Qualquer IdP que não usa HttpOnly no cookie de sessão não está pronto para produção.
• Suporte entre subdomínios: Seu app está em app.seuproduto.com e sua API em api.seuproduto.com — as sessões abrangem subdomínios? Como?
• Fim dos cookies de terceiros: O Chrome vai matar isso. Como o IdP lida com autenticação cross-origin sem cookie de terceiros? Se a resposta for "estamos estudando isso", não é suficiente.

Lembre-me e sessões persistentes#

Usuários querem ficar logados por semanas, não minutos. Uma sessão de 180 dias tem implicações de segurança bem diferentes das de uma sessão de 30 minutos.

Pergunte:

• Dá para configurar a duração da sessão separada do tempo de vida do token?
• Tem opção "lembre-me" que estende sessão sem aumentar o tempo de token?
• Dá para exigir reautenticação para operações sensíveis sem terminar a sessão?

Segurança do refresh token#

• Rotação de tokens: O IdP rotaciona o refresh token em cada uso? (Deveria.)
• Armazenamento criptografado: Os refresh tokens ficam criptografados em repouso?
• Revogação granular: Dá para revogar a sessão de um dispositivo sem revogar todas?
• Expiração configurável: Apps diferentes precisam de lives diferentes para refresh tokens. Dá para configurar por aplicação ou só global?

Dimensão 4: Modelo de autorização — Além do RBAC básico#

Role-Based Access Control é o mínimo. Se o IdP não suporta RBAC, nem avalie. Mas para SaaS B2B, RBAC não basta.

Permissões com escopo de organização#

Seus usuários pertencem a organizações. As permissões dentro de cada organização são diferentes das permissões de nível de plataforma.

Um usuário pode ser admin na Org A e viewer na Org B. O mesmo usuário, dois contextos de roles. Se o IdP não modela isso nativamente, você terá que criar um sistema paralelo de permissões — e aí tem duas fontes de verdade.

Perguntas:

• Dá para definir roles no nível de organização, não só do usuário?
• Um usuário pode ter roles diferentes em organizações distintas?
• O contexto da organização aparece no token, para sua API saber onde o usuário está agindo?

Autorização multi-nível (auth_level)#

Para apps financeiros, saúde ou onde certas operações são críticas: nem toda sessão autenticada é igual.

Visualizar painel? Cookie de sessão basta. Iniciar transferência? Você precisa de MFA novo, mesmo já logado.

Isso se chama autenticação step-up, e exige que nível de autenticação (auth_level) seja um first-class citizen do sistema de tokens.

Pergunte:

• O token pode carregar um claim auth_level que o backend verifica?
• Dá para pedir step-up authentication no app sem forçar re-login total?
• O auth_level tem expiração independente da sessão?

Se o IdP não suporta isso nativamente, você vai acabar implementando sozinho — que é justamente o tipo de lógica de identidade que IdP deveria resolver por você.

Decisões de autorização baseadas em token#

O ideal: o middleware da API lê o token, vê org, role e nível e decide sem consultar mais ninguém.

O real em muitos IdPs: o token só diz quem é o usuário, mas você precisa de API externa para saber o que ele pode fazer.

Essa chamada extra aumenta latência, cria dependência e introduz risco de falha. Em 1.000 requisições/s, não dá para depender de rede para checar autorização.

Dimensão 5: Migração — O critério que decide tudo#

Uma estatística pouco falada: a maioria das avaliações de IdP acabam não porque o novo IdP não é bom, mas porque a equipe não consegue migrar eficazmente os usuários.

Se você tem 100 mil+ usuários, migração não é "nice to have" — é o projeto inteiro.

Três estratégias de migração (e o que o IdP deve suportar)#

1. Importação em massa com hashes de senha existentes

Seus usuários têm senhas hash com bcrypt, argon2 etc. O IdP aceita importar direto esses hashes e verificar?

Se sim: o usuário entra com sua senha normal, nada muda do ponto de vista dele. Melhor cenário.

Se não: todo usuário recebe email de "reset de senha". Você perde 30-50% da base nesse processo. Isso não é teoria — já vimos acontecer.

2. Migração progressiva (lazy migration)

Ao invés de migrar todos de uma vez, os usuários são migrados a cada login. O primeiro login consulta o sistema antigo e cria o usuário no novo IdP. Próximos logins usam só o IdP novo.

Mais seguro para bases grandes, mas depende de:

• Um hook customizado de autenticação que consulta o legado
• Capacidade de criar usuário on-the-fly no login
• Controle de quem já migrou e quem não

3. Dual-write (sistemas em paralelo)

Durante a transição, antigo e novo sistema ativos. Gravações vão para ambos, leituras aos poucos mudam para o novo. Permite rollback, mas complica a operação.

Sinais de alerta na migração#

• "Suportamos importação CSV" — Isso significa só importar dados, não senhas. Você ainda terá que pedir resets.
• "Temos guia de migração" — Leia com atenção. Se disser "usuários terão que criar nova senha", aí está o cenário de perda de 30-50%.
• Nada sobre hash de senha — Se o fornecedor nem fala nisso, nunca lidou com migração em escala.

Pergunte#

• Quais algoritmos de hash de senha são aceitos para importação? (bcrypt, argon2, scrypt, PBKDF2, customizado?)
• Dá para fazer migração progressiva, migrando usuário no primeiro login?
• Dá para medir progresso — quantos usuários já migraram?
• Qual é o plano de rollback se a migração der errado?
• É possível manter a sessão atual, sem ter que deslogar usuários durante a migração?

Se o fornecedor não responde de forma segura, nunca fez isso antes. Prossiga para o próximo.

Dimensão 6: Multi-tenancy — Nativo versus improvisado#

SaaS B2B é multi-tenancy. Seus clientes são organizações, com vários usuários, roles e regras. O IdP tem que entender isso nativamente.

O que é "multi-tenancy nativo"#

• Organização como entidade first-class: Não só um custom field no usuário, mas um modelo com ID, configuração e lista de membros próprios.
• Políticas de autenticação por organização: Org A usa SAML SSO, Org B e-mail/senha com MFA obrigatório, Org C login Google. Tudo configurável via UI ou API, sem código.
• Convites e gestão de membros: Admins convidam, atribuem roles e removem membros. O IdP lida com convite, verificação e atribuição de roles.
• Tokens com escopo de organização: Quando um usuário atua em uma organização, o token inclui o contexto da org. Sua API sabe de qual organização retornar dados.

O "jeitinho do metadata customizado"#

Alguns IdPs não têm modelo nativo. Sugerem usar user metadata (user.app_metadata.org_id = "123").

Isso quebra rápido:

• Usuário com múltiplas orgs = array em metadata
• Não tem fluxo de convite/membro próprio
• Não há políticas de auth por org
• Não há token scoped por org — é preciso inferir de outros sinais
• Audit logs nem sabem o que é organização

Se o fornecedor sugerir "modele org usando metadata", é como guardar dados relacionais em coluna JSON. Funciona até deixar de funcionar.

Pergunte#

• O modelo de organização é nativo ou em cima de metadata de usuário?
• Um usuário pode pertencer a várias organizações simultâneas?
• Podemos configurar requisitos de autenticação diferentes por organização?
• Roles e permissões por organização são nativos?
• Admins podem gerenciar via self-service UI?
• O token inclui o contexto da organização?

Dimensão 7: Prontidão para IA — Critério novo, cada vez mais essencial#

Doze meses atrás, "autenticação de agente de IA" não aparecia em checklist. Hoje, se você embute IA no produto — copilotos, agentes autônomos — seu IdP precisa lidar com uma nova identidade: o agente.

Por que agentes quebram o modelo tradicional#

Tradicionalmente há dois atores: usuário e aplicação. OAuth2 foi feito para isso.

Agentes IA trazem um terceiro: entidade não-humana que age em nome do usuário com permissões limitadas, precisa de trilha de auditoria própria.

• Agente não é usuário — não tem senha nem sessão de navegador
• Não é só serviço M2M — age em nome de usuário
• Precisa de permissões limitadas e temporais — não uso total do usuário

O que seu IdP precisa suportar#

Token Exchange (RFC 8693): O agente apresenta sua credencial + autorização do usuário e recebe token scoped. O token traz: quem (usuário), qual (agente), escopo (permissão) e quando (expiração).

Agente como tipo de cliente: O agente deve ser um client OAuth2 próprio com seu client_id, não um hack com API key ou tokens compartilhados.

Gestão de escopos delegados: O usuário concede permissões específicas ao agente — ler sem escrever, acessar só certos recursos.

Distinção em logs: Logs devem mostrar "usuário fez X" versus "agente fez X em nome do usuário". Se não distinguir, você falha no próximo SOC2 ao responder "quem fez essa mudança?"

Compatibilidade com MCP (Model Context Protocol)#

MCP está virando padrão para agentes IA interagirem com ferramentas. Se o IdP suporta auth OAuth para servidores MCP, agentes autenticam direto pelo protocolo, não via API keys.

Pergunte#

• Suportam OAuth2 Token Exchange?
• Dá para modelar agentes como client types distintos?
• Tokens carregam info de delegação (quem autorizou, qual escopo)?
• Audit logs distinguem ações de agente e humano?
• Integraram MCP server ou OAuth para auth de agente?

Se não pensaram nisso, estão construindo para 2020. Você está planejando para 2026.

Dimensão 8: Requisitos não-funcionais — O que tira o sono#

Funcionalidade vende. Operação define se você renova.

Performance#

• Auth throughput: Aguenta 100+ requisições/s em pico? E 1.000+?
• Latência na validação do token: Se JWTs são validados localmente (o certo), é sub-millisecond. Mas se precisa introspectar no IdP, qual o P99?
• Limite de escala: Quantos MAU máximos suporta? Algum caso já atingiu seu porte?

Compliance#

• SOC2 Tipo II: Só Tipo II serve (auditado por período, não só pontual). Tem só Tipo I? Pergunte a previsão do II.
• Logs de auditoria: Todo evento de auth, permissão, ação admin. Dá para exportar pro SIEM? Logs são imutáveis?
• Residência de dados: Dá para escolher a região dos dados? Para clientes UE isso não é opcional.

Confiabilidade#

• SLA de uptime: 99,9% = 8,7h/ano fora. 99,99% = 52 min. Auth é a porta do produto — faz diferença.
• Failover: Em pane do fornecedor, o que acontece? Tem fallback? Multi-região?
• Histórico de incidentes: Veja a página de status — não o que prometem, mas o que de fato aconteceu.

Portabilidade de dados#

• Exportação de usuários: Pode exportar tudo, incluindo metadata, membros de organização e roles? Em qual formato?
• Padrão aberto: Usam protocolos padrão (OIDC, SCIM) que facilitam migrar para outro fornecedor?
• Sinais de não lock-in: APIs proprietárias, formatos não-padrão de token — tudo isso dificulta sair.

A matriz de avaliação: Framework de pontuação na prática#

Depois de avaliar todas as dimensões, você precisa comparar. Aqui vai um framework de prioridade:

P1 — Impeditivos (deve passar ou desclassifica)#

P2 — Fortemente preferidos (dá muito trabalho se faltar)#

P3 — Importantes (planeje para 12 meses)#

P4 — Nice to have (não bloqueia decisão)#

Como usar: Comece pelo P1. Se falhar em algum P1, descarte. Depois avalie P2 e P3. O fornecedor com melhor pontuação combinada em P2+P3 é sua resposta.

Erros comuns na avaliação#

Vemos equipes cometerem sempre os mesmos erros. Veja como evitar:

Erro 1: Avaliar por funcionalidade, não arquitetura#

Tabela de funcionalidades mostra o que existe. Não mostra COMO foi construído. Um IdP pode "suportar" organizações só gravando org_id em metadata do usuário. Passa no Excel, dá problema em produção.

Correção: Para toda funcionalidade, pergunte “como foi implementada?” — não só “tem?”

Erro 2: Ignorar migração antes da escolha#

Equipes escolhem IdP "melhor", começam a implementar e descobrem que vão forçar reset de senha. Ficam presos à má experiência ou têm que reavaliar tudo.

Correção: Migração deve ser o primeiro filtro, não o último.

Erro 3: Excesso de peso na demo#

Demo de fornecedor é polida, mostra o caminho feliz com banco limpo e zero edge case. Em produção você tem usuários com contas fundidas, unicode estranho e sessões zumbi.

Correção: Peça prova de conceito com DADOS REAIS. Importe mil usuários reais e faça seus próprios fluxos.

Erro 4: Não envolver as pessoas certas#

Só time de plataforma avalia: escolhem o mais limpo tecnicamente. Só produto avalia: o mais fácil de integrar. Só segurança avalia: o com mais checks de compliance.

Correção: O time avaliador tem que envolver plataforma, produto e segurança. Cada um olha critérios P1/P2 distintos.

Erro 5: Esquecer que um dia você vai sair#

Lock-in é real. SDKs próprios, APIs específicas, tokens não padrão — tudo isso dificulta migrar.

Correção: Prefira IdPs com protocolos abertos (OIDC, OAuth2, SCIM). Você vai se agradecer depois.

FAQ#

Quanto tempo leva uma avaliação de IdP normalmente?#

Uma avaliação completa, com prova de conceito, dura de 4 a 8 semanas. Fazer com pressa leva aos erros citados acima — especialmente negligenciar migração. Planeje 2 semanas para levantamento de requisitos, 2 a 3 para análise e PoC de fornecedores, 1 a 2 para alinhamento de stakeholders.

Deveríamos construir nossa própria auth?#

Depende do estágio. Menos de 10 mil usuários e nenhum cliente enterprise? Uma lib leve basta. Mas se precisar de SSO, multi-tenant, MFA e compliance, manter auth caseira custa mais que um IdP. Já vimos times gastando 2-3 engenheiros full-time só nisso — $300-500 mil/ano em custo de oportunidade.

Qual a diferença entre CIAM e IAM corporativo?#

Customer Identity and Access Management (CIAM) é o auth dos usuários finais (cadastro, login, perfil). IAM corporativo é o auth dos colaboradores para sistemas internos (Okta no Slack, Google Workspace etc). Compras com critérios diferentes. Aqui falamos de CIAM.

Open source vs proprietário: o quanto importa?#

IdPs open source dão transparência (auditável), portabilidade (self-host) e comunidade. Proprietários entregam UI mais polido e serviço gerenciado. O essencial não é "open x closed" — é “posso sair?”. Open tende a facilitar saída porque modelo de dados e APIs são públicos.

Quando AI agent auth vira P1 em vez de P3?#

Se você já está construindo IA que acessa dados em nome do usuário (copilot, workflow), P1 já. Se IA está para 6-12 meses, fica P3 mas com peso maior. Se IA nem está no radar, deixa como P4 — mas revise em 6 meses.

Como avaliar preço se modelos de cobrança diferem?#

Quase todo IdP cobra por Monthly Active Users (MAU). Mas "MAU" muda — alguns contam login, outros usuário único, outros M2M separado. Peça ao fornecedor preço para seu cenário: X usuários, Y orgs, Z conexões M2M, volume Y de auth. Compare custo total, não só preço unitário.

Conclusão#

Escolher provedor de identidade é decisão de infra, não de funcionalidade. Você está apostando no sistema que fará todo first touch do usuário no produto, toda permissão de API, todo log auditável.

O framework acima cobre o que realmente importa — não o marketing. Use para filtrar rápido (P1 primeiro), avaliar fundo (P2/P3 + PoC) e tomar decisão que dure anos, não meses.

As equipes que acertam nisso têm algo em comum: tratam identidade como infra, não como feature para entregar e esquecer.