Como escolher um fornecedor de identidade: O framework de avaliação da equipa de engenharia

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

Isto não é isso.

Reunimos dezenas de pedidos reais de avaliação empresarial — os verdadeiros ficheiros Excel e documentos RFP que as equipas de compras enviam aos fornecedores. Os padrões são claros: as equipas de engenharia consistentemente subvalorizam os critérios que mais importam e sobrevalorizam os menos críticos.

O resultado? As equipas escolhem um IdP com base numa demo, descobrem que a migração é um pesadelo passados seis meses, e recomeçam a avaliação.

Aqui está o framework de avaliação que gostaríamos que alguém nos tivesse dado antes de começarmos. É feito para equipas de engenharia em empresas SaaS B2B — aquelas que estão a construir produtos, não as que compram SSO de funcionários para uso interno.

Resumo rápido: O que faz ou desfaz uma decisão de IdP#

Se estás a ler na diagonal, aqui vai a versão curta:

1. A profundidade do protocolo importa mais que a quantidade de funcionalidades. Dizer que suporta "OAuth2" não quer dizer nada. Que tipos de grant? Dá para personalizar os claims dos tokens? Podes ser tu próprio um fornecedor OIDC?
2. Capacidade de migração é o critério subestimado nº1. Se não consegues migrar os teus utilizadores sem forçar a alteração das passwords, o IdP é inutilizável — por melhor que tudo o resto pareça.
3. Multi-inquilinos tem de ser nativo, não remendado em cima. Se o modelo de organizações e configurações por inquilino requerem truques, vais estar sempre a lutar contra o sistema.
4. Prontidão para IA não é planeamento para o futuro — é um requisito a 12 meses. Troca de tokens, identidade de agentes, scopes delegados. Se o IdP não suporta estas coisas, para o ano vais estar aqui outra vez a avaliar.

O resto deste guia percorre cada dimensão da avaliação ao detalhe, com perguntas específicas a fazer e sinais de alerta para identificar.

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

É para ti se:

• És CTO, VP de Engenharia ou arquiteto de plataforma numa empresa SaaS B2B de 50-300 pessoas
• Tens mais de 100K utilizadores existentes e não podes arriscar uma migração disruptiva
• Estás a crescer para clientes empresariais que exigem SSO, modelos de organizações e logs de auditoria
• Precisas de escrever um relatório técnico de avaliação e queres um framework independente do fornecedor

NÃO é para ti se:

• Procuras IAM para funcionários (SSO interno) — é outra decisão de compra
• És uma startup com 500 utilizadores e sem clientes empresariais — escolhe o melhor SDK e segue em frente
• Precisas de verificação de identidade (KYC/KYB) — é outra categoria totalmente diferente

Dimensão 1: Capacidades do protocolo — Não basta "suporta OAuth2"#

Todos os IdP do mercado dizem que suportam OAuth2 e OIDC. Isso é o básico. O que interessa é a profundidade.

Tipos de grant: Quais e porquê interessa#

Essencial:

• Authorization Code + PKCE — O único flow que deves usar para apps web e mobile. Se um fornecedor ainda recomenda o Implicit flow, sai daí. PKCE não é opcional — é obrigatório para a segurança.
• Client Credentials — Para comunicação entre serviços. Os teus serviços backend precisam de autenticar uns com os outros sem um utilizador presente.
• Refresh Token — Parece simples, mas varia imenso na prática. Dá para configurar rotação? Expiração? Dá para revogar um refresh token específico sem terminar toda a sessão?

Cada vez mais crítico:

• Token Exchange (RFC 8693) — É este grant que permite autenticação de agentes de IA, impersonação e delegação. Se ainda não existe hoje, pergunta pela roadmap. Se não houver roadmap, é sinal de alerta.

Capacidade de fornecedor OIDC#

Aqui está uma pergunta que poucas equipas fazem: Podes usar este IdP como fornecedor OIDC — não apenas como consumidor OIDC?

