Amazon Cognito: Autenticação e Identidade de Usuários em Aplicações na Nuvem

Eduardo Souza | CEO Dominit

Toda aplicação que atende clientes externos — um portal, um app mobile, uma API pública — precisa resolver o mesmo problema antes de entregar qualquer funcionalidade: quem é esse usuário, e como confirmar isso sem reinventar login, senha, recuperação de conta e autenticação multifator do zero. A franquia gratuita do Amazon Cognito cobre até 10.000 usuários ativos por mês autenticando-se diretamente ou via provedor social, e 50 usuários ativos via SAML ou OpenID Connect — números pequenos o bastante para mostrar que o serviço foi desenhado para começar barato e crescer junto com a base de usuários. Neste guia, você vai entender como o Cognito funciona, por que ele resolve um problema diferente do IAM da conta AWS, e como decidir entre os modelos de implementação disponíveis.

O Que É o Amazon Cognito e Como Ele Funciona

O Amazon Cognito é uma plataforma de identidade para aplicações web e mobile: um diretório de usuários, um servidor de autenticação e um serviço de autorização de tokens OAuth 2.0 e credenciais AWS, tudo em um único serviço gerenciado. Na prática, ele resolve o mesmo problema que uma equipe de desenvolvimento historicamente construía na mão — tabela de usuários, hash de senha, fluxo de confirmação de e-mail, emissão e renovação de token — só que operado pela AWS, com os padrões de segurança que a AWS já aplica ao restante da própria infraestrutura.

O serviço é dividido em dois componentes que operam de forma independente ou em conjunto, dependendo da necessidade: User Pools e Identity Pools. Essa divisão confunde muita gente que chega ao Cognito pela primeira vez — e entender exatamente onde termina um e começa o outro é o que evita desenhar uma arquitetura de autenticação capenga.

User Pools: o Diretório e Servidor de Autenticação

Um User Pool é um diretório de usuários com autenticação embutida. Ele guarda o perfil de cada usuário (local ou federado de um provedor terceiro), processa o login, aplica MFA, e emite JSON Web Tokens (JWT) que a aplicação usa para saber quem está autenticado. Ele pode atuar como um provedor de identidade OpenID Connect (OIDC) autônomo, ou como intermediário entre provedores de identidade corporativos (SAML, OIDC, Active Directory Federation Services) e sociais (Google, Facebook, Amazon, Apple) e a própria aplicação — padronizando tudo num único formato de token, independentemente de como o usuário realmente se autenticou.

Um User Pool não depende de um Identity Pool para funcionar: se a aplicação só precisa saber "este usuário está autenticado, entregue o conteúdo dele", o User Pool sozinho já resolve.

Identity Pools: a Ponte para Credenciais AWS Temporárias

Um Identity Pool resolve um problema diferente: dar a um usuário (autenticado ou anônimo) credenciais temporárias da AWS para acessar recursos diretamente — um bucket do Amazon S3, uma tabela do Amazon DynamoDB — sem que a aplicação precise expor uma chave de acesso fixa embutida no código do cliente. O Identity Pool troca a prova de autenticação (um token de User Pool, uma asserção SAML, um token social) por credenciais de curta duração emitidas pelo AWS Security Token Service (STS), com permissões controladas por controle de acesso baseado em papel (RBAC) ou em atributos (ABAC).

Assim como o User Pool, o Identity Pool também não exige integração com um User Pool — ele pode aceitar identidades autenticadas diretamente de provedores corporativos ou sociais. Mas o padrão mais comum em aplicações reais é usar os dois em conjunto: o usuário se autentica no User Pool, recebe um token, troca esse token no Identity Pool por credenciais temporárias, e a aplicação usa essas credenciais para falar com outros serviços AWS em nome do usuário.

Critério	User Pools	Identity Pools
O que entrega	Autenticação e diretório de usuários (tokens JWT)	Credenciais AWS temporárias via STS
Uso típico	Login, cadastro, MFA, perfil do usuário na aplicação	Acesso direto do cliente a recursos AWS (S3, DynamoDB)
Depende do outro componente	Não	Não
Suporta usuário anônimo	Não	Sim (acesso não autenticado)
Controle de acesso	Grupos de usuários, escopos OAuth	RBAC e ABAC via IAM
Quando usar sozinho	App só precisa saber quem é o usuário	App já tem outro provedor de identidade e só quer credenciais AWS

Amazon Cognito vs. IAM: Duas Camadas de Identidade Diferentes

Esse é o ponto onde mais equipes técnicas se confundem, inclusive equipes experientes migrando de uma arquitetura on-premises: Cognito e IAM resolvem problemas de identidade, mas em camadas completamente diferentes da operação.

