At some point, every team on AWS hits the same problem. You have multiple accounts, maybe multiple products, users who need access to several things at once — and your current login setup is starting to crack under the weight.
You search around. You find Okta, Auth0, native AWS IAM Identity Center, and Keycloak SSO on AWS. And then you spend an afternoon trying to figure out which one actually fits your situation.
This article makes that easier. We'll walk through all three options honestly — what each covers, where it falls short — and explain why teams that need flexibility, data ownership, or a growing user base keep landing on Keycloak.
What Problem Are You Actually Solving?
Before looking at tools, it helps to be specific about what you need. SSO on AWS usually comes down to one of these situations:
You manage multiple AWS accounts and users need access to several of them — and you're tired of maintaining separate IAM credentials per account
You have multiple applications (customer portals, internal tools, third-party SaaS) that should share one login
You have external users — customers, partners, contractors — who need managed, secure access to parts of your system
You operate under compliance requirements that demand audit logs, strict access control, or data residency within your own infrastructure
Which of these describes your situation shapes which option makes sense. Keep it in mind as you read.
Option 1: Native AWS IAM Identity Center
AWS IAM Identity Center is AWS's built-in access management service. You manage users in its own directory (or connect an external provider), assign permission sets, and control access to all your AWS accounts from one admin panel. It's included in AWS, straightforward to set up, and handles basic multi-account access well.
For a small, AWS-only team that doesn't need custom authentication flows or external user management, it gets the job done quickly.
Where it works
Small engineering teams managing a handful of AWS accounts with no external applications
Organizations getting started with centralized access who aren't ready to commit to an external identity platform yet
Teams that will add Keycloak as the identity provider later — IAM Identity Center works well as the access layer in that architecture
Where it hits limits
IAM Identity Center is built for internal AWS access management — not for customer-facing logins, multi-brand experiences, or complex authentication logic. The moment you need branded login pages, custom MFA flows, or federation from multiple identity sources, you'll be reaching for something else.
Many teams use IAM Identity Center as the access layer and add Keycloak as the identity provider in front of it. That combination is actually a common and well-suited architecture for growing companies.
Option 2: Okta or Auth0
Okta is the most widely used commercial identity provider in the enterprise space. It integrates with AWS IAM Identity Center via SAML, comes with a polished admin UI, and has solid documentation. Auth0 (now part of Okta) targets developer teams with a more code-first approach and a free tier up to 7,500 monthly active users.
If your company already pays for Okta across other tools, adding AWS is genuinely low-friction. That's a real argument for it.
Where it works
Your company already pays for Okta — adding AWS is one more connection, not a new budget line
You need enterprise features like SCIM automated provisioning, advanced threat detection, or detailed compliance reporting
Your IT team prefers a fully managed SaaS with vendor support rather than operating any infrastructure
The honest downside
The pricing model is per user per month. Okta SSO starts at around $2 per user, reaching $5–8 with MFA and lifecycle management. Auth0 moves to usage-based pricing after the free tier. For a core internal team, that's manageable. For teams with external users — customers, contractors, partners — it scales in the wrong direction. You end up paying a growing monthly fee for people accessing your product, not just your team.
There's also a ceiling on customization. Branded login pages per product, custom MFA flows, multi-brand identity setups, self-hosted data — these either aren't available or require expensive enterprise plans.
Option 3: Keycloak SSO on AWS
Keycloak is an open-source identity and access management platform developed by Red Hat, first released in 2014 and now used by over 6,400 companies worldwide. It handles SSO login, user federation, custom authentication flows, and multi-application access — and integrates with AWS IAM Identity Center as an external identity provider via SAML or OpenID Connect.
This is where the comparison shifts. Keycloak isn't just a cheaper alternative to Okta. It's a different category of tool — one that gives you full control over the identity layer of your product, including how it's built, where it runs, and how it behaves for every type of user.
How Keycloak SSO works on AWS
The core building block in Keycloak is a realm — an isolated security domain with its own users, roles, clients, and authentication flows. Each application or product connects to Keycloak as a client within a realm. Keycloak then acts as the identity provider, authenticating users and issuing tokens that your applications and AWS IAM Identity Center trust.
On AWS, Keycloak typically runs on ECS Fargate (simpler to operate, good for most teams) or EKS (better for high-availability, large-scale setups), with RDS PostgreSQL as the database. Public authentication endpoints are exposed through an Application Load Balancer; admin access stays isolated inside a private VPC subnet. This separation is a core part of secure deployment — following AWS VPC security best practices keeps your identity infrastructure protected even if other layers are compromised.
The identity federation flow works like this: a user tries to access an application or AWS account, gets redirected to Keycloak for authentication, Keycloak validates their identity (via its own user store, Active Directory, Google, or another upstream provider), and returns a signed SAML assertion or OIDC token to AWS IAM Identity Center. IAM Identity Center then grants access based on the permission sets mapped to that user's Keycloak groups.
What Keycloak SSO on AWS gives you
No per-user fees. You pay for the AWS infrastructure to run Keycloak — typically $100–500/month depending on scale. Whether you have 50 users or 50,000, the cost model doesn't change. This is the decisive factor for teams with large or growing external user bases.
Full customization of authentication flows. Branded login and registration pages per product or sub-brand. Email-based MFA with device recognition and trusted sessions. Conditional authentication based on user role, context, or risk level. You configure the logic — Keycloak runs it.
Support for multiple protocols simultaneously. Keycloak speaks OAuth 2.0, OpenID Connect, and SAML 2.0 at the same time. Legacy applications on SAML, modern microservices on OIDC — one Keycloak instance handles both, without separate identity providers for each protocol.
Identity brokering across multiple sources. Google Workspace for internal staff, Active Directory for enterprise users, a separate directory for customers — Keycloak federates all of them into a single identity layer that AWS trusts downstream. This is called identity brokering, and it's one of Keycloak's strongest capabilities for teams with mixed user types.
Full data ownership. Keycloak runs inside your AWS VPC. All identity data — users, credentials, sessions — stays inside your own perimeter. For regulated industries, this isn't just a preference, it's a compliance requirement.
"💡 Pro tip: Map roles to Keycloak groups, not individual users. When someone changes teams or leaves, you update one group and all their AWS permissions update automatically. Managing it at the user level becomes a maintenance problem within a few months."
The honest trade-off
Out of the box, Keycloak covers about 60–70% of what a production SSO system needs. The remaining 30–40% — branded login pages, custom admin tooling, complex MFA flows, multi-brand setups — requires configuration and development work. This is where teams either invest the time internally or bring in a specialist who has done it before.
It's not difficult infrastructure to run. But it does require someone to own it. Teams already stretched on DevOps capacity should factor that in when comparing the true cost of each option.
How the Options Compare
Here's a side-by-side view of the three approaches across the criteria that matter most for teams evaluating SSO on AWS:
A useful reference: Perfsys implemented Keycloak SSO on AWS for a large energy distribution company in Western Europe operating a customer platform across multiple sub-brands. Each sub-brand had its own login experience; all of them ran on shared backend infrastructure.
The client's challenges were typical for this stage of growth: no central system for customer logins, different access requirements for customers versus internal admins, and strict security requirements around energy and billing data. A managed SaaS wasn't viable — data ownership was a compliance requirement, and per-user pricing didn't work for their customer base size.
After the Keycloak SSO implementation on AWS:
4 sub-brands were unified under one login system, each with its own branded login experience
Login-related support requests dropped 30–40%, driven by more reliable authentication and better admin tooling
Onboarding new products became 2–3× faster, reusing the centralized identity architecture instead of rebuilding it per product
That last number is the one that surprises teams most. Identity is usually treated as a security problem. It's also a product velocity problem — every new application that needs its own login setup from scratch slows your launches. A well-built Keycloak SSO layer on AWS pays for itself in time saved on the second product, and every one after.
Three questions that usually make the decision clear:
Do you have external users — customers, contractors, or partners — who need managed access?
If yes, per-user pricing will become a real cost as you grow. Keycloak's flat infrastructure cost model handles external users without penalty.
Do you run (or plan to run) more than one product or brand?
Keycloak SSO is built for multi-application and multi-brand setups. Reusing one identity layer across products is one of the strongest arguments for it.
Does your industry require keeping identity data inside your own environment?
Energy, healthcare, finance, and other regulated sectors often do. Keycloak self-hosted on AWS is the practical answer.
If you answered yes to any of these, Keycloak SSO on AWS is worth a serious look.
How Perfsys Helps
The gap most teams face with Keycloak isn't the concept — it's the 30–40% of production work that goes beyond a default install: custom auth flows, branded login pages, multi-brand setups, admin tooling, secure AWS architecture.
The Perfsys Keycloak SSO solution covers the full implementation: Keycloak deployment on AWS, custom authentication flows, MFA, branded login pages per product, and documented runbooks for your team to operate it day-to-day. No per-user fees.
Ready to implement Keycloak SSO on AWS?
Get a full implementation — Keycloak deployment, custom auth flows, MFA, branded login pages, and runbooks for your team.
CEO & Founder | Serverless architect with 10+ years of hands-on experience designing cloud-native architectures on AWS, backed by multiple AWS certifications. He is writing bridges deep technical expertise with real-world business strategy, covering topics from AWS best practices to scaling tech-driven organizations.
Need to move fast? Our cloud team is ready to scale, secure, and optimize your systems. Get serverless expertise, 24/7 support, and seamless CI/CD pipelines when you need it most.
By clicking "Accept", you agree to the storing of cookies on your device to enhance
site navigation, analyze site usage, and assist in our marketing efforts. View our
Privacy Policy for more information.