Porquê interessa: À medida que o teu SaaS cresce, parceiros e clientes podem querer usar o teu sistema de identidade para entrar nas ferramentas deles. Precisas de emitir tokens, gerir consentimento e registar apps de terceiros. Se o teu IdP só consome fornecedores externos mas não pode atuar como tal, bate numa parede quando for altura de federar para fora.

Pergunta:

• O IdP expõe um endpoint OpenID Discovery que podes "white-labelar"?
• Dá para registar apps first-party e third-party com diferentes níveis de confiança?
• Apps próprias podem saltar o ecrã de consentimento enquanto as de terceiros são obrigadas a mostrar?

Personalização de JWT#

O token é o contrato entre o teu IdP e os teus serviços. Se não der para o personalizar, todos os serviços downstream precisam de fazer chamadas API extra para perceber o que um utilizador pode fazer.

Pergunta:

• Podes adicionar claims personalizados aos access tokens e ID tokens?
• Dá para colocar o contexto da organização (qual o inquilino da sessão) diretamente no token?
• Podes definir scopes customizados que representam o teu modelo de permissões?
• Os claims são calculados à emissão do token, ou podem ser preenchidos dinamicamente via webhook ou script?

Um token com { "org_id": "org_123", "role": "admin", "auth_level": 2 } permite que o middleware da API autorize em uma linha. Um token com apenas { "sub": "user_456" } obriga cada serviço a consultar o IdP ou base de dados — em escala, isso é a diferença entre 2ms e 200ms por pedido.

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

Todos os IdP suportam email/password e login social. Parabéns, reduziste a lista a... todos eles.

A diferença está nos detalhes que raramente aparecem nas demos.

O fluxo de registo (sign-up)#

• Auto-login pós-registo: Depois de criar conta, o utilizador entra automaticamente ou vê o ecrã de login outra vez? Obrigar a iniciar sessão acabada de registar reduz conversões. Irias surpreender-te com todos os IdP que fazem mal.
• Campos personalizados de registo: Podes recolher cargo, nome da empresa ou caso de uso durante o registo? Ou tens de fazer onboarding separado depois?
• Perfil progressivo: Dá para recolher mais informação em várias sessões, ou obrigas tudo à cabeça?

O fluxo de login#

• Suporte login_hint: Links de email marketing podem pré-preencher o email? Parece trivial, mas faz diferença de 40% para 60% de conversão.
• Políticas por organização: Org A pode exigir SAML SSO enquanto Org B usa email/password? MFA só para clientes enterprise? Se mudar políticas por inquilino requer código em vez de configuração, vais queimar recursos sempre que entra um cliente novo.
• Customização da experiência de login: Dá para personalizar a experiência de login por inquilino? Não só logo e cores — controlo total de CSS, domínios customizados, emails white-label. "Hosted UI vs. bring your own UI" deve ser uma escolha tua, não uma limitação do IdP.

O que os checklists costumam falhar#

• Autenticação silenciosa: Quando expira o token, a app consegue refrescar sem redirecionar o utilizador? E se o refresh token também expirar — há fallback (ex: sessão deslizante via iframe)?
• Ligação de contas (account linking): Alguém regista com Google, depois tenta entrar por email. São duas contas ou uma? Como é gerida a fusão? Se falha, vais ter duplicados de identidade para sempre.
• Opções sem password: Magic links, passkeys, WebAuthn. Não porque toda a gente precise já, mas porque os clientes enterprise vão pedir dentro de seis meses.

Dimensão 3: Gestão de sessão e tokens — O fundo do poço#

Aqui separam-se as avaliações das demos. Gestão de sessão e tokens é aborrecido até falhar — aí, todos os utilizadores são desconectados ao mesmo tempo.

Segurança dos cookies#

Não é glamouroso. É absolutamente crítico.

