Ir para o conteúdo principal

Gestão de usuários B2B multi-tenant e controle de acesso

Desenvolvedor Frontend Sênior · 2025 · 2 min de leitura

Reconstruí identidade B2B para papéis multi-tenant: um login entre empresas, controle de acesso mais fino e suporte a planos por papel.

Caminho rejeitado: Copiar helpers de login e sessão em cada microfrontend

Visão geral

Fui responsável pelo microfrontend de identidade Astro/React e pelo pacote de autenticação compartilhado numa mudança de identidade B2B, com backend e segurança: de contas por nick isoladas (um nick, uma empresa, todos admin) para acesso multi-tenant por e-mail, em que uma identidade acumula papéis entre empresas.

Problema

Usuários entravam com nick, e um nick significava uma empresa. Todos eram admin porque não havia papéis restritos. Com o crescimento da plataforma, empresas precisavam de controle de acesso mais fino e uma pessoa gerenciando mais de uma empresa.

Restrições

  • A mudança tocava todo microfrontend que mostrava login ou nome de usuário.
  • O backend cuidava da aplicação das regras no Keycloak; o frontend precisava de uma biblioteca compartilhada para ler os novos estados de sessão.
  • Sem lançamento único. Rollout gradual, sem quebrar sessões legadas ativas.

Arquitetura

Com backend e segurança, construímos cadastro, login e atribuição de papéis como microfrontend central Astro/React, mais biblioteca JS interna para validação de autenticação e Keycloak. Essa biblioteca exportava componentes compartilhados de User Profile e Login injetados nos demais microfrontends.

Decisões principais

Autenticação em pacote interno

Motivo

Um lugar para validação, chamadas Keycloak e UI de autenticação supera copiar lógica de login entre microfrontends.

Alternativas consideradas
  • Copiar helpers de login e sessão em cada microfrontend (rejeitado: código diverge e sobe o risco de segurança)
  • Um único shell SPA responsável por toda a interface de autenticação (rejeitado: acoplado demais à migração da plataforma)

Atoms para estado React local, Astro no resto

Motivo

Cadastro em várias etapas precisava de estado compartilhado dentro de um app React. Atoms encaixaram sem inventar persistência entre ilhas.

Alternativas consideradas
  • Redux ou store global entre microfrontends (rejeitado: exagero e vazamento de fronteira)

Rollout em fases

Motivo

Peças de identidade foram para produção em etapas para sessões legadas continuarem funcionando.

Alternativas consideradas
  • Troca única e abrupta (rejeitado: risco de sessão alto demais)

Stack

  • Astro
  • React
  • TypeScript
  • Internal Atom-based State Management
  • Keycloak (Auth integration)
  • Tailwind CSS

Impacto

Modelo de identidade 1 e-mail → várias empresas + papéis
Modelo anterior 1 nick → 1 empresa (todos administradores)
Distribuição de autenticação Pacote compartilhado entre microfrontends
Suporte a planos Níveis de assinatura por papel/empresa

Identidade passou de 1 nick = 1 empresa para 1 e-mail = várias empresas com papéis. Esse modelo habilitou planos que dependem de papéis e empresas gerenciadas.

Aprendizados

  • Microfrontends funcionam quando as fronteiras são claras. Autenticação cruza elas, então biblioteca compartilhada foi o ajuste certo.
  • Rollout de identidade em fases reduz o risco de migrar autenticação legada.
  • Keycloak é a fonte da verdade; como o frontend lê as claims do token ainda decide se login e perfil ficam coerentes entre microfrontends.