ThunderID 1.0 Is Here

ThunderID 1.0 is generally available today. This is our first GA release. We built ThunderID from scratch, in Go, because open source IAM was designed for a world where humans were the only intelligent actors, quantum computing was a research topic, and decentralized identity was still a spec draft. That world is gone. ThunderID handles authentication, authorization, and identity for humans, AI agents, and machines, and it secures applications, APIs, Model Context Protocol (MCP) servers, and wallets.

What ThunderID is​

ThunderID is built around four pillars, each addressing a gap in identity infrastructure:

• Agent-native Identity: AI agents are first-class identities. They get delegated authority, consent-aware access, traceability, and verifiable credentials issued to them directly. ThunderID also aims to expose IAM capabilities through interfaces that agents can use safely and programmatically.

• Post-quantum-safe by Design: The cryptographic foundation is agile. Algorithms, key types, signing methods, and token protection mechanisms can evolve over time, including post-quantum-safe algorithms and hybrid approaches for the transition. This runs across key management, credential issuance, assertions, and service-to-service communication.

• Decentralized Identity: 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-holder model.

• Lightweight Runtime with GitOps Support: A lightweight, containerized runtime that runs on-premises or in the cloud. Flows, policies, and configuration are all declarative, so they can be versioned, reviewed, and automated.

What's in 1.0​

Identity for humans, AI agents, and machines​

Users, AI agents, and machines are first-class identity types. Each has its own attribute schema. Agents get the parts of both users and machines that they need. An agent lives in an organization unit, carries a recorded owning user for accountability, and takes its access through groups and roles, the same way a person does. It also works on its own for machine-to-machine work. The directory itself covers custom user type schemas, nested groups, and hierarchical organization units.

Protocols and standards​

ThunderID is an OAuth 2.1-compliant authorization server with OpenID Connect on top. It supports the authorization code, client credentials, refresh token, token exchange, Client-Initiated Backchannel Authentication (CIBA), and JWT bearer grants, along with PKCE, DPoP, PAR, resource indicators, Dynamic Client Registration, token introspection, revocation, and OIDC discovery.

Verifiable credentials are supported too: ThunderID issues with OpenID4VCI and verifies with OpenID4VP against presentation definitions and trust anchors, covering the full issuer, verifier, and holder model.

On the authorization side, ThunderID supports a hierarchical resource model covering resource servers, MCP-aware tool and resource scopes, and permission- and role-based access control. It can also act as an AuthZEN-compatible external authorization engine, answering authorization requests from other systems.

Post-quantum readiness​

Algorithms, key types, and signing methods are all configurations. Argon2id and PBKDF2 for password hashing. AES-256 for symmetric encryption. ML-DSA for JWT signing. X25519MLKEM768 for post-quantum TLS on both inbound and outbound connections. Bring your own key is supported.

Hybrid key exchange on TLS is the piece worth acting on now. Traffic captured today can be stored and decrypted later, so the exposure window for anything long-lived opens when the traffic goes out, not when the quantum hardware arrives.

Flows and user journeys​

Authentication is rarely one step, and the steps differ by user, by risk, and by application. ThunderID models this as flows: a visual editor, 29 built-in executors (the reusable steps a flow is composed from), and journeys for authentication, self-registration, onboarding, and recovery.

Executors are the units of composition. Username and password with PBKDF2 or Argon2id. Passkeys and WebAuthn. SMS and email OTP. Magic links. Social login with Google and GitHub. Federation with any OIDC or OAuth2 provider. Credential presentation, which turns a verifiable credential check into a step inside an existing flow rather than a separate integration.

Composability is the useful part. A credential check during registration replaces a manual review. A passkey requirement sits in front of a high-value action. Steps can be added without rewriting the flow around them.

Connections manage identity providers and notification senders together, including SMS senders like Twilio and Vonage and email senders, so everything a journey depends on is configured in one place.

ThunderID Gate, the hosted login UI, serves these flows with browser SSO and configurable session timeouts. It is ready to use as it ships and can be customized.

Look and feel​

The login page is often the only part of identity infrastructure a customer sees. It should look like the solution it belongs to.

How far that goes is a choice. Themes cover colors, typography, and logos. Layouts change the structure of the page itself, not just its styling. Translations handle language. Beyond any of that, the SDKs support building the interface directly, with flows still driving what happens at each step.

GitOps support​

Every resource in ThunderID can be defined in YAML. Everything can be built visually in the ThunderID Console, then exported as YAML and attached to a ThunderID runtime. When a runtime starts from those definitions, they are locked at startup, and nothing changes them at runtime through the Console or the API.

The authentication policy running in production is exactly the one that was reviewed and committed, and it stays that way. Changing a flow means changing the file, which means going through whatever review your repository already enforces.

Developer experience​

IAM has a steep learning curve. Getting a login flow right means understanding authorization code flow, PKCE, redirect URI validation, token storage, refresh handling, and session management. Most teams integrating IAM have no interest in becoming experts in any of it. They want working auth.

So 1.0 ships with 14 client SDKs covering web and mobile stacks, and the SDKs handle protocol correctness on the application's behalf. For teams working against the API directly, there are 22 OpenAPI specifications and a Postman collection, plus samples including a full B2C application and an AI agent demo.

Configuration has its own tooling. A CLI covers installation through day-to-day resource management. Skills and plugins for Claude Code and Codex bring the same operations into the AI coding tools most teams already run, so setting up an application or debugging a flow happens in the same place as the code that consumes it.

Get involved​

ThunderID is open source, and the work around it is open too. Design discussions happen in public before anything is built. Proposals, decisions, and the reasoning behind them are all in the open. The Community guide covers how to get started, whether that is filing an issue, joining a discussion, or opening a pull request.

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.

Getting started​

Get started by exploring how ThunderID can be used to secure:

• Applications: follow the Securing B2C Application guide
• AI agents: follow the Securing AI Agents guide
• MCP: follow the Securing MCP guide

To learn more about the requirements and solution patterns behind these scenarios, see the Use cases section. Visit Get ThunderID for installation methods.

ThunderID 1.0 is out. Go run it, break it, and tell us what you find.