---
term: 'IAM (Gestão de Identidade e Acesso)'
seoTitle: 'IAM (Gestão de Identidade e Acesso): Pilares, Padrões, Ciclo de Vida'
headline: 'O que é IAM (Gestão de Identidade e Acesso)?'
slug: iam
category: auth-security
shortDefinition: '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.'
relatedTerms:
  - role-based-access-control-rbac
  - oauth-2-social-login
  - multi-factor-authentication-mfa
  - json-web-token-jwt
contrastsWith:
  - role-based-access-control-rbac
aboutTerms:
  - 'Provedor de Identidade (IdP)'
  - 'Single Sign-On (SSO)'
  - 'Ciclo de Vida da Identidade'
  - 'CIAM'
faq:
  - question: 'O que é IAM em termos simples?'
    answer: 'A disciplina de gerenciar quem pode acessar o quê: provar que usuários são quem dizem ser (autenticação), decidir o que podem fazer (autorização), administrar contas da criação à remoção (ciclo de vida) e manter registro de tudo (auditoria). Ela responde "quem é você?" e "o que você pode fazer?" para cada requisição.'
  - question: 'Qual a diferença entre autenticação e autorização?'
    answer: 'Autenticação verifica quem você é — credenciais, códigos, biometria. Autorização decide o que você pode fazer — papéis, permissões, políticas. Na versão aeroporto: o controle de passaporte versus o cartão de embarque. A autenticação sempre roda primeiro; a autorização roda em cada ação depois dela.'
  - question: 'Quais são os componentes de um sistema IAM?'
    answer: 'Um repositório de identidades (o diretório de usuários), serviços de autenticação (senhas, MFA, single sign-on), o maquinário de autorização (papéis, permissões, ACLs), ferramentas de ciclo de vida (provisionamento e desprovisionamento) e logging de auditoria. Todo sistema real tem os cinco, sejam montados à mão ou herdados de uma plataforma.'
  - question: 'O que é um provedor de identidade (IdP)?'
    answer: 'O sistema que é dono das identidades e responde por elas: autentica o usuário e emite tokens ou asserções assinadas — via OpenID Connect ou SAML — nas quais outras aplicações confiam. Todo botão de "Entrar com…" é um IdP em ação; empresas rodam o próprio para o single sign-on da força de trabalho.'
  - question: 'O que é single sign-on (SSO)?'
    answer: 'Autentique-se uma vez no provedor de identidade e acesse muitas aplicações sem novos logins — cada app confia na asserção do IdP em vez de guardar as próprias credenciais. Menos senhas, um único lugar para impor MFA, um único interruptor para cortar o acesso em todo lugar.'
  - question: 'O que é provisionamento e desprovisionamento?'
    answer: 'Os verbos do ciclo de vida: o provisionamento cria a conta e concede os direitos quando alguém entra ou muda de papel; o desprovisionamento os revoga na saída. Automatizado via padrões como o SCIM. Desprovisionamento que falha deixa contas órfãs — perenemente um dos principais achados de auditoria e um ponto de apoio favorito de atacantes.'
  - question: 'Qual a diferença entre IAM corporativo (workforce) e CIAM?'
    answer: 'Público e prioridades. O IAM de força de trabalho gerencia funcionários — milhares de usuários, controles impostos pela TI, menor privilégio e compliance em primeiro lugar. O IAM de clientes (CIAM) gerencia os usuários do seu app — potencialmente milhões, cadastro self-service, login social, onde UX, conversão e consentimento de privacidade lideram. A maioria dos desenvolvedores de apps está construindo CIAM, use a palavra ou não.'
  - question: 'Como o IAM se relaciona com zero trust?'
    answer: 'Zero trust — nunca confie, sempre verifique — substitui o perímetro de rede pela identidade: toda requisição é autenticada e autorizada, não importa de onde venha. O IAM é o maquinário que torna isso possível — e é por isso que "identidade é o novo perímetro" virou o slogan da disciplina.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST SP 800-63-4 — Digital Identity Guidelines'
    url: 'https://pages.nist.gov/800-63-4/'
  - name: 'NIST Identity & Access Management program'
    url: 'https://www.nist.gov/identity-access-management'
  - name: 'OpenID Connect Core 1.0'
    url: 'https://openid.net/specs/openid-connect-core-1_0.html'
  - name: 'RFC 7644 — SCIM Protocol'
    url: 'https://datatracker.ietf.org/doc/html/rfc7644'
  - name: 'Identity and access management — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Identity_and_access_management'
cta:
  title: 'IAM em nível de app, pré-montado'
  text: 'O Back4app entrega os primitivos de IAM que seu app precisa no primeiro dia — repositório de usuários, sessions, papéis, ACLs, verificação de e-mail, login social, MFA — aplicados pela plataforma em toda requisição.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: identity-access-management-iam
---

**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