O AWS Identity and Access Management (IAM) controla quem — dentro da empresa, entre os times de infraestrutura, ou entre serviços internos da própria AWS — pode fazer o quê nos recursos da conta AWS. É a camada de permissão administrativa: quem pode criar uma instância EC2, quem pode ler um bucket S3 de produção, qual papel uma função Lambda assume para gravar num banco de dados. É sobre a operação interna da infraestrutura, e o assunto já foi tratado em profundidade no artigo Zero Trust e IAM Avançado na AWS, que cobre políticas de menor privilégio, papéis e redução de superfície de ataque dentro da conta.

O Amazon Cognito controla quem — os clientes, usuários finais, assinantes de um SaaS, o público de um aplicativo — pode entrar e usar a aplicação que a empresa constrói e vende. É gestão de identidade de cliente (CIAM, Customer Identity and Access Management): cadastro, login, recuperação de senha, MFA, federação social e corporativa para o usuário final. Ninguém da equipe de infraestrutura assume um papel via Cognito para administrar um recurso AWS; é o cliente do produto que se autentica ali.

A confusão mais comum acontece justamente na ponte entre os dois: um Identity Pool do Cognito pode emitir credenciais que assumem um papel IAM — mas esse papel é limitado ao que aquele usuário específico da aplicação pode fazer (por exemplo, ler apenas os próprios arquivos num bucket S3), nunca o mesmo nível de acesso que uma política IAM administrativa concede a um operador interno. Tratar as duas camadas como intercambiáveis é o tipo de erro de desenho que resulta em usuários finais com permissões amplas demais na conta AWS — o oposto do que a disciplina de Zero Trust recomenda.

Aspecto	Amazon Cognito	AWS IAM
Quem gerencia	Usuários finais da aplicação (clientes)	Usuários internos, equipes e serviços da AWS
Escopo	Autenticação e identidade de cliente (CIAM)	Autorização de acesso a recursos AWS
Interface principal	Login, cadastro, MFA, hosted UI/managed login	Console AWS, políticas JSON, papéis
Exemplo de uso	Cliente faz login no app de e-commerce da empresa	Time de DevOps acessa o CloudWatch de produção
Ponte entre os dois	Identity Pool troca token do usuário por credenciais AWS limitadas	Papel IAM assumido define o limite dessas credenciais

O ganho central do Cognito não é "ter login" — qualquer aplicação tem isso. É não precisar manter a parte de segurança de identidade atualizada manualmente enquanto o produto evolui.

Autenticação multifator (MFA) está disponível via SMS, aplicativo autenticador (TOTP) em todos os planos, e por e-mail nos planos Essentials e Plus — sem que a equipe precise integrar um provedor de SMS ou implementar TOTP do zero. O plano Plus adiciona proteção contra ameaças (threat protection): monitoramento de tentativas de login suspeitas, detecção de senha comprometida em vazamento público, e autenticação adaptativa que exige MFA condicionalmente quando o comportamento de login foge do padrão esperado.

Federação social e corporativa conecta o Cognito a provedores como Google, Facebook, Amazon e Apple via OAuth 2.0 para login de consumidor, e a provedores corporativos via SAML 2.0 ou OIDC — Okta, Microsoft Entra ID, Active Directory Federation Services — para cenários de single sign-on (SSO) com identidades de força de trabalho ou de clientes corporativos (B2B). O Cognito absorve as particularidades de cada protocolo e entrega um token padronizado para a aplicação, o que evita que o time de desenvolvimento escreva um adaptador diferente para cada provedor.

Managed login (a versão atual do que era conhecido como hosted UI) é um conjunto de páginas hospedadas para cadastro, login, MFA e redefinição de senha, com editor visual de marca nos planos Essentials e Plus. A versão clássica do hosted UI, mais limitada e menos personalizável, continua disponível em todos os planos — mas não recebe os recursos mais novos, como autenticação por passkey.

Modelos de Implementação: SPA, Mobile e API Backend

A forma como o Cognito se encaixa na arquitetura muda conforme o tipo de aplicação:

Single Page Applications (SPA) normalmente usam o managed login hospedado pelo Cognito com o fluxo OAuth 2.0 Authorization Code, redirecionando o usuário para as páginas do Cognito e recebendo os tokens de volta via redirect — evita manter estado de sessão sensível diretamente no navegador e reduz a superfície de ataque a XSS que aplicações com login totalmente custom enfrentam.

Aplicações mobile costumam integrar via SDK (usando bibliotecas como o AWS Amplify) para construir uma tela de login nativa em vez de abrir uma WebView para o managed login — a experiência fica mais integrada ao app, ao custo de a equipe assumir mais responsabilidade sobre a interface de autenticação.

APIs backend validam o token de acesso emitido pelo Cognito em cada requisição, tipicamente com um autorizador do Amazon API Gateway ou middleware equivalente, sem que o backend precise conhecer detalhes de como o usuário se autenticou originalmente — social, SAML ou senha local, o resultado chega padronizado como um JWT verificável. Esse padrão combina bem com arquiteturas serverless na AWS, onde cada função Lambda por trás do API Gateway recebe a identidade do usuário já validada, sem gerenciar sessão própria.