• Atributos HttpOnly, Secure, SameSite: Os três têm de estar corretos. IdP que não põe HttpOnly nos cookies de sessão não está pronto para produção.
• Suporte cross-subdomain: Se a tua app corre em app.teuproduto.com e a API em api.teuproduto.com, as sessões abrangem os subdomínios? Como?
• Fim dos cookies de terceiros: O Chrome vai terminar com eles. Como é que o IdP lida com auth cross-origin sem esses cookies? Resposta "estamos a trabalhar nisso" não chega.

"Remember me" e sessões persistentes#

Os utilizadores querem estar ligados semanas, não minutos. Mas uma sessão de 180 dias tem muito mais risco que uma de 30 minutos.

Pergunta:

• Dá para configurar a duração da sessão independentemente do lifetime do token?
• Existe opção "remember me" para estender a sessão sem aumentar o lifetime do token?
• Dá para forçar reautenticação em operações sensíveis sem terminar a sessão?

Segurança dos refresh tokens#

• Rotação de tokens: O IdP roda o refresh token em cada uso? (Deve rodar.)
• Armazenamento encriptado: Os refresh tokens são encriptados em repouso?
• Revogação granular: Dá para revogar a sessão de um dispositivo sem terminar todas?
• Expiração configurável: Diferentes apps = diferentes lifetimes de refresh token. Dá para configurar por app?

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

RBAC é o mínimo. IdP sem RBAC não serve. Mas para SaaS B2B, o RBAC sozinho não chega.

Permissões por organização#

Os utilizadores são de organizações. As permissões por organização são diferentes das de plataforma.

Um utilizador pode ser admin na Org A e só visualizador na Org B. O mesmo utilizador, dois contextos. Se o IdP não consegue modelar isto, constróis o teu sistema de permissões à parte — e ficas com duas fontes de verdade.

Perguntas:

• Dá para definir roles ao nível da organização, não só da pessoa?
• Um utilizador pode ter roles diferentes em diferentes organizações?
• O contexto da organização ativa está no token, para a API saber a que organização pertence o pedido?

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

Financeiro, Saúde, ou qualquer onde certas operações têm mais risco: nem todas as sessões autenticadas são iguais.

Visualizar dashboard? Cookie de sessão serve. Fazer transferência bancária? Precisas de MFA, mesmo já autenticado.

Isto é autenticação "step-up", e requer o conceito de nível de autenticação (auth_level) como claim de primeira classe no sistema de tokens.

Pergunta:

• O token pode ter um claim auth_level para o backend verificar?
• Dá para disparar "step-up authentication" sem forçar re-login total?
• O auth_level expira independentemente da sessão?

Se o IdP não tem isto nativamente, vais acabar a desenvolver — exatamente aquilo que procuras evitar.

Decisões de autorização com base em token#

Ideal: middleware da API lê o token, vê a organização, role e nível, e decide autorização sem chamadas externas.

Realidade em muitos IdP: o token só diz quem é o utilizador, mas precisas de chamada API à parte para saber o que pode fazer.

Essa chamada extra adiciona latência, dependências e pontos de falha. A 1000 pedidos/segundo, não queres que a autorização faça viagens de rede.

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

Eis um dado pouco falado: a maioria das avaliações de IdP falha não por o novo IdP ser insuficiente, mas por a equipa não conseguir migrar os utilizadores.

Com 100K+ utilizadores, migração não é "agradável de ter" — é o projeto inteiro.

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

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

Os utilizadores têm passwords com bcrypt, argon2, etc. O IdP pode importar e verificar estes hashes?

Se sim: os utilizadores entram com a password antiga, não muda nada. Melhor cenário.

Se não: todos recebem "redefine a tua password". Vais perder 30-50% da base de utilizadores. Não é teórico — já vimos acontecer.

2. Migração progressiva (lazy migration)

Migra utilizadores um a um a cada login. O primeiro login verifica a password no sistema antigo e cria o utilizador no novo. A partir daí, só no novo.

