AWS Cognito Support
Amazon Cognito SAML and social identity provider federation.
Federation lets users sign in with a corporate SAML provider or a social account, and Cognito then issues its own tokens. Setup fails in predictable ways: wrong redirect URIs, missing attribute mappings and duplicate users for the same person. We configure it end to end and fix those errors.
When You Need This
The situations where this work pays for itself.
Signs it is time
- Sign-in with a SAML or social provider fails with redirect_mismatch or a generic error
- Federated users appear in the pool as separate duplicate accounts
- Required attributes such as email are missing after sign-in
- An enterprise customer needs to sign in with their own identity provider
- The hosted UI shows no provider button or the callback URL is rejected
What you get
- Identity providers, app client and domain in infrastructure as code
- An attribute mapping table per provider
- A linking strategy and trigger
- Per-provider setup instructions to give to customers
How we do it
A clear, safe process you can follow along with.
1. Set up the hosted UI domain and app client
Federation uses the pool's domain, either a Cognito prefix or a custom domain, and an app client with the identity providers enabled, valid callback URLs and OAuth flows. Callback URLs must match exactly, including trailing slashes.
2. Configure the SAML provider
We add the identity provider with its metadata URL or file, then give the provider Cognito's service provider values: the ACS URL https://DOMAIN/saml2/idpresponse and the entity ID urn:amazon:cognito:sp:POOL_ID.
3. Configure social providers
For Google, Apple or Facebook we register the app with the provider and add the redirect URI https://DOMAIN/oauth2/idpresponse, then enter the client ID and secret, and request the right scopes.
4. Map attributes
We map provider attributes, usually email and name, to Cognito attributes. If the pool requires an attribute the provider does not send, sign-in fails, so we align requirements or add a pre sign-up or post authentication trigger.
5. Link or prevent duplicate users
The same person can create separate native and federated users. We use a pre sign-up Lambda with AdminLinkProviderForUser to link accounts after verifying ownership, rather than blindly trusting email.
6. Test each provider and clock/certificate details
We test sign-in and sign-out per provider, with encrypted assertions and signed requests if required, and note certificate expiry dates for SAML so rotation does not cause an outage.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Mismatched callback URLs
A small difference gives redirect_mismatch. Match exactly.
Linking accounts by unverified email
It can allow account takeover. Only link verified identities.
Ignoring SAML certificate rotation
An expired signing certificate breaks sign-in for that customer.
Requiring attributes providers do not send
Sign-in then fails for those users.
Frequently Asked Questions
What are the SAML values to give my identity provider?
The ACS URL is your Cognito domain plus /saml2/idpresponse, and the audience (entity ID) is urn:amazon:cognito:sp: followed by the user pool ID.
Why do I get duplicate users for the same person?
Cognito creates a separate user per provider identity. Linking them with a pre sign-up trigger and AdminLinkProviderForUser combines them.
Can one user pool support many SAML providers?
Yes. A pool can have multiple identity providers, subject to current quotas, and you can route users by email domain or an identity provider hint.
Want Help With Amazon Cognito SAML and social identity provider federation?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required