Machine-to-machine (M2M) cobre o caso em que quem se autentica não é uma pessoa, mas um serviço automatizado: um app client configurado com client-credentials grant do OAuth 2.0 emite tokens de acesso com escopos definidos, sem exigir usuário nem senha — útil para integrações entre sistemas que não devem herdar identidade humana.

Segurança e Compliance

O modelo de responsabilidade compartilhada da AWS se aplica ao Cognito como a qualquer outro serviço: a AWS garante a segurança da plataforma (patching, disponibilidade, isolamento), e a empresa é responsável pela segurança na configuração — decidir se permite cadastro público, quais fatores de MFA exigir, como tratar erros de autenticação sem vazar se um e-mail existe na base.

Do ponto de vista de compliance, o Cognito é compatível com SOC 1-3, PCI DSS e ISO 27001 na obrigação de "segurança da nuvem" que cabe à AWS, e elegível para HIPAA-BAA. A configuração da empresa (a parte "segurança na nuvem") pode ser desenhada para ficar em conformidade com SOC 1-3, ISO 27001 e HIPAA-BAA — mas não com PCI DSS, o que importa para quem processa dados de cartão diretamente através da autenticação do usuário.

Vale reforçar uma limitação de escopo: MFA e threat protection do Cognito se aplicam a usuários locais — aqueles cadastrados diretamente no diretório do User Pool. Para usuários federados, a postura de segurança do login (força de senha, MFA, monitoramento de tentativas suspeitas) é responsabilidade do provedor de identidade terceiro, não do Cognito. Uma empresa que federa 100% dos usuários via Google ou via SAML corporativo está, na prática, delegando essa parte da segurança ao provedor de origem.

Custos e Métricas: Como o Cognito É Cobrado

O modelo de cobrança do Cognito mudou para uma estrutura de planos de recursos (feature plans) por User Pool, com preço mensal por usuário ativo (MAU — monthly active user):

Lite: plano de baixo custo, cobre autenticação básica e o hosted UI clássico, mas não inclui recursos mais recentes como personalização de token em tempo de execução ou autenticação por passkey.
Essentials: plano padrão para pools novos, inclui os recursos mais atuais de autenticação — login por escolha, MFA por e-mail, senha única (OTP) como primeiro fator, e passkeys via FIDO2/WebAuthn.
Plus: inclui tudo do Essentials e adiciona proteção avançada contra ameaças — detecção de senha vazada, análise de risco de login, exportação de logs de atividade para auditoria.

A franquia gratuita permanente cobre 10.000 MAUs por mês para login direto ou social, e 50 MAUs para federação via SAML/OIDC — sem expirar depois dos 12 meses padrão de free tier da AWS. Acima disso, o custo por MAU varia por plano (a partir de frações de centavo de dólar por usuário no plano Lite, subindo no Essentials e no Plus, que embute os recursos de proteção contra ameaças no preço). Mensagens de SMS para MFA são cobradas separadamente via Amazon SNS, assim como e-mails transacionais via Amazon SES — um detalhe que costuma escapar do orçamento inicial em aplicações com volume alto de recuperação de senha por SMS.

Para efeito de planejamento: o custo do Cognito cresce com o número de usuários ativos, não com o número de logins — uma aplicação com pico sazonal de uso não paga proporcionalmente mais só por causa do volume de autenticações, o que facilita a previsibilidade orçamentária comparado a soluções cobradas por requisição.

Casos de Uso por Porte de Empresa

Empresas menores (30-100 funcionários) lançando um produto digital novo tendem a caber inteiramente na franquia gratuita ou no plano Essentials nos primeiros milhares de usuários, usando o managed login para não gastar tempo de desenvolvimento construindo tela de autenticação — o foco de engenharia fica no produto, não na camada de identidade.

Empresas de porte médio (100-400 funcionários) com aplicações B2B costumam precisar de federação SAML/OIDC desde o início, porque os próprios clientes exigem SSO corporativo como requisito de segurança para fechar contrato — nesse cenário, o plano Essentials já é necessário, e a franquia de 50 MAUs SAML/OIDC é consumida rapidamente.

Empresas maiores (400-700 funcionários) com múltiplas aplicações e requisitos de auditoria geralmente justificam o plano Plus, pelo monitoramento de atividade suspeita e a capacidade de exportar logs de risco para análise externa — parte do mesmo tipo de disciplina de observabilidade que essas empresas já aplicam a outros sistemas críticos.

Nos três casos, o ponto comum é que a decisão de plano deveria ser revisitada conforme a base de usuários cresce, não fixada uma vez no desenho inicial — trocar de plano é uma operação simples pela API ou console, mas alguns recursos precisam ser desativados antes de rebaixar de plano.