Isto é o mais seguro para grandes volumes, mas requer:

• Hook de autenticação custom para o sistema antigo
• Capacidade de criar utilizadores "on-the-fly" durante login
• Controlo de quem já migrou e quem não

3. Dual-write (sistemas em paralelo)

Durante a transição, ambos sistemas ativos. Gravação para os dois, leituras migram gradualmente. Dá rollback mas é complexo.

Sinais de alerta na migração#

• "Suportamos importação por CSV" — Só importa perfis, não passwords. Precisas de resets de password.
• "Temos guia de migração" — Lê com atenção. Se diz "utilizadores terão de definir nova password", é perda garantida de utilizadores.
• Sem referência a compatibilidade de hashes — Se o fornecedor não topa disto, não trabalhou em escala.

Perguntas essenciais#

• Algoritmos de hash suportados na importação (bcrypt, argon2, scrypt, PBKDF2, custom)?
• Dá para fazer migração progressiva (por 1º login)?
• Dá para acompanhar progresso (percentagem migrada)?
• Estratégia de rollback se correr mal?
• Continuidade de sessão durante migração (sem logout de todos)?

Se o fornecedor não responde com confiança, segue para outro.

Dimensão 6: Multi-inquilinos — Nativo vs. remendado em cima#

SaaS B2B = multi-inquilinos. Os teus clientes são organizações com múltiplos utilizadores, roles e políticas de acesso. O IdP precisa de suportar isto nativamente.

O que significa "multi-inquilinos nativo"#

• Organização como entidade de primeira classe: Não é um campo no perfil, mas um modelo com ID próprio, configuração e lista de membros.
• Políticas por organização: Org A usa SAML SSO, Org B email/password com MFA obrigatório, Org C Google Workspace. Tudo configurável por UI/API, sem código.
• Gestão de convites e membros pela organização: Admins podem convidar, dar roles, remover membros. O IdP gere convites, verificação de email, e atribuição de roles.
• Tokens com contexto de organização: Em contexto organizacional, o token inclui qual organização. A tua API sabe que dados devolver.

O "workaround" dos metadados#

Alguns IdP não têm modelo de organização nativo. Sugerem meter user.app_metadata.org_id = "123" como substituto.

Isto não dura:

• Utilizador em múltiplas orgs = arrays complicados
• Sem flow nativo de convite/membros
• Sem políticas de auth por org
• Sem tokens com contexto — tens de deduzir de outros sinais
• Logs de auditoria ignoram organizações

Se o fornecedor diz para modelar organizações com campos de metadata, é o equivalente a juntar dados relacionais numa coluna JSON. Funciona até não funcionar.

Perguntas essenciais#

• O modelo de organização é nativo ou construído em cima de metadata?
• Utilizador pode pertencer a múltiplas orgs?
• Dá para configurar requisitos de autenticação por org?
• As roles/permissões por org vêm de raiz?
• Os admins podem gerir membros em UI self-service?
• O token inclui o contexto de organização?

Dimensão 7: Prontidão para IA — O critério que quase ninguém pensa#

Doze meses atrás, "autenticação de agentes de IA" não existia em checklists. Hoje, se constróis features com IA — copilotos, agentes autónomos, workflows IA — o teu IdP precisa de suportar uma nova identidade: o agente.

Porquê os agentes quebram o modelo tradicional#

Autenticação tradicional: dois atores — utilizador e aplicação. OAuth2 foi desenhado para isto.

Agentes IA introduzem o terceiro: entidade não-humana que age em nome do utilizador, com permissões limitadas e precisa de trilhos de auditoria próprios.

• Um agente não é utilizador — não tem password nem sessão browser
• Não é serviço machine-to-machine — age por um utilizador concreto
• Precisa de permissões limitadas no tempo — não acesso total do utilizador

O que o IdP deve suportar#

