If you’re already using AWS, chances are you’re using Cognito for authentication.It fits well with the rest of your stack, supports the basics out of the box, and keeps everything inside your AWS boundary.

When your first enterprise customer asks for SSO, be it with Okta, Entra ID, or Google Workspace, you can technically support it with Cognito. But doing that means wiring up each connection yourself, managing metadata, and becoming the go-to support person for every enterprise IT team you sell to.

That’s exactly where Scalekit comes in and helps you add SSO to your Cognito setup.

It connects to your customer’s identity provider, handles the login flow (SAML or OIDC), and returns control to Cognito, so your sessions, tokens, and users stay exactly where they are.

In this guide, you’ll integrate Scalekit with AWS Cognito and go live with your first SSO connection, without rebuilding your login flow or wiring up federation from scratch.

What Scalekit adds (Without replacing AWS Cognito)

Scalekit integrates with AWS Cognito just for enterprise SSO.

You still use Cognito to manage sessions, tokens, and users—just like before. But instead of configuring a new SAML or OIDC provider for every customer inside Cognito, you point them all to Scalekit.

Here’s what Scalekit adds:

• Setup Scalekit as an OIDC provider in Cognito: You only set up Scalekit as an OIDC provider inside Cognito. Scalekit handles routing to the correct customer connection behind the scenes.
• Per-customer SSO routing: Pass a ^login_hint (usually the user’s email) when you redirect to Cognito. Scalekit uses that to find the right org and identity provider.
• Hosted admin portal: Share a link with your customer’s IT team so they can configure their IdP without back-and-forth on metadata or certificates.
• SSO orchestration layer: Scalekit runs the actual SAML or OIDC flow with the customer’s IdP, validates the response, and redirects the user back to Cognito.
• Token passthrough to Cognito: After SSO, Cognito receives the identity payload from Scalekit, maps it to your user pool, and continues session management as usual.

Before you begin, make sure:

• You’re using a custom login page: Cognito’s hosted UI doesn’t support passing the ^{identity_provider} or ^login_hint required for routing SSO logins to Scalekit.
• You’ll need to build a custom login page to collect the user’s email and construct the ^/authorize URL with the right parameters.
• Scalekit is set up as an OIDC IdP: You’ll only need one OIDC connection in Cognito. Scalekit handles per-org routing internally.
• Attribute mapping is configured: In Cognito, map standard OIDC claims like ^email and ^sub to your user pool fields so users can be created or matched correctly after login.

Setting up Scalekit with AWS Cognito: A step-by-step guide

Here’s how you’ll connect Scalekit to Cognito and go live with your first SSO login—without federation scripts or rewriting your auth flow.

1. Add Scalekit as an OIDC provider

In your Cognito User Pool, add a new OIDC provider using the credentials from your Scalekit dashboard.

This one provider handles every customer while Scalekit takes care of routing based on the login hint.

2. Map user attributes

Map standard OIDC claims like ^sub, ^email, and ^name to your Cognito user pool fields.

This ensures Cognito knows how to create or link users once Scalekit completes the login.

3. Add Cognito’s callback URI to Scalekit

Copy Cognito’s callback URL and add it to your Scalekit Redirect URIs. This lets Scalekit return the user to Cognito after successful SSO.

4. Create an organization in Scalekit

Set up a new org for your customer.

Share the hosted portal link so their IT team can configure their IdP (SAML or OIDC) themselves—no need to exchange metadata manually.

5. Build the login URL

When a user clicks “Sign in with SSO” on your app’s login screen, you redirect them to Cognito’s ^/authorize endpoint. Then, Scalekit uses this to find the right connection and start the SSO handshake.

6. Let Cognito handle the session

After login, Scalekit redirects back to Cognito.

Cognito handles the token exchange, applies the attribute mapping, and starts the session like it always does.

That’s it. You’ve added SSO to your Cognito setup, without federation logic, Lambda triggers, or a new IdP per customer.

What changes (and what doesn’t)

Adding Scalekit doesn’t change how you use AWS Cognito.

Cognito still manages your sessions, tokens, user pools, and everything tied into your AWS stack. Scalekit steps in only to handle the SSO handshake—so you don’t have to build and maintain that part yourself.

Here’s how it breaks down:

What Scalekit handles

• Connecting to your customer’s IdP (SAML or OIDC)
• Handling login redirects and SSO flow orchestration
• Routing login requests to the right org using ^login_hint
• Hosting the admin portal for your customer’s IT team
• Redirecting the user back to Cognito after successful login

What Cognito handles

• Mapping the identity returned from Scalekit to your user pool
• Issuing tokens and managing sessions
• Running refresh flows and token lifecycles
• Acting as your source of truth for authenticated users

What doesn’t change

• Your user model stays in Cognito
• Your session handling stays untouched
• Your existing authentication methods continue to work

Wrapping up

Enterprise SSO always sounds simple until you try to build it yourself.

Cognito gives you a solid foundation for authentication, including enterprise SSO. But without a way for customers to self-serve, you’re still the one setting up every IdP, managing configs, and unblocking IT teams on their timeline.

Scalekit takes that work off your plate. You support SSO at scale without rewriting anything and without losing control. You just hand off the part you don’t want to manage.

That’s enough to close your next enterprise deal, without breaking your flow or piling more work on your team.

Get started with the Cognito + Scalekit integration →

‍