2026-05-10

WSO2 Identity Server: open-source IAM

WSO2 Identity Server is the open-source IAM platform from the same WSO2 stable that produces API Manager (covered in the WSO2 API Gateway post) and Micro Integrator. It’s the IdP underneath their API gateway’s Key Manager and a standalone product in its own right. Apache 2.0, on-prem-first, with a SaaS sibling (Asgardeo) for organizations that want managed.

This post is what WSO2 IS actually does, how it sits architecturally, and where it competes with Keycloak (the obvious open-source comparator), Okta, and Ping Identity.

The position

WSO2 IS is a full-featured open-source IAM platform. Three properties:

1. Open source, Apache 2.0. No locked features behind enterprise editions. WSO2 sells support; the software is yours.
2. Multi-protocol native. OAuth 2.0, OIDC, SAML 2.0, WS-Federation, SCIM 2.0, OpenID Connect FAPI for finance. The protocols aren’t tacked on; they’re first-class.
3. Federation as a first principle. WSO2 IS isn’t just a user store — it’s an identity broker. Users sign in via Google, Microsoft Entra, your existing enterprise IdP, a customer’s IdP, social providers, all funneled through one consistent OAuth/OIDC interface to your applications.

The closest open-source comparator is Keycloak. The closest commercial comparators are Okta, Auth0, Ping Identity, and Microsoft Entra ID (formerly Azure AD).

Architecture

Reading the diagram:

• Client application — your web app, API, mobile app, native app. Talks to WSO2 IS over OAuth / OIDC / SAML for authentication.
• User / browser — the end user, redirected to IS for login.
• WSO2 Identity Server — the IdP. Handles AuthN (login), AuthZ (token issuance, scope, claims), federation, MFA, session management.
• Social IdPs, enterprise IdPs (SAML / OIDC), AD/LDAP, JDBC user stores — the sources of identity. IS federates outbound to any of these. A single user can be authenticated via multiple providers via WSO2’s identity federation.
• MFA — TOTP, SMS OTP, FIDO2 / WebAuthn, biometric (via mobile SDKs), email OTP. Configurable per application or per user-segment with adaptive rules.
• SCIM 2.0 — provisioning. Other systems push users into IS or pull provisioning events from IS. Standard inbound and outbound flow.

The green dashed edges are out-of-band: federation, MFA validation, provisioning. The solid edges are the front-channel user authentication flow. Federation lets a single application accept logins from many identity sources without each application needing to integrate each source directly.

What’s actually in the box

The capabilities:

The protocols are the table stakes; the differentiator is the federation model and the adaptive authentication scripting.

Adaptive authentication scripting

The feature WSO2 IS leans on hardest in marketing — and the one that genuinely differentiates it from simpler IdPs.

You can attach JavaScript code to the login flow. The script has access to the user, the application, the device, the IP, the time. It decides which authentication steps to require:

var onLoginRequest = function(context) {
  executeStep(1); // username + password
  var user = context.steps[1].subject;
  if (user.localClaims['http://wso2.org/claims/role'].indexOf('admin') >= 0) {
    executeStep(2, { authenticator: 'fido' }); // require FIDO2 for admins
  } else if (isUnusualLocation(user, context)) {
    executeStep(2, { authenticator: 'totp' }); // step-up TOTP for new locations
  }
};

This composes step-up auth, geo-aware MFA, role-based requirements, and risk scoring into the login flow without requiring a separate fraud product. Auth0 and Okta have equivalent features (Actions / Workflows) but WSO2 IS makes it a first-class part of the open-source offering.

Asgardeo: the SaaS variant

Asgardeo is WSO2’s hosted IAM SaaS. Conceptually it’s WSO2 IS as a service, with a more modern UX, simpler onboarding, and B2B-first ergonomics. Pricing per-MAU (monthly active user), with free tier.

When to use which:

• Asgardeo if you don’t want to operate the platform and you don’t have on-prem-only requirements
• WSO2 IS if you need on-prem, multi-cloud, BYOC, or specific compliance certifications

Asgardeo and WSO2 IS share the underlying engine; APIs are largely compatible. Migration paths exist but aren’t fully bidirectional.

Comparison: WSO2 IS vs the competition

WSO2 IS’s natural lane: on-prem and BYOC deployments where the customer needs full-feature IAM (SAML + OAuth + adaptive + B2B), wants open source, and is comfortable operating a Java application stack. Regulated industries (finance, healthcare, government), Asia-Pacific market, and existing WSO2 customers form most of the user base.

Limitations and pitfalls

• Java application footprint. WSO2 IS is a Carbon-framework-based Java app. HA requires multiple nodes + a database. Less cloud-native feeling than Keycloak Quarkus distribution or pure-SaaS alternatives.
• The admin UI has improved but is still a learning curve. Older Console (Carbon-era) vs newer Console — make sure tutorials match what’s in your version.
• Documentation versions. Like API Manager, the 5.x vs 6.x vs 7.x version differences are significant. Match docs to your installed version.
• Federated IdP setup is metadata-heavy. SAML federation in particular requires importing SP/IdP metadata, mapping attributes, configuring signature/encryption certificates. Real work even for “standard” integrations.
• B2B Organizations model is newer. It’s good but evolving — earlier major versions handled multi-tenancy via separate “tenants” with their own admin domains. New patterns use Organizations. Pick one model and commit.
• Marketing pivots to Asgardeo. On-prem WSO2 IS is supported but Asgardeo gets more roadmap energy. Plan accordingly.

Where to start

1. Run WSO2 IS via Docker for evaluation — single container, default H2 database (don’t use for production).
2. Walk the first-app integration: configure a service provider, integrate a sample OIDC app, validate login.
3. Add a federated IdP (Google or your enterprise IdP) and validate federation works.
4. Configure adaptive authentication for one rule (e.g., require MFA for users with admin role) using the script editor.
5. Move to a production-ready deployment: Postgres database, multiple nodes, load balancer, certificates, exported logs.
6. Decide between Asgardeo and on-prem before committing engineering effort. The two share concepts but operational profiles differ.

The mistake to avoid: under-investing in user-store strategy on day one. WSO2 IS supports multiple user stores (LDAP, AD, JDBC, custom) but the primary store choice locks in how users sync, how federation works, and how SCIM provisioning behaves. Decide early and stick with it.