Introduction
Identity management sounds simple on the surface. A user logs in, the system checks who they are and access is granted. But underneath that simple idea sits a huge amount of complexity with passwords, tokens, multi factor checks, user directories, compliance rules and now, AI agents that also need to prove who they are.
WSO2 has built three different products to solve this problem. WSO2 Identity Server, Identity Platform and WSO2 ThunderID. At first glance this can look confusing. Why does one company need three identity products? The short answer is that each one was built for a different situation, a different type of team and in ThunderID’s case, a different era of technology altogether.
This article walks through what each product is, how it is built, what it is good at and why all three continue to exist side by side.
The Three Products at a Glance
1. WSO2 Identity Server: The Original, Full Control Option
What it is
WSO2 Identity Server is the oldest and most complete of the three. It has been developed for over a decade and is used by large organizations such as banks, telecoms and government bodies. It is open source, which means the code is publicly available, but serious deployments use the commercial support version.
How it is built
WSO2 IS is written in Java and runs on something called the “Carbon” platform, which is WSO2’s own internal framework used across many of their products. Think of it as one large application that you install on your own servers (or your own cloud account) and it stays running there permanently, like a piece of infrastructure you own.
A simple picture of how it fits into a company’s systems is as below.
Strengths
Full control. Nothing leaves your own infrastructure, which matters a lot for banks, hospitals and governments.
Very deep customization. You can change almost anything about how it behaves.
Strong support for federation, meaning it can connect to many other identity systems (social logins, corporate directories, government ID systems and so on).
Built in tools for governance and consent, which are important for privacy laws.
Trade offs
Someone has to install it, patch it and keep it running. This takes real engineering time.
Because it does so much, it can feel heavy and slower to set up for smaller projects.
The interface, while improved recently, still feels built for enterprise IT teams rather than individual developers moving fast.
Who it fits
Large organizations with strict compliance needs, dedicated infrastructure teams and a requirement that user data never leaves their own systems.
2. WSO2 Identity Platform: The Same Power, Delivered as a Cloud Service
What it is
Formerly known as Asgardeo, WSO2 Identity Platform is built using the same core identity engine as WSO2 Identity Server. In other words, it is not a different product from scratch. It is the same proven technology, but instead of installing it yourself, WSO2 runs it for you in the cloud and you simply connect to it.
This is the same idea as the difference between running your own email server versus using Gmail. The underlying concepts are similar, but one requires you to manage servers and the other does not.
Identity Platform can also be deployed as a “single tenant private cloud” for companies that want cloud convenience but with their own isolated environment. That is a middle ground between full self-hosting and shared cloud.
Strengths
No servers to install or patch. You sign up and start building right away.
Newer AI powered features, such as describing a login flow in plain English and having the system build it automatically and automatic branding of login screens.
Predictable, cloud style pricing compared to some competitors.
Trade offs
Your identity data lives on WSO2’s cloud infrastructure rather than your own, which may not suit organizations with strict data residency rules.
Less low level control than the self hosted Identity Server since you are working within a managed service.
Who it fits
Startups, product teams and companies that want enterprise grade identity features without hiring a team to maintain servers. It is WSO2’s direct answer to services like Auth0.
3. WSO2 ThunderID: Built for a New Kind of User, the AI Agent
What it is
ThunderID is the newest of the three and it is built completely differently under the hood. Where Identity Server and Identity Platform share a large Java based core, ThunderID is written in Go, a programming language known for being fast, lightweight and easy to package into small containers.
ThunderID was created because the identity world is changing. It is no longer just humans logging in. Now, software “agents” (AI systems that act on behalf of a person or a company) also need an identity, need permissions, and need to be tracked and trusted. Traditional identity systems were never designed with that in mind.
How it is built
Strengths
Very lightweight and fast to start, which fits naturally into modern container-based systems (the kind of setup used by cloud native teams today).
Treats AI agents as “first class citizens,” meaning an agent can have its own identity, its own limited permissions and a clear record of what it did and on whose behalf.
Supports newer identity ideas like digital wallets and verifiable credentials (a modern, more private way of proving facts about yourself, similar to a digital ID card).
Built with future proof encryption in mind, so it stays secure even as computing power increases.
Designed to be simple to run anywhere, whether on a laptop for testing or across a large cloud deployment.
Trade offs
It is still new and under active development, so it does not yet have the years of enterprise track record that Identity Server has.
Some advanced enterprise features found in Identity Server may take time to appear in ThunderID.
Who it fits
Teams building modern, cloud native applications and especially teams working with AI agents that need to securely access data, tools or other systems on behalf of a user or company.
How the OAuth2 / OIDC Login Flow Actually Works
All three products (Identity Server, Identity Platform and ThunderID) are built on the same two industry standards, OAuth2 and OIDC. These are not WSO2 inventions. They are open standards used by almost every login system in the world, including Google, Microsoft and Facebook logins. Understanding this flow helps explain what all three products are actually doing underneath.
Here is the simple version of what these two words mean.
OAuth2 answers the question “what is this app allowed to do.” It is about permission.
OIDC (OpenID Connect) is built on top of OAuth2 and answers the question “who is this person.” It is about identity.
Think of OAuth2 as a hotel key card system and OIDC as the ID check at the front desk. The front desk checks who you are (OIDC), then hands you a key card that only opens certain doors (OAuth2).
Think of OAuth2 as a hotel key card system, and OIDC as the ID check at the front desk. The front desk checks who you are (OIDC), then hands you a key card that only opens certain doors (OAuth2).
The flow, step by step
Imagine you are logging into a shopping app using your WSO2 Identity Platform account.
Why the code and not just a direct password check
You may notice the shopping app never actually sees your password. It only receives a short lived code, then trades that code for tokens. This is one of the most important ideas in modern identity systems. The app you are using should never touch your raw password. Only the identity system (WSO2 IS, WSO2 Identity Platform or ThunderID) ever sees it. This is exactly what all three products are built to manage safely.
What the two tokens actually mean
ID Token: A small, signed piece of information that proves who you are. It usually contains your name, email, and a unique ID.
Access Token: A separate piece of information that the shopping app can use to make requests on your behalf, such as “get this user’s order history.” It does not prove identity by itself. It proves permission.
This separation is the same across WSO2 Identity Server, Identity Platform, and ThunderID, because all three follow the same open standard. The real difference between them is not the flow itself, but where it runs (your own servers, WSO2’s cloud, or a lightweight container) and who or what is allowed to go through that flow (a human only, or also an AI agent, a service, or a decentralized digital wallet).
How WSO2 ThunderID Handles AI Agent Permissions
This is the part of ThunderID that is genuinely new compared to older identity systems. Traditional identity systems like WSO2 IS were designed with one assumption: the thing logging in is a human being sitting at a keyboard. ThunderID was designed knowing that is no longer always true. Sometimes the thing logging in is an AI agent acting on a person’s behalf, with no human directly present at that moment.
ThunderID handles this through a few connected ideas.
1. Agents get their own identity, not a borrowed one
Instead of an AI agent secretly using a human’s saved password or personal login token, ThunderID gives the agent its own separate identity record. This means the system always knows, clearly, whether an action was taken by a human or by an agent acting for that human.
2. Delegated authority, not full impersonation
This is one of the most important ideas in the whole system. There are two very different ways to let an agent act for you.
Impersonation: the agent completely becomes you. The system can no longer tell the difference between you and the agent. This is risky, because if something goes wrong, it is hard to know who actually did it.
Delegation: the agent keeps its own separate identity, but is granted specific, limited permission to act on your behalf. The system always keeps a clear record of “Agent X did this action, on behalf of User Y.”
ThunderID is built around delegation rather than impersonation. This matters a lot for safety and trust, because it means an AI agent can be given exactly the permissions it needs and nothing more.
3. Consent aware access
Before an agent is allowed to act, the system is designed to check that the human has actually agreed to it. This is similar to how a mobile app asks “allow this app to access your camera, yes or no.” ThunderID applies that same idea to AI agents. A human can grant an agent permission for a specific task, such as “you may check my calendar,” without giving it permission for everything else, such as “you may also read my private messages.”
4. Traceability, meaning every action leaves a trail
Every time an agent does something, ThunderID is designed to record that action, including which agent did it, under which permission and on whose behalf. This creates an audit trail. If something unexpected happens, it is possible to look back and see exactly what the agent was allowed to do and what it actually did.
5. Verifiable credentials for agents
ThunderID can also issue what are called verifiable credentials to agents. A simple way to think about a verifiable credential is a digital, tamper proof certificate. Instead of just trusting an agent because it says who it is, the agent can present a signed credential that proves a fact about itself, for example, “this agent was created by Company X and is approved to access Service Y.” Other systems can check that this credential is real without having to call back and ask the original issuer every time.
ThunderID supports the emerging standards for this, often referred to as OpenID4VCI (issuing credentials to a digital wallet) and OpenID4VP (presenting and verifying those credentials later). In plain terms:
Putting it together
The overall idea behind ThunderID’s agent permission model is simple, even though the technology behind it is new. Give every agent its own identity, give it only the permissions it actually needs, keep a clear record of what it does and make sure it can prove who it is without needing a human to vouch for it every single time. This is very different from older systems, where the safest option was often just to give an application full access using someone’s personal login, which is exactly the kind of risk that becomes dangerous once agents start acting on their own.
Why All Three Exist Together
It can help to think of these three products less as competitors and more as three answers to three different questions:
“I need full control and my data can never leave my own servers.” → WSO2 Identity Server
“I want enterprise grade identity but I do not want to manage servers.” → WSO2 Identity Platform
“I am building modern, container-based software and some of my users are actually AI agents.” → WSO2 ThunderID
They are not fighting for the same job. They are built for different environments and different moments in a company’s growth. In fact, they often work together. For example, a company might use Identity Platform for its customer login, while using ThunderID as the identity layer inside an internal platform that manages AI agents and still keep Identity Server running for a legacy system that cannot be moved to the cloud.
Side by Side Comparison
Conclusion
WSO2 Identity Server, Identity Platform and ThunderID are not three versions of the same idea. They represent three different philosophies about how identity should be delivered. Fully owned and controlled, conveniently delivered as a cloud service, or lightweight and built for the new world of AI agents and cloud native software.
Identity Server exists because some organizations must keep everything in house. Identity Platform exists because most teams would rather focus on their product than manage servers. ThunderID exists because the definition of a “user” is expanding beyond just people and older systems were not designed for that shift.
Understanding why all three exist is really about understanding how much identity management itself has changed, from a login box on a website, to a full system that now has to think about humans, machines and AI agents all at once.
Top comments (0)