ThunderID: an Apache-2.0 identity stack that treats AI agents as first-class identities
ThunderID is a high-performance, open-source identity stack designed for developers to secure and manage access for humans, AI agents, and machines through fully composable identity flows.
At a glance
- What is it?
- ThunderID is a Go identity and access management server covering OAuth 2.1, OpenID Connect, verifiable credentials and agent identity, configured through YAML and shipped as a container. The interesting part is the agent model and the declarative runtime. The unproven part is everything the README promises about post-quantum readiness.
- Who is it for?
- Adopt ThunderID if you are building agent-driven or decentralized-identity flows and want a single Go runtime that speaks OAuth 2.1, OIDC, OpenID4VCI and OpenID4VP under one configuration model. Do not adopt it if you need a mature enterprise IAM product with a long support history, or if your identity requirements are plain username and password with no agents and no credentials.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ThunderID is aimed at: agents that need credentials, not just API keys
Most identity servers were designed around a human typing a password into a browser. When you add autonomous agents to that picture, the usual answer is a long-lived API key pasted into a config file, with no consent record, no delegation chain and no way to trace which agent acted on whose behalf. ThunderID's README states the project is built to secure access for humans, AI agents and machines, and lists agent-native identity as a core design goal, with delegated authority, consent-aware access and traceability. It also states an intent to issue verifiable credentials to agents. That is the specific problem: giving a non-human actor a credential that carries scope and provenance instead of a shared secret. The audience is developers building agent-driven workflows, APIs and services who would otherwise bolt an authorization layer onto an OAuth server that has no concept of a non-human principal. It is not aimed at teams who just need a login form.
What the runtime actually contains: journeys, executors and a declarative resource model
The README describes user journeys as the unit of authentication logic. Login, registration and recovery are each defined as a journey, and the server ships more than 20 built-in executors covering password, passkey, OTP, social login and consent. Those executors can be orchestrated in the server or in the application, which matters because it decides where your credentials and intermediate state live. A server-orchestrated journey keeps the flow inside ThunderID; an application-orchestrated one hands control back to your code. The README does not spell out the wire format for the second case, so treat that boundary as something to read the docs for before committing. Authorization is described as hierarchical resources with derived permissions, plus role-based access control across users, agents and applications, and consent management with a user-facing review step. On the standards side the README lists OAuth 2.1 and OpenID Connect with PAR and PKCE, WebAuthn and passkeys, and IdP federation to Google, Microsoft, GitHub and any OIDC or SAML provider. Decentralized identity is handled through OpenID4VCI for issuance and OpenID4VP for verification, with credential templates and presentation definitions checked against trust anchors. The README says credentials can be used standalone or as part of an identity journey, which is the more useful arrangement: a wallet presentation can sit next to a password step in the same flow.
Declarative configuration and the GitOps claim
The README states that every entity has a YAML resource definition and that the runtime is immutable. That combination is the project's operational thesis: identity configuration lives in version control, changes are reviewed like code, and the running container does not drift from what is committed. For teams already running Kubernetes with a GitOps controller, this removes a category of incident where a console edit silently diverges from the repository. The cost is that anything not expressible in the YAML schema requires a code change or an out-of-band path. The README does not enumerate the schema, so the practical question of which fields are declarative and which are not cannot be answered from the repository description alone. The Console UI is listed under developer experience alongside REST APIs and SDKs, which suggests a UI exists for the same resources, but the README does not say whether UI edits are written back as YAML or held separately. If they are held separately, the immutability claim is narrower than it sounds. That is worth checking in the documentation before you build a deployment process around it.
Getting it running: what the README gives you and what it does not
The README does not include an install command. It points to a Get ThunderID page in the documentation for installation methods, and to three try-it-out guides: Securing B2C Application, Securing AI Agents, and Securing MCP. It also states the runtime is containerized and can run on-premises or in the cloud, and that contributors should follow the Contributing Code prerequisites to run ThunderID in development mode. So the honest answer to how you start it is: read the get-thunderid page, because the repository description supplied here contains no docker run line, no Helm chart name and no binary name. What the README does establish is the shape of the work. You will define YAML resources for the entities you need, configure at least one journey from the built-in executors, and register an application or agent as a client against the OAuth 2.1 and OIDC endpoints. For the credential path you will define credential templates for issuance and presentation definitions for verification. If you are evaluating ThunderID, the fastest honest test is the B2C try-it-out guide, because it exercises the parts that are least likely to surprise you. The AI agents and MCP guides are where the differentiating behaviour lives, and they are also where the documentation is most likely to be ahead of the released code.
The post-quantum and crypto-agility language is a direction, not a shipped guarantee
The README says ThunderID is post-quantum-safe by design and describes a crypto-agile foundation where algorithms, key types, signing methods and token protection mechanisms can evolve, with support for post-quantum-safe algorithms and hybrid transition approaches across key management, credential issuance, assertions and secure service-to-service communication. Read that carefully. It is a statement about architecture and intent. The README does not name a single post-quantum algorithm, does not say which of those four areas currently ship with one, and does not distinguish between implemented and planned. For a project at v1.0.1, that gap is normal, but it means you cannot treat post-quantum readiness as a checkbox you have satisfied by choosing ThunderID. If regulatory or contractual language requires post-quantum cryptography today, verify the actual implementation in the key management and token signing paths before you rely on it. The same caution applies to the decentralized identity features. OpenID4VCI and OpenID4VP are listed as features, and the release history shows a v1.0.0 line, but the README gives no indication of which specification versions are tracked or how mature the wallet interop is.
Where ThunderID is the wrong tool
ThunderID is a large surface. OAuth 2.1, OIDC, WebAuthn, SAML federation, verifiable credentials, hierarchical authorization, consent, a console, SDKs and an MCP server are all in scope. If your requirement is a single-tenant login for an internal tool with a handful of users, that surface is a liability: more endpoints to configure, more YAML to maintain, more upgrade notes to read. A smaller OIDC provider will get you there with less operational weight. The second case is teams that need a long support horizon and vendor accountability. ThunderID reached v1.0.0 in August 2026 according to the release list, and v1.0.1 followed ten days later. There is no evidence in the supplied material of a commercial support offering, a long-term support branch, or a migration policy between minor versions. If your identity layer is on a multi-year compliance cycle, that absence matters more than any feature list. The third case is any deployment where the agent and verifiable-credential features are irrelevant. Those features are the reason the project exists, and you would be paying their complexity cost for nothing.
Alternatives and the real difference in approach
Keycloak is the obvious comparison for a self-hosted, open source IAM server. The difference is not features, it is the configuration model. Keycloak is administered primarily through an admin console and a database, and its realm configuration is exported and imported as JSON rather than authored as the primary source of truth. ThunderID inverts that: the README states YAML resource definitions for every entity and an immutable runtime, which puts the file, not the database, at the centre of the workflow. If your team already reviews infrastructure changes through pull requests, that inversion is the whole argument. If your team expects to click through an admin UI and have the change stick, it is friction. The second axis is scope. Keycloak's model is users, clients, roles and realms. ThunderID adds agents as a distinct identity type, verifiable credentials through OpenID4VCI and OpenID4VP, and an MCP server for querying IAM from an agent. A third option is to assemble the pieces: an OIDC provider for human login, a separate authorization service for policy, and a credential library for issuance. That gives you control over each layer and three upgrade cycles to manage instead of one. ThunderID's bet is that agent identity and human identity belong in the same runtime because delegation crosses between them, and that bet is either the reason to adopt it or the reason to walk away.
Licence, upgrade cost and what to check before committing
ThunderID is licensed under Apache-2.0. That permits commercial use, modification and distribution, and it includes an explicit patent grant. It does not impose copyleft obligations on your own code, and it does not require you to publish modifications. It also provides no warranty, and it does not by itself give you any support commitment from the maintainers. This is a description of the licence text, not legal advice; if you are embedding ThunderID in a product with its own compliance obligations, have counsel read the LICENSE file. On upgrade cost, the release history shows v1.0.0-rc, v1.0.0 and v1.0.1 within about six weeks, and the README describes the runtime as immutable with declarative configuration. That combination usually means upgrades are a container image swap plus a schema check on your YAML, which is cheap when the schema is stable and expensive when it is not. The supplied material does not include a changelog or a compatibility statement, so the size of that risk is unknown. Before adopting, read the v1.0.0 and v1.0.1 release notes for breaking changes, confirm whether the YAML schema is versioned, and check the commit history on the key management package to see whether the crypto-agility claim has code behind it.
Editorial conclusion
Adopt ThunderID if you are building agent-driven or decentralized-identity flows and want a single Go runtime that speaks OAuth 2.1, OIDC, OpenID4VCI and OpenID4VP under one configuration model. Do not adopt it if you need a mature enterprise IAM product with a long support history, or if your identity requirements are plain username and password with no agents and no credentials. Verify first that the post-quantum and crypto-agility claims are implemented rather than planned by reading the key management code paths, and confirm that the OpenID4VCI and OpenID4VP endpoints you depend on are wired into a released version rather than only documented.
Community notes