Tendências: Passwordless e Passkeys

A direção mais visível na evolução recente do Cognito é o afastamento gradual da senha como único primeiro fator de autenticação. O serviço já suporta login sem senha com código único (OTP) por e-mail ou SMS, e autenticação por passkey baseada nos padrões WebAuthn e FIDO2 — permitindo que o usuário se autentique com biometria do dispositivo (impressão digital, reconhecimento facial) ou uma chave de segurança física, sem digitar nem armazenar senha alguma.

Passkeys exigem o plano Essentials (não estão disponíveis no Lite) e permitem até 20 chaves registradas por usuário — cobrindo o cenário realista de alguém com passkey no notebook, no celular e num token físico de backup. Uma limitação importante para o desenho da experiência: o Cognito não permite combinar MFA tradicional com login sem senha (incluindo passkeys) para o mesmo usuário — a decisão entre "senha + segundo fator" e "passwordless" é estrutural, não uma camada adicional sobre a outra.

Para empresas que avaliam onde investir esforço de modernização de autenticação, a adoção de passkeys tende a reduzir tanto o atrito de login (sem senha esquecida, sem SMS que demora a chegar) quanto a superfície de ataque a phishing de credenciais — mas exige que a base de usuários tenha dispositivos compatíveis, o que ainda limita a adoção total em bases de usuários mais heterogêneas ou legadas.

Perguntas Frequentes sobre Amazon Cognito

Amazon Cognito substitui o AWS IAM?

Não. Eles resolvem problemas diferentes: o Cognito gerencia identidade e login dos usuários finais de uma aplicação, enquanto o IAM controla permissões de acesso a recursos internos da conta AWS. Um Identity Pool do Cognito pode até emitir credenciais que assumem um papel IAM, mas esse papel é limitado ao que aquele usuário específico pode fazer — nunca substitui a governança de acesso administrativo que o IAM oferece.

Preciso de um User Pool e de um Identity Pool ao mesmo tempo?

Não necessariamente. Um User Pool sozinho já resolve aplicações que só precisam autenticar o usuário e emitir tokens. Um Identity Pool entra quando a aplicação também precisa que o cliente (o navegador ou o app mobile) acesse diretamente outros serviços AWS, como um bucket S3, com credenciais temporárias em vez de uma chave fixa.

Sim. O Cognito atua como intermediário entre a aplicação e os provedores sociais via OAuth 2.0, unificando o resultado num token padronizado — a aplicação não precisa integrar cada provedor social separadamente.

Qual a diferença entre o hosted UI clássico e o managed login?

O hosted UI clássico é a versão mais antiga e menos personalizável das páginas de autenticação, disponível em todos os planos. O managed login é a versão atual, com editor visual de marca e suporte aos recursos mais recentes (como passkeys), disponível nos planos Essentials e Plus.

Quanto custa usar o Amazon Cognito?

Depende do plano (Lite, Essentials ou Plus) e do número de usuários ativos mensais (MAU) acima da franquia gratuita — 10.000 MAUs para login direto ou social, 50 MAUs para federação SAML/OIDC. SMS de MFA e e-mails transacionais são cobrados separadamente pelos serviços de mensageria da AWS.

O Cognito suporta autenticação sem senha (passwordless)?

Sim, com código único por e-mail ou SMS e com passkeys baseadas em WebAuthn/FIDO2, disponíveis a partir do plano Essentials. Uma limitação relevante: não é possível combinar MFA tradicional com login passwordless para o mesmo usuário — é uma escolha de modelo, não uma camada extra.

O Cognito é indicado para uma aplicação pequena que ainda não tem muitos usuários?

Sim — a franquia gratuita permanente cobre até 10.000 usuários ativos por mês em login direto ou social, o que costuma ser suficiente para o primeiro ano ou mais de um produto novo, sem custo de infraestrutura de identidade dedicada.

O Cognito Como Camada de Confiança Entre o Usuário e a Aplicação

O Amazon Cognito não compete com o IAM nem o substitui — ele resolve a metade do problema de identidade que o IAM nunca tratou: quem são os clientes que usam a aplicação, e como confirmar isso de forma segura, escalável e sem reconstruir login do zero a cada novo produto. Tratar essas duas camadas — identidade de cliente e permissão de infraestrutura interna — com a mesma disciplina de menor privilégio é o que separa uma arquitetura de nuvem madura de uma que só parece segura até o primeiro incidente.

Empresas que avaliam consolidar autenticação de múltiplas aplicações num único diretório de usuários, ou que precisam de federação corporativa para fechar contratos B2B, tendem a ganhar mais adotando o Cognito cedo — antes que cada novo produto reinvente sua própria camada de login com nível de segurança inconsistente entre si.