Keycloak vs AWS IAM Identity Center: Workforce SSO Compared

Last updated: May 2026

Keycloak and AWS IAM Identity Center solve different problems, and most teams use them together rather than picking one. AWS IAM Identity Center is AWS’s managed workforce SSO service, the rebrand of AWS Single Sign-On, and its standout feature is permission sets that grant people access to AWS accounts across AWS Organizations. The service itself is free, but it is AWS-bound. Keycloak is an open-source, self-hostable, general-purpose identity provider. The common pattern is to run Keycloak as your corporate IdP and federate it into IAM Identity Center as an external SAML 2.0 identity source.

This guide clears up what each tool actually is, compares them across the dimensions that matter, and explains the “both, not either” federation pattern that most AWS-heavy teams land on.

What exactly is AWS IAM Identity Center?

AWS IAM Identity Center is the AWS workforce identity and SSO service, renamed from AWS Single Sign-On on July 26, 2022 (source: AWS). It gives your workforce one sign-in to AWS accounts and to business applications. The naming change matters because it is routinely confused with two other AWS services that do completely different jobs.

Here are the three AWS things people mix up:

• IAM (the original): Long-lived users, roles, and policies scoped to a single AWS account. Built for machine and account-level permissions, not human SSO at scale.
• IAM Identity Center: Workforce SSO. It centralizes human access across many AWS accounts and connects to external identity providers.
• Amazon Cognito: A customer-facing identity service (CIAM) for your app’s end users, not your employees.

IAM Identity Center is not Amazon Cognito

This is the most common conflation, so let’s debunk it plainly. Cognito handles customer identity, the people who sign up and log into your product. IAM Identity Center handles workforce identity, the employees and contractors who need access to AWS accounts and internal tools. If you are choosing a sign-in system for your application’s users, you are comparing Cognito (see our Keycloak vs Cognito comparison), not Identity Center. If you are managing employee access to AWS, Identity Center is the relevant service.

Why does this distinction trip people up? Both carry “IAM” or “identity” in the name, and both issue tokens. But their target users and pricing models diverge completely.

There is a second, subtler mix-up worth naming: IAM Identity Center versus plain IAM. Classic IAM was designed for a single AWS account, with long-lived users and access keys. That model strained badly once organizations grew to dozens of accounts, because operators had to recreate users and rotate keys everywhere. IAM Identity Center exists precisely to fix that pain. It sits above many accounts and hands out short-lived, federated access instead of static credentials. Keep these three boxes separate in your head, and the rest of this comparison reads cleanly.

How do Keycloak and IAM Identity Center compare?

Keycloak is an open-source identity provider offering SSO, OIDC, OAuth 2.0, SAML, identity brokering, and LDAP/Active Directory federation, deployable anywhere you choose (source: keycloak.org). IAM Identity Center, by contrast, is a managed AWS service offered at no extra charge (source: AWS). The table below maps where they overlap and where they pull apart.

Dimension	Keycloak	AWS IAM Identity Center
Scope	General-purpose IdP for any app or cloud	Workforce SSO centered on AWS accounts
Hosting	Self-host anywhere, or use a managed provider	Fully managed by AWS
Protocols	OIDC, OAuth 2.0, SAML 2.0	OIDC/OAuth for app access; SAML 2.0 + SCIM for external IdPs
Identity sources	Built-in directory, LDAP/AD, social, brokered IdPs	Built-in directory, AWS Managed AD, or external SAML 2.0 IdP
AWS-account permission sets	Not available natively (you federate into AWS)	Core differentiator
Cost model	No license fee; you pay infrastructure plus operations	No charge for the service; you pay for AWS resources used
Extensibility	Highly extensible via SPIs, themes, custom providers	Limited to AWS-defined configuration surface
Lock-in	Portable across clouds and on-prem	AWS-bound by design

The headline takeaway: Keycloak is portable and broad; IAM Identity Center is narrow, deep, and tied to AWS. Neither replaces the other cleanly.

