Digital Identity | ThunderID

Announcing ThunderID: an agent-native, quantum-safe open source IAM stack joins Linux Foundation Decentralized Trust

Sagara Gunathunga, ThunderID maintainer |
Announcing ThunderID: an agent-native, quantum-safe open source IAM stack joins Linux Foundation Decentralized Trust

Today, we are excited to announce that ThunderID is joining Linux Foundation Decentralized Trust (LFDT) as an incubating project. ThunderID was founded by WSO2 and has been generally available since August 2026. Under LFDT, it moves to vendor-neutral governance, so the project's technical direction is set in the open and anyone with a stake in it can take part.

What is ThunderID?

ThunderID is an open source Identity and Access Management stack, built from scratch in Go. It handles authentication, authorization, and identity for humans, AI agents, and machines, and it secures applications, APIs, Model Context Protocol (MCP) servers, and wallets. That covers standards-based authentication and authorization (OAuth 2.1, OpenID Connect), identity and credential management, fine-grained authorization and consent, and a flow engine for login, registration, recovery, and step-up authentication, all with a lightweight runtime and GitOps-native configuration. If you want the full picture, we covered it in the ThunderID introduction back in May.

ThunderID is built around four pillars, each one addressing a gap the current generation of open source IAM doesn't cover well:

  • Agent-native identity. AI agents are modeled as a distinct identity type with their own lifecycle, supporting delegated authority, consent-aware access, traceability, and verifiable credentials issued to them directly. Agents interact with ThunderID as themselves, not through credentials borrowed from a service account.
  • Post-quantum-safe by design. The cryptographic foundation is agile. Algorithms, key types, signing methods, and token protection mechanisms are configuration rather than assumptions, so they can evolve toward post-quantum-safe algorithms and hybrid approaches during the transition. Crypto-agility applies across key management, credential issuance, signed assertions, and service-to-service communication.
  • Decentralized identity integration. Decentralized identity has an adoption gap on the consuming side. ThunderID makes it practical for applications to consume, verify, and trust DIDs, verifiable credentials, digital wallets, and trust registries, following the issuer, verifier, and holder model, rather than treating any of it as a later add-on.
  • Lightweight runtime with GitOps support. Headless and API-first, with declarative configuration so IAM definitions are versioned and deployed through the same pipelines as the rest of your platform, on-premises or in the cloud.

Beyond the runtime, ThunderID includes a console UI, RESTful APIs, server-side and client-side SDKs, framework SDKs for React, Next.js, Vue.js, and Nuxt.js, a flow engine, and a visual flow designer. ThunderID also prioritizes integration with existing community projects, so teams can adopt it without leaving the tools they already use.

Core features

Agent-native identity

  • AI agents are a distinct identity type with their own lifecycle, not service accounts with borrowed credentials.
  • Agents carry delegated authority, consent-aware access, and traceability, with a recorded owning user for accountability.
  • Verifiable credentials can be issued directly to agents.
  • IAM operations are exposed over the Model Context Protocol, so agents interact with identity infrastructure programmatically, as themselves.
  • MCP-aware tool and resource scopes let authorization decisions follow the shape of what an agent is actually calling.

Post-quantum-safe by design

  • Algorithms, key types, signing methods, and token protection mechanisms are configuration rather than assumptions.
  • Crypto-agility spans key management, credential issuance, signed assertions, and service-to-service communication.
  • ML-DSA is supported for JWT signing, and X25519MLKEM768 for post-quantum TLS, which is used on both inbound and outbound connections.
  • Argon2id and PBKDF2 are supported as password hashing algorithms, AES-256 as the symmetric encryption algorithm, and bring your own key is also available.
  • Hybrid key exchange on TLS addresses harvest-now-decrypt-later exposure, where the window opens when traffic goes out rather than when quantum hardware arrives.

Decentralized identity integration

  • OpenID4VCI is supported for credential issuance, and OpenID4VP is supported for credential presentation.
  • The full issuer, verifier, and holder interaction patterns are supported, including credential status and revocation checking.
  • Credential presentation is available as an executor inside an authentication or registration flow, so a wallet-based check is a configuration change rather than a separate integration.
  • Credential types, presentation requirements, and trust policies are declarative; ThunderID executes the protocol flows, validates cryptographic proofs, and enforces trust and privacy behind them.
  • Existing OAuth 2.0 and OpenID Connect deployments can enter the decentralized trust ecosystem incrementally, without a migration.