| Pergunta | Resposta |
| --- | --- |
| Os quatro pilares | Autenticação · autorização · ciclo de vida · auditoria |
| O slogan | Pessoas certas, acesso certo, recursos certos, momento certo |
| Os dois mundos | IAM de força de trabalho (funcionários, compliance) · CIAM (os usuários do seu app, UX) |
| Os padrões | OIDC e OAuth para tokens · SAML para SSO corporativo · SCIM para ciclo de vida · WebAuthn para credenciais |
| A versão do desenvolvedor | Repositório de usuários + sessions + papéis + ACLs + recuperação — construa ou herde |

## 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:

```text
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:**

```javascript
// 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: 'ada@example.com' });

// 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
// 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, 'ada@example.com');
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)
```

**Swift:**

```swift
// 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 = "ada@example.com"
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)
```

**Kotlin:**

```kotlin
// 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 = "ada@example.com"
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:

| | Autenticação (AuthN) | Autorização (AuthZ) |
| --- | --- | --- |
| Pergunta | Quem é você? | O que você pode fazer? |
| Evidência | Credenciais, códigos de [MFA](/glossary/pt/autenticacao-multifator-mfa/), biometria, passkeys | Papéis, permissões, [ACLs](/glossary/pt/listas-de-controle-de-acesso-acl/), políticas |
| Acontece | Uma vez por session | Em cada ação |
| Produz | Uma session ou um [token](/glossary/pt/json-web-token-jwt/) | Um permitir/negar por requisição |
| Falha como | Roubo de conta | Escalação de privilégios, exposição de dados |

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.

```mermaid
flowchart LR
  accTitle: Fluxo de requisição do IAM através dos quatro pilares
  accDescr: Um usuário se autentica contra o repositório de identidades e recebe uma session. Cada requisição é então autorizada contra papéis e permissões antes de chegar aos recursos, enquanto a gestão do ciclo de vida governa a existência da conta e o logging de auditoria registra os eventos de autenticação e autorização.
  U["Usuário"] -->|"credenciais + MFA"| AN["Autenticação<br/>repositório de identidades · IdP"]
  AN -->|"session / token"| AZ["Autorização<br/>papéis · permissões · ACLs"]
  AZ --> R[("Recursos")]
  L["Ciclo de vida<br/>entrar · mudar · sair"] -.->|"governa as contas"| AN
  AN -.-> AU["Auditoria<br/>quem fez o quê, quando"]
  AZ -.-> AU
```

## 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](/glossary/pt/controle-de-acesso-rbac/), 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:

| Padrão | O que faz | Onde você o encontra |
| --- | --- | --- |
| [OAuth 2.0](/glossary/pt/oauth-2-login-social/) | Autorização delegada — tokens com escopo em vez de senhas compartilhadas | Acesso a APIs, o encanamento sob o login social |
| OpenID Connect | Autenticação sobre o OAuth — ID tokens assinados atestam quem fez login | Todo botão de "Entrar com…", SSO moderno |
| SAML 2.0 | Asserções de federação em XML — o irmão mais velho corporativo do OIDC | Integrações de SSO corporativo |
| SCIM | API padrão para provisionar/desprovisionar contas | Automação de ciclo de vida na força de trabalho |
| WebAuthn / FIDO2 | Credenciais de chave pública resistentes a phishing | Passkeys, chaves de segurança de hardware |
| [JWT](/glossary/pt/json-web-token-jwt/) | O formato de token em que as asserções viajam | ID tokens, access tokens |
| LDAP | Protocolo de consulta a diretórios | Repositórios de identidade legados |

## Workforce IAM vs. CIAM

| | IAM de força de trabalho | IAM de clientes (CIAM) |
| --- | --- | --- |
| Usuários | Funcionários, terceirizados — milhares | Os usuários do seu app — até milhões |
| Onboarding | A TI provisiona você | Cadastro self-service — fricção mata conversão |
| Autenticação | SSO corporativo, MFA obrigatório | Login social, passwordless, MFA opcional |
| Prioridades | Menor privilégio, compliance | UX, conversão, consentimento de privacidade |
| Ciclo de vida | Entrar/mudar/sair guiado pelo RH | Registrar/engajar/abandonar/excluir guiado pelo usuário |
| Comprador | TI e segurança | O time de produto — muitas vezes se *constrói*, não se compra |

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

| Situação | Tendência |
| --- | --- |
| Auth em nível de app para um produto | Herde de um BaaS — do repositório de usuários ao MFA, pré-construído |
| SSO de força de trabalho entre ferramentas SaaS | Compre um serviço de IdP |
| Controle total, auto-hospedado, protocolos padrão | IdP open-source (Keycloak, Ory) |
| Um app, necessidades simples, sessions do framework | Construa o mínimo — mas planeje recuperação e auditoria |
| Verificação de identidade regulada | Compre — níveis de garantia são trabalho de certificação |
| Fazer o próprio armazenamento de senhas "por enquanto" | Não faça — esta é a única roda que não se reinventa |

## 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](/glossary/pt/oauth-2-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](/glossary/pt/controle-de-acesso-rbac/) e [ACLs](/glossary/pt/listas-de-controle-de-acesso-acl/) 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.