A few rows deserve a closer look. On identity sources, Keycloak can act as your directory, broker external providers, and federate LDAP or Active Directory in one place. Identity Center can use its own directory, AWS Managed Microsoft AD, or an external SAML 2.0 IdP, but it expects an upstream source rather than aiming to be your one identity hub for every app.

On cost model, the difference is real but easy to misread. Identity Center charges nothing for the service itself; your spend comes from the AWS resources people reach through it. Keycloak has no license fee either, yet someone still pays for compute, databases, upgrades, and on-call coverage. “Free” means different things in each column, so weigh operational effort, not just invoices.

On lock-in, Keycloak’s portability is a strategic hedge. If you move clouds or run hybrid, your IdP moves with you. Identity Center is deliberately AWS-bound, which is a feature when AWS is your home and a constraint when it is not.

What makes permission sets the killer feature?

Permission sets are the reason IAM Identity Center exists, and Keycloak has no native equivalent. A permission set is “a template … that defines a collection of one or more IAM policies,” and assigning one automatically creates IAM Identity Center-controlled IAM roles in each target account (source: AWS). This is the bridge between human identity and AWS account access.

Here is what that buys you in practice. Say you run 40 AWS accounts under AWS Organizations. You define a “ReadOnly-Auditor” permission set once. You assign a group to it across whichever accounts you choose, and Identity Center provisions the matching roles automatically. No manual role creation per account. No copy-pasting trust policies 40 times.

In our experience helping AWS-heavy teams, this is exactly the workflow Keycloak cannot reproduce on its own. Keycloak issues tokens and manages identities beautifully, but it does not own AWS account roles. To grant AWS-account access from Keycloak, you federate Keycloak into AWS rather than expecting Keycloak to manage permission sets directly. That architectural fact drives the next section.

It is worth being precise about what “no native equivalent” means. Keycloak can model roles, groups, and fine-grained authorization inside its own realm. What it cannot do is reach into your AWS accounts and provision IAM roles on your behalf. Those roles are AWS objects governed by AWS Organizations, and only an AWS-aware service can create them automatically. This is not a Keycloak shortcoming; it reflects where each tool’s authority ends. Keycloak’s authority stops at identity and tokens. Identity Center’s authority extends into the AWS account boundary, which is exactly why the two pair so well.

Why do teams run both together?

Most AWS-heavy organizations don’t choose between these tools, they layer them. IAM Identity Center supports external identity providers through SAML 2.0 and SCIM (source: AWS), which means you can keep Keycloak as your corporate IdP and plug it into Identity Center as the upstream identity source. AWS’s own engineering blogs document Keycloak federated into AWS for services like Amazon QuickSight and Amazon WorkSpaces.

The architecture looks like this:

• Keycloak is the single source of truth for employee identities, MFA, password policy, social or brokered logins, and LDAP/AD federation.
• Keycloak acts as a SAML 2.0 IdP to IAM Identity Center, which trusts it as the external identity source.
• IAM Identity Center maps those federated users and groups to permission sets, granting AWS account access.

The payoff is clean separation of duties. Your identity policy lives in Keycloak, where you control it fully. Your AWS account access logic lives in Identity Center, where AWS automates the role plumbing. If you already broker other providers into Keycloak, the pattern extends naturally. See our guides on configuring Keycloak as a SAML service provider and the broader SSO implementation guide for developers.

The provisioning caveat you must plan for

SAML alone is not enough, and this catches teams off guard. SAML authenticates users at login but cannot let Identity Center query your IdP for the full list of users and groups ahead of time. Identity Center needs those entities provisioned, typically over SCIM. That requirement is where Keycloak’s setup needs care.

Keycloak does not ship SCIM in its core out of the box, so you provision users and groups into Identity Center through an extension or manually. Because this area evolves between releases, check your current Keycloak release notes rather than assuming a fixed answer. Plan the provisioning path early; do not discover it after the SAML trust is already wired up.