Lightweight runtime with GitOps support

  • Written in Go, shipped as a single binary and container image, with a small footprint and low latency.
  • Headless and API-first, deployable with Helm or on OpenChoreo, on-premises or in the cloud.
  • Backed by SQLite or PostgreSQL, with Redis for transient state and caching.
  • Every resource definable in YAML, built visually in the Console and exported to a runtime.
  • Definitions are locked at startup and cannot be modified through the Console or the API afterwards, so the identity policy running in production is the one that was reviewed and committed.
  • Versioned releases on the 1.0 line, with OpenAPI specifications and a Postman collection for direct API work, client SDKs covering web and mobile stacks, and a CLI covering installation through day-to-day resource management.
  • Skills and plugins for Claude Code and Codex bring identity configuration and debugging into the AI coding tools development teams already run.

Identity model

  • Users, AI agents, and machines are first-class identity types, each with its own attribute schema.
  • An AI agent lives in an organization unit, carries a recorded owning user, and takes its access through groups and roles the same way a person does, while still operating independently for machine-to-machine work.
  • The directory supports custom user type schemas, nested groups, and hierarchical organization units.
  • A hierarchical resource model covers resource servers and scopes, with permission- and role-based access control.
  • Attribute and permission-based consent that users can review.

Standards and protocols

ThunderID is standards first, implemented against the specifications rather than through vendor extensions.

  • OAuth 2.1 and OpenID Connect. A compliant authorization server with OpenID Connect on top, supporting the authorization code, client credentials, refresh token, token exchange, Client-Initiated Backchannel Authentication (CIBA), and JWT bearer grants.
  • Protocol extensions. PKCE, DPoP, PAR, resource indicators, dynamic client registration, token introspection, token revocation, and OIDC discovery.
  • Verifiable credentials. OpenID4VCI for issuance and OpenID4VP for verification, against presentation definitions and trust anchors, covering the full issuer, verifier, and holder model.
  • Externalized authorization. AuthZEN-compatible external authorization engine, answering authorization decisions for other systems.
  • Agent and tool access. MCP-aware tool and resource scopes, with IAM operations exposed over the Model Context Protocol.
  • Authentication methods. Passkeys and WebAuthn, OTP over SMS and email, and federation with any OIDC or OAuth2 provider.
  • Cryptography. NIST-standardized post-quantum primitives alongside classical algorithms, configurable per deployment.

Flows and user journeys

  • Authentication, self-registration, onboarding, and recovery modeled as composable flows, built in a visual editor.
  • Executors include password with Argon2id or PBKDF2, passkeys and WebAuthn, SMS and email OTP, magic links, social login, federation with any OIDC or OAuth2 provider, and credential presentation.
  • Steps can be added without rewriting the flow around them: a credential check during registration replaces a manual review, a passkey requirement sits in front of a high-value action.
  • Connections manage identity providers and notification senders, including SMS and email providers, in one place.
  • ThunderID Gate, the hosted login UI, serves these flows with browser SSO and configurable session timeouts.
  • Themes, layouts, and translations cover customization, with the SDKs available for building the interface directly.

Current adoption

ThunderID reached general availability in September 2026 and is already deployed as a core identity component across production and open source infrastructure.

ThunderID is licensed under Apache-2.0, compatible with the rest of the LFDT ecosystem, and now operates under LFDT governance, adopting the LF Decentralized Trust Code of Conduct. Design discussions happen in public before anything is built, with proposals, decisions, and the reasoning behind them all in the open.

ThunderID’s roadmap is public and openly maintained, and anyone can suggest an improvement or open a proposal for a new feature, which moves to implementation once it reaches consensus in community discussion. The maintainers set the project’s overall direction, onboard new maintainers, and uphold its governance process.

Get involved

The roadmap is shaped by what people hit when they actually run ThunderID, so the most useful thing you can do right now is run it and tell us where it breaks.

One kind of feedback we especially want right now: if you are integrating ThunderID and something is harder than it should be, tell us. First integrations surface friction that nobody on the inside can see anymore.

Contributions are particularly welcome from engineers and researchers working on AI agent identity and delegated authority, post-quantum cryptography in identity protocols, verifiable credential and wallet interoperability, trust registries and trust frameworks, and GitOps-native identity operations.
Back to all blog posts