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:
- 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?
- 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.
- 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.
- 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.
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.
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.
- 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?
- 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)#
| Critério | Porque é P1 |
|---|
| Importação de hash de password ou migração progressiva | Sem isto não dá para migrar |
| Suporte Authorization Code + PKCE | Base de segurança |
| Modelo de organização nativo | Necessidade B2B SaaS |
| SOC2 Type II ou caminho claro para lá | Clientes enterprise vão exigir |
| SLA de uptime 99.9%+ | Auth em baixo = produto em baixo |
P2 — Fortemente preferido (grande esforço de engenharia se faltar)#
| Critério | Porque é P2 |
|---|
| Claims JWT personalizados | Evita queries a cada pedido |
| Políticas de autenticação por organização | Onboarding enterprise |
| Roles/tokens por organização | Multi-inquilinos seguro |
| Rotação/revogação dos refresh tokens | Melhores práticas de segurança |
| UI hosted + opção UI custom | Flexibilidade para vários casos |
P3 — Importante (planeia para 12 meses)#
| Critério | Porque é P3 |
|---|
| Token Exchange (RFC 8693) | Autenticação de agentes IA |
| Capacidade OIDC Provider | Federação com parceiros |
| Step-up authentication / auth_level | Operações financeiras/risco |
| SCIM provisioning | Sincronização diretórios enterprise |
| Suporte Passkey/WebAuthn | Sem password |
P4 — Bom ter (não bloqueia decisão)#
| Critério | Porque é P4 |
|---|
| Dashboard analytics integrado | Dá para construir dos logs |
| Templates de email white-label | Conveniência |
| Builder visual de fluxos | Conveniência |
| Conectores sociais prebuilt (além dos top 5) | Provedores menos comuns |
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.
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.