In practice, teams choose one of two approaches. Some adopt a community or third-party SCIM extension for Keycloak so group membership syncs into Identity Center automatically. Others provision the needed users and groups manually or through scripts when the workforce is small and changes slowly. Neither is wrong. The manual route trades automation for simplicity; the extension route trades setup effort for hands-off syncing. Decide based on how often your directory churns. Either way, treat provisioning as a first-class part of the design, not an afterthought bolted on once login already works.

When does each tool win?

Each tool wins in a clearly bounded scenario, and the boundary is whether AWS account access is your central problem. IAM Identity Center is free as a service (source: AWS), while Keycloak carries no license cost but does require infrastructure and operational effort. Match the tool to the job rather than forcing one to cover both.

IAM Identity Center wins when

• AWS account access for humans is your primary challenge, especially across many accounts in AWS Organizations.
• You want permission sets to automate IAM role creation rather than hand-managing roles per account.
• You prefer a fully managed service and accept AWS lock-in as a reasonable trade.
• Your workforce identities already live in an external IdP you can federate in.

Keycloak wins when

• You need a general-purpose IdP for apps and services beyond AWS, including multi-cloud and on-prem.
• You require deep customization: custom auth flows, themes, SPIs, or brokered providers.
• LDAP/Active Directory federation and full control over identity policy matter to you.
• Portability and avoiding vendor lock-in are priorities. For an enterprise-scale view, compare with our Keycloak vs Okta comparison.

The honest answer for most AWS-heavy teams is “both.” Keycloak owns identity; Identity Center owns AWS account access; SAML and SCIM connect them.

Frequently asked questions

Is AWS IAM Identity Center the same as AWS SSO?

Yes. AWS IAM Identity Center is the renamed version of AWS Single Sign-On, with the change taking effect July 26, 2022 (source: AWS). The functionality carried over; only the name changed. If you find older documentation referencing “AWS SSO,” it describes the same service. AWS recommends using the current name in new work.

Can Keycloak replace AWS IAM Identity Center?

Not directly, because Keycloak has no native concept of AWS-account permission sets, the feature that auto-creates IAM roles across accounts (source: AWS). Keycloak excels as the upstream identity provider, but AWS account access still flows through Identity Center. You federate Keycloak into AWS rather than replacing the AWS layer entirely with Keycloak.

How do I connect Keycloak to IAM Identity Center?

You configure Keycloak as an external SAML 2.0 identity source, which Identity Center supports alongside SCIM provisioning (source: AWS). Set up the SAML trust between Keycloak and Identity Center, then handle user and group provisioning. Our walkthrough on setting up an external IdP in Keycloak via SAML covers the federation mechanics that apply here.

Does using IAM Identity Center cost extra?

No. IAM Identity Center is offered at no extra charge as a service; you only pay for other AWS resources you use through it (source: AWS). Keycloak likewise has no license fee, but you carry the cost of running and maintaining the infrastructure yourself, or the cost of a managed hosting provider that handles it for you.

Is IAM Identity Center the same as Amazon Cognito?

No, and conflating them is a common mistake. Cognito is a customer identity (CIAM) service for your application’s end users. IAM Identity Center is a workforce SSO service for employees accessing AWS accounts and internal apps. They target different audiences and use different pricing models, so pick based on whose identities you are managing.

The bottom line

Stop framing this as Keycloak versus IAM Identity Center. They occupy different layers. IAM Identity Center is AWS’s free, managed workforce SSO service whose permission sets uniquely automate AWS account access across AWS Organizations. Keycloak is the open-source, portable IdP that owns your identity policy and federates outward to anything, including AWS.

The pattern that works for most AWS-heavy teams is to run Keycloak as the corporate IdP and federate it into IAM Identity Center over SAML 2.0, with SCIM handling provisioning. Plan that provisioning path early, since Keycloak does not ship SCIM in core, and verify the details against your current release.

If you want Keycloak running reliably as your corporate IdP without owning the operational burden, explore Skycloak’s managed Keycloak hosting or review the pricing options.