TL;DR: A semana trouxe uma enxurrada de novidades para unificar identidade — OCI IAM com Azure AD, Oracle IDCS com gateways de provisionamento, Entra no Azure SQL. Mas quase todas resolvem o problema dentro do plano de um provedor, trocando fragmentação por lock-in. A alternativa portável é manter o plano de identidade na sua mão com Keycloak (open source, CNCF), federando todos eles. E o Keycloak Organizations, agora GA, entrega multi-tenancy B2B num único realm.
A semana foi pródiga em novidades de IAM. A Oracle publicou um webcast sobre a "jornada de um IAM fragmentado para um IAM unificado", anunciou integração do OCI IAM com o Azure AD, conectou o Oracle Identity Cloud Service a um gateway de provisionamento e simplificou a administração de Single Sign-On. A Microsoft, do outro lado, levou os Entra server principals para o Azure SQL Database em GA. O recado coletivo é claro: identidade espalhada por várias nuvens virou dor de cabeça grande o suficiente para todo provedor querer vender a cura.
O detalhe que ninguém no material oficial vai destacar é onde essa cura acontece. Em quase todos os anúncios, a unificação se dá dentro do plano de identidade de um provedor — você consolida no OCI IAM, ou no Entra, ou no IDCS. Resolve a fragmentação trocando-a por outra coisa: dependência. E para quem opera infraestrutura no Brasil, com a régua de custo, soberania e portabilidade que o mercado exige hoje, isso merece uma segunda leitura.
Por que "unificar dentro do provedor" é um problema disfarçado de solução?
Identidade é o ponto de acoplamento mais caro de desfazer em qualquer arquitetura. Quando suas aplicações confiam no issuer de um provedor, herdam o formato de token dele, as APIs de administração dele, o modelo de papéis dele e o ciclo de vida de usuário dele. No dia em que você quiser trocar de nuvem — por custo, por uma exigência de soberania de dados, por uma negociação de contrato que azedou — não basta migrar workloads: é preciso reintegrar cada aplicação a um novo plano de identidade.
É o tipo de lock-in que não aparece no PoC e cobra caro anos depois. A fragmentação que os provedores se oferecem para resolver é real; a solução proposta só é confortável enquanto você não precisar sair.
A alternativa não é viver fragmentado. É colocar o plano de identidade na sua mão — uma camada portável que federa todos os provedores e fala protocolos abertos. É aqui que entra o Keycloak.
O que muda quando o plano de identidade é seu?
Keycloak é uma solução open source de Identity and Access Management, projeto incubado na CNCF (doado pela Red Hat). Ele fala OIDC e SAML 2.0 nativamente, roda em qualquer Kubernetes, VM ou on-premises, e funciona como identity broker: cada provedor externo — OCI IAM, Azure AD/Entra, Google, um AD corporativo via LDAP — entra como um identity provider, e suas aplicações enxergam um único issuer e um único formato de token, não importa onde o usuário de fato se autenticou.
A diferença em relação a unificar dentro de um vendor é estrutural:
| Unificar no plano do provedor | Plano portável com Keycloak | |
|---|---|---|
| Issuer dos tokens | Do provedor | Seu, estável entre nuvens |
| Trocar de nuvem | Reintegrar cada aplicação | Aplicações não mudam — confiam no protocolo |
| Federar múltiplas nuvens | Limitado ao ecossistema do vendor | OIDC/SAML de qualquer provedor, simultaneamente |
| Onde roda | Infra gerenciada do provedor | Qualquer Kubernetes/VM, qualquer nuvem ou on-prem |
| Custo | Por usuário/feature, na régua do vendor | Custo de operar o serviço, sem licença por seat |
| Saída | Cara e arriscada | Migra para outro IdP que fale os mesmos protocolos |
O ponto não é que o IAM dos provedores seja ruim — é que a unificação não deveria morar dentro de quem você um dia pode querer deixar. Federar é diferente de se render.
Por que o Keycloak Organizations é a novidade que importa para multi-tenant?
Por anos, o calcanhar de Aquiles do Keycloak em cenários B2B SaaS foi o multi-tenancy. Quem precisava isolar clientes recorria a um de três padrões, todos com um preço:
- Um realm por cliente — bom isolamento, mas cada realm é uma unidade operacional: configuração, temas, IdPs, chaves e upgrades multiplicados por N. Não escala para dezenas ou centenas de clientes.
- Realm compartilhado com groups — escala, mas o isolamento é fraco e a governança vira gambiarra.
- Um client por cliente — resolve autorização, não identidade nem onboarding.
O Organizations, que entrou como preview no Keycloak 25 e se tornou GA no Keycloak 26, resolve isso de frente: multi-tenancy de primeira classe dentro de um único realm. Cada organização é um tenant lógico com membros, identity provider e claims próprios — sem o inferno operacional de um realm por cliente.
Na prática, o Organizations entrega quatro capacidades que antes exigiam código e contorno:
- Identity provider por organização. Cada cliente pode plugar o próprio SSO corporativo. A federação B2B deixa de ser configuração espalhada na aplicação e vira atributo da organização.
- Login identity-first com match por domínio. O usuário informa só o e-mail; o Keycloak casa o domínio (
@cliente.com) com a organização e ajusta o fluxo de autenticação — redirecionando para o IdP daquele cliente quando existir. - Onboarding por convite ou brokering. Membros entram por link de convite ou são federados automaticamente a partir do IdP da organização (managed members).
- Claims por organização no token. A aplicação recebe, no token, a qual organização o usuário pertence — base direta para autorização multi-tenant.
E porque é Keycloak, tudo isso é dirigível por API de administração. Criar um tenant e plugar o SSO do cliente é uma chamada, não um chamado para o time de infra:
# Cria a organização (o tenant lógico) e seu domínio
POST /admin/realms/{realm}/organizations
{
"name": "acme",
"domains": [ { "name": "acme.com", "verified": true } ]
}
# Associa o identity provider do cliente à organização (SSO corporativo dele)
POST /admin/realms/{realm}/organizations/{org-id}/identity-providers
"acme-corporate-oidc"
# Inclui um usuário existente como membro do tenant
POST /admin/realms/{realm}/organizations/{org-id}/members
"<user-id>"
O controle de acesso a essas operações segue o modelo do próprio Keycloak, com as roles manage-organizations, view-organizations e query-organizations — então você delega a administração de tenants sem abrir o realm inteiro.
O que isso destravou na prática
Em projetos recentes de SaaS B2B multi-tenant que construímos, o padrão realm-per-tenant era exatamente o teto que nos impedia de escalar o onboarding: cada novo cliente significava provisionar e, pior, manter mais um realm — o que pesa a cada upgrade do Keycloak e a cada ajuste de configuração que precisa ser replicado.
Migrar o modelo para Organizations mudou a natureza do problema. Incluir um cliente passou a ser uma operação de dados — uma chamada de API que cria a organização, registra o domínio e, quando o cliente tem SSO próprio, associa o identity provider dele — em vez de uma operação de infraestrutura. O ganho concreto aparece em três frentes:
- Escalabilidade de onboarding: a curva de esforço por novo cliente deixou de crescer com a quantidade de tenants.
- Superfície operacional menor: um realm para auditar, versionar e atualizar, não N.
- Experiência B2B nativa: o cliente entra com a conta da própria empresa (identity-first + IdP por organização), sem fluxo de cadastro paralelo.
Tudo isso sem abrir mão da portabilidade: o plano de identidade continua sendo nosso, federando os provedores que cada cliente usa, e roda no mesmo Kubernetes onde já operamos o resto da stack.
Quando o IAM do provedor ainda faz sentido?
Posicionar-se contra lock-in não é dogma. Há cenários em que consolidar no provedor é a escolha pragmática:
- Acesso à infraestrutura do próprio provedor (políticas IAM do OCI, do Azure, da AWS para os recursos deles) — isso é, e deve continuar sendo, nativo do provedor. Federar o acesso humano via Keycloak é compatível com manter as políticas de recurso onde elas nascem.
- Isolamento físico total por exigência regulatória — quando a norma pede separação de banco/infra por cliente, realms separados (ou até instâncias separadas) ainda batem o Organizations.
- Equipe muito enxuta e zero apetite por operar um serviço stateful — aí um IAM gerenciado reduz carga operacional, com o lock-in entrando consciente na conta.
A régua é simples: acesso à infra do provedor, no provedor; identidade dos seus usuários e dos seus clientes, no seu plano portável.
Conclusão
A onda de anúncios de unificação de IAM da semana mira uma dor real — mas a maioria resolve fragmentação criando dependência. Para quem opera infraestrutura no Brasil e leva a sério custo, soberania e a liberdade de trocar de fornecedor, a pergunta certa não é "em qual provedor eu consolido?", e sim "de quem é o meu plano de identidade?".
Com Keycloak, ele é seu: federa todos os provedores, fala protocolos abertos e roda onde você quiser. E com o Organizations agora GA, o último grande argumento contra usá-lo em SaaS multi-tenant — o custo operacional do realm-per-tenant — caiu. Unificar identidade sem se prender a um vendor deixou de ser um trade-off difícil; virou a escolha padrão para quem quer escalar com a mão no leme.
Fontes:
- Keycloak Organizations — anúncio oficial (CIAM e multi-tenancy) — Keycloak
- Managing organizations — Keycloak Server Administration Guide — Keycloak
- The journey from a fragmented IAM to a unified IAM — Oracle
- Managing identity across OCI IAM and Azure AD — Oracle
- OCI IAM simplifies Single Sign-On administration — Oracle
- IDCS integration with the Kapstone Provisioning Gateway — Oracle
- Generally available: Microsoft Entra server principals and server roles for Azure SQL Database — Microsoft