Token Exchange (RFC 8693): O agente apresenta credencial própria + autorização do utilizador e recebe token limitado. O token inclui: quem (utilizador), o quê (agente), scope (permissão), e quando (expira).

Agente como tipo de cliente: O agente deve ser um cliente OAuth2 com client_id próprio, não um truque com API keys ou tokens partilhados.

Gestão de scopes delegados: O utilizador pode dar permissões específicas ao agente — ler mas não escrever, acesso a certos recursos, etc.

Distinção em logs: Os logs devem separar "utilizador fez X" de "agente fez X em nome de utilizador". Sem isto, falhas auditoria SOC2 quando te perguntarem "quem fez esta alteração?"

Compatibilidade MCP (Model Context Protocol)#

MCP está a tornar-se o protocolo padrão para agentes IA interagirem com ferramentas e serviços. Se o IdP suporta autenticação OAuth para servidores MCP, os agentes autenticam-se nativamente pelo protocolo e não por API keys ou segredos partilhados.

Perguntas essenciais#

• Suportam OAuth2 Token Exchange?
• Os agentes podem ser modelados como clientes diferentes?
• O token pode trazer informações de delegação (quem autorizou, escopo)?
• Logs de auditoria distinguem ações de agentes das de humanos?
• Integração com servidor MCP ou suporte OAuth para autenticação agente-para-ferramenta?

Se o fornecedor nunca pensou nisto, está a construir para 2020. Tu planeias para 2026.

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

Funcionalidades vendem. Operações decidem renovações.

Performance#

• Throughput de autenticação: Aguenta mais de 100 pedidos auth por segundo no pico? E 1000+?
• Latência de validação de token: Se validas JWT local (deves!), é sub-milisegundo. Se há chamadas de introspeção, qual a latência P99?
• Limite de escala: Qual o máximo de Utilizadores Ativos por Mês (MAU) suportado? Histórico comprovado para a tua escala?

Conformidade#

• SOC2 Type II: Não Type I. Type II é auditado ao longo do tempo. Só têm Type I? Pergunta pelo plano para Type II.
• Logs de auditoria: Todos os eventos auth, alterações de permissões e ações de admin. Dá para exportar para o teu SIEM? Os logs são imutáveis?
• Residência dos dados: Dá para escolher a região dos dados? Para clientes UE não é opcional.

Fiabilidade#

• SLA de uptime: 99.9% são 8.7 h/ano de indisponibilidade. 99.99% são 52 minutos. Para autenticação conta mesmo.
• Failover: O que acontece se o fornecedor tiver outage? Há fallback? Multi-região?
• Histórico de incidentes: Consulta o histórico do status page. Não promessas — o que aconteceu de facto.

Portabilidade de dados#

• Exportação de utilizadores: Dá para exportar utilizadores, metadata, organização, roles? Que formato?
• Conformidade com standards: Usam protocolos standard (OIDC, SCIM) para facilitar futura migração?
• Sinais de ausência de lock-in: APIs proprietárias, tokens custom a bloquear. Quanto mais proprietário, mais difícil sair.

Matriz de avaliação: Framework prático de pontuação#

Após avaliares cada dimensão, precisas de comparar. Eis um framework de prioridade:

P1 — Deal-breakers (obrigatório passar, senão elimina)#

P2 — Fortemente preferido (grande esforço de engenharia se faltar)#

P3 — Importante (planeia para 12 meses)#

P4 — Bom ter (não bloqueia decisão)#

Como usar: Começa por P1. Se o fornecedor falha qualquer P1, elimina. Depois pontua categorias P2 e P3. Quem tiver melhor P2+P3 é a escolha.

Erros comuns na avaliação#

Vimos equipas a errar sempre nos mesmos pontos. Eis como evitar:

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

Tabelas de comparação só mostram o que existe, não como funciona. Um IdP pode "suportar" organizações guardando org_id como metadata de utilizador — preenche a célula do Excel mas dá problemas em produção.

