“SSO between Cognito and Salesforce” describes two opposite trust directions. Configuration fails when the identity provider (IdP), relying party (RP), token issuer, and callback owner change halfway through the design. Choose one topology from the user journey and write it down before opening either console.
This guide was verified on 2026-08-01 against the official AWS documentation for [Cognito user pools with OIDC providers](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-oidc-idp.html), [Cognito federation endpoints](https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints.html), and [Cognito security practices](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-security-best-practices.html), plus Salesforce guidance for [External Client Apps](https://developer.salesforce.com/docs/platform/accsdk/guide/acc-sdk-setup-auth-external.html) and [OIDC single logout](https://help.salesforce.com/s/articleView?id=xcloud.security_auth_slo_oidc_idp_configuring.htm&language=en_US&type=5).
## Topology A: Cognito is the IdP, Salesforce is the RP
Use this when users should enter Salesforce with an identity represented by a Cognito user pool. Salesforce creates an OpenID Connect Authentication Provider that trusts Cognito. The browser starts at Salesforce, goes to the Cognito authorization endpoint, and returns to the exact callback URL generated by Salesforce.
1. Give the user pool a domain and an app client using the authorization-code grant.
2. In Salesforce, create an OpenID Connect Auth Provider. Copy its generated callback URL exactly into the Cognito app client's allowed callback URLs.
3. Configure Salesforce from Cognito's discovery metadata rather than guessing endpoint paths. Cognito publishes discovery under its issuer and signing keys through JWKS. Cache keys by `kid`, refresh them on an unknown key, and validate issuer, audience, signature, expiry, and nonce.
4. Request only needed scopes, normally `openid` plus approved profile claims.
5. Implement a Salesforce Registration Handler that maps an immutable external subject to an existing user or performs tightly controlled just-in-time (JIT) provisioning.
The Cognito app client is confidential when Salesforce authenticates to the token endpoint with a secret. Store that secret only in the platform configuration intended for the Auth Provider. Do not put it in browser code, source control, screenshots, or an Apex custom setting readable by ordinary users.
The Registration Handler must not match accounts by an unverified, mutable email address alone. Prefer the tuple of trusted issuer and `sub`, preserve that external identifier, allowlist acceptable tenant or group claims, and apply least-privilege profiles and permission sets. Decide what happens when a user is disabled at the source; JIT creation without deprovisioning produces stale access.
## Topology B: Salesforce is the IdP, Cognito is the RP/broker
Use this when a Salesforce identity should sign users into an application that receives Cognito-issued tokens. Salesforce authorizes the Cognito OIDC client, Cognito validates Salesforce tokens and maps claims, then Cognito issues its own user-pool tokens to the application.
1. Configure My Domain and create a Salesforce **External Client App** for new OAuth integrations where Salesforce is the authorization server. Enable the authorization-code flow and the policy controls required by the org.
2. Register Cognito's exact OIDC callback as the Salesforce callback. For a Cognito user-pool OIDC provider, AWS documents the callback in the form `https://<user-pool-domain>/oauth2/idpresponse`.
3. In Cognito, add Salesforce as an OIDC IdP. Use the Salesforce My Domain discovery document: `https://<my-domain>.my.salesforce.com/.well-known/openid-configuration`.
4. Confirm that discovery returns HTTPS authorization, token, user-info, and JWKS endpoints compatible with Cognito. AWS currently requires the provider's supported client authentication behavior described in its OIDC IdP prerequisites.
5. Map Salesforce claims to mutable and required Cognito attributes deliberately. Cognito automatically maps the upstream OIDC `sub` into its federated identity; do not overwrite identity keys with display names.
6. Enable this IdP for the intended Cognito app client and initiate sign-in through Cognito managed login or its authorize endpoint. The application accepts Cognito tokens, not upstream Salesforce tokens.
External Client App policies should restrict who may authorize, scopes, session behavior, refresh-token use, and administrative approval. A public browser or native client must use authorization code with PKCE and must not contain a client secret. In this topology Cognito acts as a server-side OIDC client to Salesforce, so confirm the exact client-authentication method supported by both products rather than copying a public-client recipe.
## Browser request controls
For application-to-Cognito authorization requests, use authorization code with PKCE (`S256`). Generate a high-entropy `state` value, bind it to the browser transaction, and compare it on return to prevent login CSRF. Generate and validate `nonce` for OIDC replay protection. Use exact HTTPS redirect URIs; do not allow wildcards, substring matching, or user-provided return origins.
Keep the post-login destination separate from `redirect_uri`. Store an allowlisted relative route server-side or in integrity-protected state. Never redirect directly to an arbitrary `startURL`, RelayState, or query-string URL supplied by a caller.
## Claims, JIT, and authorization
OIDC proves an authentication event; it does not define the user's application permissions. Document each required claim, its issuer, data type, mutability, and destination. Treat groups and roles as authorization input only after verifying the issuer and applying an allowlist. Minimize personally identifiable claims and avoid putting sensitive internal attributes in tokens visible to the browser.
Test existing-user linking, first login, changed email, duplicate email, disabled user, missing claim, unexpected tenant, and a user with no authorized role. JIT provisioning should fail closed and produce an auditable event. Define deprovisioning through lifecycle automation, short sessions, token revocation, or a combination appropriate to the risk.
## Logout is a separate protocol decision
Clearing the local application cookie does not end the Cognito, Salesforce, or upstream corporate IdP session. Define which sessions a “Log out” action should end. Cognito exposes a managed-login logout endpoint; Salesforce documents front-channel OIDC single logout when Salesforce is the provider. Product support is not symmetric, so test RP-initiated logout, IdP-initiated logout where supported, post-logout redirect allowlists, refresh-token revocation, and login from a shared browser.
## Migration and verification checklist
1. Draw browser, app, Cognito, and Salesforce with arrows for authorize, callback, token, user-info, and logout.
2. Record issuer, discovery URL, JWKS URL, client owner, exact callbacks, scopes, and secret owner.
3. Start in non-production orgs and use test accounts with no privileged profile.
4. Verify PKCE, `state`, `nonce`, issuer, audience, expiry, signature, and key rotation.
5. Review claim mappings and JIT/deprovisioning with Salesforce and identity administrators.
6. Test callback mismatch, invalid state/nonce, expired code, unknown `kid`, disabled user, logout, and rollback.
7. Capture audit logs from Cognito, Salesforce Login History, and the application without logging codes, tokens, or secrets.
8. Promote exact configuration through infrastructure or change control; do not retype production callbacks from memory.
The acceptance gate is a complete browser trace in the chosen topology, least-privilege authorization after login, predictable logout, and a documented rollback that disables the new trust without locking out administrators.
“SSO between Cognito and Salesforce” describes two opposite trust directions. Configuration fails when the identity provider (IdP), relying party (RP), token issuer, and callback owner change halfway through the design. Choose one topology from the user journey and write it down before opening either console.
Topology A: Cognito is the IdP, Salesforce is the RP
Use this when users should enter Salesforce with an identity represented by a Cognito user pool. Salesforce creates an OpenID Connect Authentication Provider that trusts Cognito. The browser starts at Salesforce, goes to the Cognito authorization endpoint, and returns to the exact callback URL generated by Salesforce.
Give the user pool a domain and an app client using the authorization-code grant.
In Salesforce, create an OpenID Connect Auth Provider. Copy its generated callback URL exactly into the Cognito app client’s allowed callback URLs.
Configure Salesforce from Cognito’s discovery metadata rather than guessing endpoint paths. Cognito publishes discovery under its issuer and signing keys through JWKS. Cache keys by kid, refresh them on an unknown key, and validate issuer, audience, signature, expiry, and nonce.
Request only needed scopes, normally openid plus approved profile claims.
Implement a Salesforce Registration Handler that maps an immutable external subject to an existing user or performs tightly controlled just-in-time (JIT) provisioning.
The Cognito app client is confidential when Salesforce authenticates to the token endpoint with a secret. Store that secret only in the platform configuration intended for the Auth Provider. Do not put it in browser code, source control, screenshots, or an Apex custom setting readable by ordinary users.
The Registration Handler must not match accounts by an unverified, mutable email address alone. Prefer the tuple of trusted issuer and sub, preserve that external identifier, allowlist acceptable tenant or group claims, and apply least-privilege profiles and permission sets. Decide what happens when a user is disabled at the source; JIT creation without deprovisioning produces stale access.
Topology B: Salesforce is the IdP, Cognito is the RP/broker
Use this when a Salesforce identity should sign users into an application that receives Cognito-issued tokens. Salesforce authorizes the Cognito OIDC client, Cognito validates Salesforce tokens and maps claims, then Cognito issues its own user-pool tokens to the application.
Configure My Domain and create a Salesforce External Client App for new OAuth integrations where Salesforce is the authorization server. Enable the authorization-code flow and the policy controls required by the org.
Register Cognito’s exact OIDC callback as the Salesforce callback. For a Cognito user-pool OIDC provider, AWS documents the callback in the form https://<user-pool-domain>/oauth2/idpresponse.
In Cognito, add Salesforce as an OIDC IdP. Use the Salesforce My Domain discovery document: https://<my-domain>.my.salesforce.com/.well-known/openid-configuration.
Confirm that discovery returns HTTPS authorization, token, user-info, and JWKS endpoints compatible with Cognito. AWS currently requires the provider’s supported client authentication behavior described in its OIDC IdP prerequisites.
Map Salesforce claims to mutable and required Cognito attributes deliberately. Cognito automatically maps the upstream OIDC sub into its federated identity; do not overwrite identity keys with display names.
Enable this IdP for the intended Cognito app client and initiate sign-in through Cognito managed login or its authorize endpoint. The application accepts Cognito tokens, not upstream Salesforce tokens.
External Client App policies should restrict who may authorize, scopes, session behavior, refresh-token use, and administrative approval. A public browser or native client must use authorization code with PKCE and must not contain a client secret. In this topology Cognito acts as a server-side OIDC client to Salesforce, so confirm the exact client-authentication method supported by both products rather than copying a public-client recipe.
Browser request controls
For application-to-Cognito authorization requests, use authorization code with PKCE (S256). Generate a high-entropy state value, bind it to the browser transaction, and compare it on return to prevent login CSRF. Generate and validate nonce for OIDC replay protection. Use exact HTTPS redirect URIs; do not allow wildcards, substring matching, or user-provided return origins.
Keep the post-login destination separate from redirect_uri. Store an allowlisted relative route server-side or in integrity-protected state. Never redirect directly to an arbitrary startURL, RelayState, or query-string URL supplied by a caller.
Claims, JIT, and authorization
OIDC proves an authentication event; it does not define the user’s application permissions. Document each required claim, its issuer, data type, mutability, and destination. Treat groups and roles as authorization input only after verifying the issuer and applying an allowlist. Minimize personally identifiable claims and avoid putting sensitive internal attributes in tokens visible to the browser.
Test existing-user linking, first login, changed email, duplicate email, disabled user, missing claim, unexpected tenant, and a user with no authorized role. JIT provisioning should fail closed and produce an auditable event. Define deprovisioning through lifecycle automation, short sessions, token revocation, or a combination appropriate to the risk.
Logout is a separate protocol decision
Clearing the local application cookie does not end the Cognito, Salesforce, or upstream corporate IdP session. Define which sessions a “Log out” action should end. Cognito exposes a managed-login logout endpoint; Salesforce documents front-channel OIDC single logout when Salesforce is the provider. Product support is not symmetric, so test RP-initiated logout, IdP-initiated logout where supported, post-logout redirect allowlists, refresh-token revocation, and login from a shared browser.
Migration and verification checklist
Draw browser, app, Cognito, and Salesforce with arrows for authorize, callback, token, user-info, and logout.
Record issuer, discovery URL, JWKS URL, client owner, exact callbacks, scopes, and secret owner.
Start in non-production orgs and use test accounts with no privileged profile.
Review claim mappings and JIT/deprovisioning with Salesforce and identity administrators.
Test callback mismatch, invalid state/nonce, expired code, unknown kid, disabled user, logout, and rollback.
Capture audit logs from Cognito, Salesforce Login History, and the application without logging codes, tokens, or secrets.
Promote exact configuration through infrastructure or change control; do not retype production callbacks from memory.
The acceptance gate is a complete browser trace in the chosen topology, least-privilege authorization after login, predictable logout, and a documented rollback that disables the new trust without locking out administrators.