DEV Community

Cover image for Amazon Cognito - Entendendo User Pool e Identity Pool
Eduardo Rabelo
Eduardo Rabelo

Posted on

Amazon Cognito - Entendendo User Pool e Identity Pool

Créditos da Imagem

O Amazon Cognito é um serviço da AWS que permite adicionar facilmente o gerenciamento de usuários a aplicativos da web e móvel. Ele oferece suporte a provedores de identidade social, como Facebook, Google e provedores de identidade corporativa via SAML 2.0.

Um serviço poderoso.
No começo, difícil de entender.

Uma das coisas que geram a maior confusão é o fato de que o Amazon Cognito vem com dois componentes principais:

  • Amazon Cognito User Pools
  • Amazon Cognito Identity Pools (também conhecido como Federated Identities)

Esta é a primeira dificuldade, pois em linguagem comum, usuários e identidades são quase a mesma coisa.

Nesse artigo, tentaremos esclarecer as diferenças reais e quais cenários podem ser resolvidos usando um desses componentes ou combinando os dois.

Cognito User Pool

De acordo com a documentação oficial da AWS:

Um pool de usuários é um diretório de usuários no Amazon Cognito. Com um pool de usuários, seus usuários podem entrar em seu aplicativo da web ou móvel por meio do Amazon Cognito […]

Isso significa que um usuário anônimo de nosso aplicativo (por exemplo, um aplicativo móvel ou de página única) pode preencher um formulário de registro e se tornar um usuário registrado. As credenciais escolhidas (ou seja, nome de usuário e senha) serão armazenadas com segurança no Cognito User Pool .

Nesse caso, Amazon Cognito atua como um provedor de identidade (IdP) .

Quando este usuário registrado deseja efetuar login, o Pool de usuários será usado como a fonte da verdade para avaliar a autenticidade das credenciais fornecidas; se for válido, um JSON Web Token (JWT) será retornado (clique aqui , se quiser saber mais sobre o JWT).

Fig.1 - Durante o login de um usuário, o Cognito User Pool fará o processo de verificação da credencial, caso seja válido, um JWT será emitido. Esse token pode eventualmente ser usado para invocar APIs protegidas.

Eventualmente, se tivermos uma API protegida (por exemplo GET /orders/42), esse token pode ser usado para autenticar solicitações (Fig.2) por meio do cabeçalho Authorization.

Se esta API foi criada usando o Amazon API Gateway, existe a oportunidade de protegê-la facilmente por meio da integração com Cognito User Pool. Nesse cenário, o API Gateway solicitará que o pool de usuários do Amazon Cognito valide esse token; se for bem-sucedido, a função de backend Lambda será chamada.

Fig.2 - API Gateway pode ser integrado nativamente com Cognito User Pool para validar o JWT fornecido.

Fácil como domingo de manhã.

Mas e se nosso aplicativo precisar interagir diretamente com o DynamoDB (Fig.3)?

Cognito Identity Pool

Normalmente, as APIs REST são protegidas por meio do uso de um token - por exemplo, um JSON Web Token (JWT) - e é por isso que o Amazon API Gateway com a ajuda do Cognito User Pool suporta este cenário nativamente.

Fig.3 - As vezes, seu aplicativo no cliente pode querer acessar diretamente um serviço AWS (por exemplo, DynamoDB) sem o API Gateway como proxy. O JWT ainda será útil?

Infelizmente, a grande maioria dos recursos da AWS não oferece suporte a um JWT como meio de autenticação ! Por exemplo, se nosso aplicativo fosse ler o item de pedido 42 diretamente do DynamoDB, precisamos de uma IAM Role que tenha permissão para ler dados da tabela Pedidos .

E aí vem o Cognito Identity Pool:

Os pools de identidade fornecem credenciais da AWS para conceder aos usuários acesso a outros serviços da AWS.

Aqui, "seus usuários" são os usuários registrados em nosso Cognito User Pool (* ressalvas abaixo).

Para permitir que os usuários em seu pool de usuários acessem recursos da AWS, você pode configurar um pool de identidade para trocar tokens do pool de usuários por credenciais da AWS.

Para permitir que esses usuários acessem diretamente o DynamoDB e leiam o pedido fornecido, não podemos usar o JWT diretamente; mas temos que usar o Cognito Identity Pool para negociar o JWT com uma chave de acesso e uma chave secreta (Fig.4).

Fig.4

Cada par de chaves tem uma IAM Role associada ao conjunto certo de permissões.

Aqui, graças ao Identity Pool, o Amazon Cognito atua como um Identity Broker.

( * ) Algumas ressalvas

Em um cenário simples, tudo pode ser resumido em uma regra geral:

1 - Se nosso aplicativo precisar acessar um endereço do API Gateway, o Cognito User Pool é suficiente.

2 - Se nosso aplicativo precisa se comunicar diretamente com um serviço AWS (DynamoDB, S3, ...), precisamos do Amazon Cognito Identity Pool também.

Como sabemos, as coisas não são necessariamente pretas ou brancas e a vida real tem muitas nuances. Por exemplo, nosso aplicativo pode ter usuários registrados em um provedor de identidade de terceiros e, neste caso, usaríamos o Cognito Identity Pool, mas não o Cognito User Pool (mais informações na seção Leitura adicional ).

Conclusão

Mesmo as coisas mais mundanas, se não forem bem compreendidas, parecerão difíceis. Amazon Cognito não é exceção. Espero que esse artigo ajude aqueles que não tinham uma compreensão muito clara do assunto

Imagem para postagem
Se você gostou desse post, por favor apoie meu trabalho!

Leitura adicional


Créditos

Top comments (0)