What AWS Cognito is
AWS Cognito, which Amazon Web Services calls Amazon Cognito, is an identity platform for web and mobile apps: a user directory, an authentication server and an authorisation service in one. Its user pools sign people in with passwords, passkeys or one-time codes, through Google, Apple or Facebook, or through an enterprise SAML or OpenID Connect provider, and issue standard tokens.
It lives in the same AWS account, regions and tooling as the rest of a team's stack, which makes it a natural choice for companies already on AWS. That is why it is one of the identity providers our authentication module connects to.
What it does in your platform
Authentication
Holds your customers' accounts in a Cognito user pool and signs them in, with passkeys, one-time codes, multi-factor and social sign-in set up in Cognito. The module checks Cognito's tokens and adds its own trusted devices, sessions and the second factor on payments.
How the connection works
The module talks to your user pool through its OpenID Connect endpoints and the Cognito API, and our Flutter apps sign in through AWS Amplify's Flutter library. Every token Cognito issues is checked on the server before a session opens.
A customer signs in
The app starts sign-in against your user pool, offering the methods you enabled: a passkey, a one-time code by email or SMS, or a password.
Cognito weighs the risk
With threat protection on, Cognito scores each sign-in from its device and location and can require multi-factor or block it. It also checks passwords against known leaks.
Tokens come back
Cognito issues an ID token and an access token, signed JSON web tokens the module checks before it opens a session on the customer's device.
A payment asks for more
Confirming a transfer or a card payment asks for the second factor strong customer authentication requires, on top of the Cognito session.
Activity is kept
Cognito logs sign-in activity with its risk assessment and can export it to your AWS storage, and the module's own sign-in and session events show up in the backoffice.
Next to other providers
Cognito can sign in your customers while staff use your company directory through the backoffice's single sign-on. A user pool can also sit in front of other providers, accepting sign-in from Google, Apple or an enterprise SAML or OpenID Connect provider such as Okta, so the module sees one set of tokens.
Moving onto Cognito can happen gradually: its migrate-user trigger brings each account across from your old directory the first time its owner signs in. Moving off it later is a configuration change for the module, and your apps stay the same.
When AWS Cognito fits best
A strong fit when
- Your platform runs on AWS and you want identity in the same account and region.
- You want passkeys, one-time codes and social sign-in from a managed service, without running an identity server.
- You are moving off another provider and want accounts to move across as customers sign in.
Also worth a look
- Auth0 or Firebase Authentication, when your stack is not centred on AWS.
- Keycloak, when identity must run on infrastructure you operate yourselves.
How we get you live
The AWS account
We set Cognito up in your AWS account, in the region your customers' data should stay in.
The user pool
We set up the user pool with you: sign-in methods, multi-factor rules, threat protection, social providers and the email and SMS messages Cognito sends.
The keys
App client secrets and AWS credentials go into your platform's secrets and nowhere else. The apps only carry public identifiers.
A full test run
We run sign-up, sign-in, a blocked attempt and a confirmed payment against a separate test user pool before your first real customer.