Correto: Por cada funcionalidade, pergunta "como está implementado?" — não só "tens isto?"

Erro 2: Ignorar migração até à escolha#

As equipas escolhem o "melhor" IdP, começam implementação, e percebem que não conseguem migrar sem reset de passwords. Ficam presos ou começam do zero.

Correto: Garante a migração como 1º filtro, não o último.

Erro 3: Valorização excessiva da demo#

Toda demo de fornecedor é bonita. Mostra o happy path com base limpa, zero edges. O teu ambiente tem contas fundidas, unicode estranho, sessões imortais.

Correto: Exige PoC com dados reais. Importa 1000 utilizadores reais e testa os fluxos reais.

Erro 4: Não envolver as pessoas certas#

Só a plataforma avalia e escolhe o tecnicamente puro. Só o produto avalia e escolhe o mais fácil de integrar. Só a segurança avalia e escolhe o mais compliance.

Correto: Equipa de avaliação = plataforma, produto e segurança. Cada um detém critérios P1/P2 diferentes.

Erro 5: Esquecer que um dia vais sair#

Lock-in é real. SDKs proprietários, APIs custom, formatos não-standard — tornam tudo mais difícil se saíres.

Correto: Prefere IdP que usam standards (OIDC, OAuth2, SCIM). Agradeces-te no futuro.

FAQ#

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

Bem feita, incluindo PoC, espera 4-8 semanas. Apressar resulta nos erros acima — em especial ignorar migração. Reserva 2 semanas para requisitos, 2-3 para avaliação e PoC, 1-2 para alinhamento stakeholders.

Devo construir o meu próprio auth?#

Depende da tua fase. Menos de 10.000 utilizadores e sem enterprise, biblioteca leve chega. Mas precisas de SSO, multi-inquilinos, MFA e compliance, manter auth próprio custa mais que IdP dedicado. Vemos equipas a gastar 2-3 engenheiros full-time (~300-500K$/ano de custo de oportunidade).

Diferença entre CIAM e workforce IAM?#

CIAM (Customer Identity and Access Management) é o que os utilizadores finais veem — registar, login, perfil. Workforce IAM é o que funcionários usam para aceder a ferramentas internas (Okta para o Slack da empresa, Google Workspace, etc.). São decisões de compra diferentes. Este guia é sobre CIAM.

Importância open-source vs. proprietário?#

IdP open-source dá transparência (podes auditar), portabilidade (podes self-host se precisares), e comunidade. Proprietário pode ter UI mais polida e serviços geridos. A questão chave não é "open vs closed" — é "posso sair se precisar?" Open tende a facilitar saída porque modelo de dados e APIs são públicas.

Quando autenticação de agentes IA é P1 e não P3?#

Já constróis IA que acede a dados de utilizador (copilotos, workflows, assistentes)? Sobe a P1 já. Se IA está no roadmap a 6-12 meses, mantém P3 mas dá peso. Se nem se coloca, fica P4 — revisita em 6 meses.

Como avaliar preços com modelos diferentes?#

A maioria dos IdP cobre por Utilizador Ativo Mensal (MAU). Mas a definicão varia — alguns contam logins, outros personas únicas, alguns os tokens M2M em separado. Faz-te orçar o teu caso: X utilizadores, Y organizações, Z ligações M2M, e volume esperado. Compara custo total, não preço unitário.

Conclusão#

Escolher um IdP é uma decisão de infraestrutura, não de funcionalidade. Estás a comprometer-te com um sistema por onde todo utilizador passa ao entrar, cada check de permissão da API, cada log de auditoria.

O framework acima cobre o que realmente importa — não as bullets de marketing. Usa para filtrar rápido (P1), avaliar a fundo (P2/P3 com PoC), e tomar uma decisão que dure anos, não meses.

As equipas que acertam vêem a identidade como infraestrutura, não como uma feature para despachar e esquecer.