O que é IAM (Gestão de Identidade e Acesso)?

IAM é um framework de políticas e tecnologias que garante que os usuários certos tenham o acesso certo aos recursos certos, no momento certo. Gestão de Identidade e Acesso é a disciplina por trás de toda caixa de login e toda verificação de permissão — e uma desambiguação logo de início: grandes provedores de nuvem também vendem produtos chamados “IAM” para controlar o acesso à própria infraestrutura; esses são implementações da disciplina, não a sua definição. Este artigo cobre a disciplina — incluindo a versão que todo desenvolvedor de app constrói ou herda, geralmente sem chamá-la de IAM.

Principais pontos

O ciclo de vida da identidade: entrar, mudar, sair

O trabalho diário do IAM é um loop que toda conta percorre, e ele mapeia para operações concretas:

ENTRAR   criar identidade → verificar e-mail → emitir credenciais/session
         (provisionamento — automatizado via SCIM em sistemas corporativos)
MUDAR    mudanças de papel · mudanças de time · concessões e revogações
         (a autorização segue os papéis, então uma mudança é atualização de dados)
SAIR     revogar sessions JÁ → desativar a conta → excluir ou anonimizar
         (desprovisionamento — etapas puladas viram "contas órfãs",
          o achado de auditoria que insiste em aparecer nos relatórios de violação)

O mesmo loop como chamadas de API:

// JavaScript / Node.js — Back4app JS SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret, email: '[email protected]' });

// Move: authorization follows roles, not people
editors.getUsers().add(user);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Flutter / Dart — Back4app Flutter SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();

// Move: authorization follows roles, not people
editors.addRelation('users', [user]);
await editors.save();

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// iOS / Swift — Back4app Swift SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
var user = User()
user.username = "ada"
user.password = secret
user.email = "[email protected]"
let signedUp = try await user.signup()

// Move: authorization follows roles, not people
try await editors.users.add([signedUp]).save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

// Android / Kotlin — Back4app Android SDK
// The identity lifecycle as API calls: join → move → leave
// Join: create the identity (email verification configurable server-side)
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.email = "[email protected]"
user.signUp()

// Move: authorization follows roles, not people
editors.users.add(user)
editors.save()

// Leave: deprovision — revoke sessions server-side, then delete or anonymize
// (admin / Cloud Code territory: no orphaned accounts, audit trail kept)

Autenticação vs. autorização

A distinção sobre a qual a disciplina inteira se apoia:

A versão aeroporto, uma única vez: controle de passaporte versus cartão de embarque. Depois a versão de engenharia, que importa mais: a autenticação produz a identidade que uma session carrega; a autorização a consome em cada requisição dali em diante — e é por isso que as duas falham de formas diferentes e são endurecidas separadamente.

Os quatro pilares — e as três letras do mercado

A anatomia funcional: autenticação (provar identidade — senhas, MFA, SSO, passwordless), autorização (decidir ações — papéis, permissões, regras por objeto), ciclo de vida (o loop entrar/mudar/sair) e auditoria (o quarto pilar cronicamente subestimado: logs, revisões de acesso e a capacidade de responder “quem podia ler isto, e quem leu?”). O mercado de fornecedores fatia o mesmo território em segmentos que você vai encontrar em uma compra corporativa: AM (access management — login, SSO, MFA), IGA (governança — certificações, segregação de funções, a camada do “deveriam ter isso?” acima do operacional “conseguem?”) e PAM (acesso privilegiado — cofres e elevação just-in-time para as contas cujo comprometimento é fim de jogo). A mesma disciplina, dois mapas.

O stack de padrões

A sopa de letrinhas, resolvida em funções — a tabela que as páginas do ranking nunca oferecem:

Workforce IAM vs. CIAM

A distinção merece sua tabela porque o conteúdo do ranking é quase todo escrito sobre a coluna da esquerda, enquanto a maioria dos desenvolvedores lendo um glossário está construindo a da direita: fluxos de cadastro, gestão de session e recuperação de conta para os usuários de um app é CIAM — a disciplina se aplica mesmo quando ninguém na sala usa a sigla.

Casos de uso comuns

• Gestão de usuários do app — cadastro, verificação, sessions, papéis, exclusão: CIAM como trabalho cotidiano de backend.
• SSO corporativo — um IdP, muitos apps; MFA e offboarding impostos em um único ponto.
• Identidade de APIs e serviços — credenciais de máquina, tokens com escopo e rotação para chamadores não humanos.
• Programas de compliance — revisões de acesso, trilhas de auditoria e evidência de menor privilégio para GDPR, HIPAA, SOC 2.
• Arquiteturas zero trust — verificações de identidade por requisição substituindo a localização na rede como sinal de confiança.

Você deveria construir ou comprar seu IAM? Matriz de decisão

Limitações e trade-offs

• IAM é um processo vestindo software. Ferramentas automatizam política; não conseguem inventá-la — desenho de papéis, cadência de revisão e disciplina de offboarding continuam sendo trabalho humano.
• Centralizar concentra risco. Um IdP significa um único lugar a proteger e uma única queda que desloga todo mundo; planejamento de disponibilidade e recuperação vem junto com a conveniência.
• Federação herda confiança. Todo app que confia em um IdP herda os comprometimentos dele; validação de token e tempos de vida curtos são a contenção.
• Automação de ciclo de vida precisa de verdade. O provisionamento é tão bom quanto a fonte de registro que o alimenta; dados de RH desatualizados viram acessos desatualizados.
• Auditoria sem revisão é teatro. Logs que ninguém lê e certificações sobre as quais ninguém age satisfazem checklists, não atacantes.

IAM no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A visão de IAM pelos olhos do desenvolvedor é exatamente o que ele entrega: a classe User é o repositório de identidades; cadastro, verificação de e-mail, redefinição de senha e login social cobrem a autenticação (com um adaptador de MFA para step-up); tokens de sessão revogáveis carregam a identidade; papéis e ACLs por objeto são o pilar da autorização, aplicados em toda requisição REST, GraphQL e Live Query; e o ciclo de vida das abas de código — entrar, mudar, sair — é trabalho comum de dados, com os gatilhos do Cloud Code como o lugar de impor política (bloquear e-mails descartáveis, registrar eventos de auditoria, desprovisionar em cascata). É CIAM como camada de plataforma: os pilares chegam montados, e o seu trabalho muda de construir o maquinário de identidade para decidir a política.