Pocket ID: A Passkey-Only OIDC Provider for Self-Hosted Apps
The most user-friendly OpenID Connect Certified™ and OAuth 2.0 provider that lets users sign in to your applications with passkeys.
At a glance
- What is it?
- Pocket ID is a Go-based, OpenID Connect Certified OAuth 2.0 provider that authenticates users exclusively with passkeys. It targets self-hosters who find Keycloak or ORY Hydra too heavy for a handful of internal services.
- Who is it for?
- Adopt Pocket ID if you run a small set of self-hosted services, your users can hold a passkey, and you want an OIDC provider you can stand up with one Docker container. Do not adopt it if you need password fallback, LDAP or Active Directory federation, or fine-grained role management; the project's own README states that it only supports passkey authentication, so any user without one is locked out.
- Can I use it commercially?
- Yes. BSD-2-Clause 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 received new commits within the last day.
- 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 problem Pocket ID removes: OIDC without a password database
Self-hosted OIDC providers tend to grow into identity platforms. Keycloak ships realms, clients, roles, user federation and an admin console with its own learning curve. ORY Hydra splits the identity layer from the login UI, which is clean architecture but leaves you building and hosting that login UI yourself. Pocket ID takes the opposite position: it is an OIDC and OAuth 2.0 provider whose only credential type is a passkey. The README states the goal directly, calling the project "simple and easy-to-use" and noting that other self-hosted providers "are often too complex for simple use cases." That is the whole pitch. If you have five services behind a reverse proxy and want single sign-on without storing password hashes, Pocket ID is aimed at you. It is not aimed at organisations that need to model departments, groups and delegated administration. The audience is a person or small team running their own infrastructure, plus anyone who wants a hardware key such as a Yubikey to serve as the login factor across every connected app, which the README lists as a benefit of the passkey-only design.
What passkey-only authentication means for account recovery
A passkey is a WebAuthn credential bound to a device or synced through a platform keychain. There is no shared secret the server can verify against, so there is no password to reset and no password hash to leak. That removes an entire class of credential-stuffing attacks, because there is nothing to stuff. It also removes the escape hatch. If a user loses every device holding their passkey and has no synced copy, the provider cannot issue a temporary password. Recovery has to happen out of band, typically through another administrator or a second registered credential. This is the design trade-off, and the README acknowledges the friction rather than hiding it, saying "Some people might not like this idea at first." Treat that as a real constraint, not marketing modesty. Before you migrate an account, register more than one passkey, ideally on separate hardware, because the project offers no password-based fallback by design. The upside is that the login surface is small enough to reason about: one ceremony, one credential type, no reset flow to secure.
Architecture visible from the repository and README
Pocket ID is written in Go, which means it compiles to a single binary and, in the recommended deployment, runs as one Docker container. The README does not document the internal package layout or the storage engine, so anything beyond that would be guesswork. What can be confirmed is the protocol surface: the project implements OpenID Connect and OAuth 2.0, and its OpenID Connect Certified badge links to the OpenID Foundation's list of certified providers and profiles. Certification matters here because it is an external check on conformance rather than a self-declared claim. The data flow follows the standard authorization code pattern. A relying application redirects the browser to Pocket ID, Pocket ID runs the WebAuthn ceremony against the user's authenticator, and on success it returns an authorization code that the application exchanges for tokens. The application never sees a password because none exists. The README's demo instance at demo.pocket-id.org is the fastest way to inspect that flow before installing anything, since it exercises the same sign-in path a real deployment would.
Getting a container running, and what the README does not specify
The setup section is short. It states that Pocket ID "can be set up in multiple ways" and that "the easiest and recommended way is to use Docker," then points to docs.pocket-id.org for the setup guide. No compose file, image tag, port number, volume path or environment variable appears in the README itself. That is a deliberate division: the repository stays readable and the operational detail lives in the documentation site. The practical consequence is that you cannot install Pocket ID from the README alone. Open the docs before you start, because the configuration keys, the persistent data location and the public URL setting all live there, and getting the external URL wrong will break the OIDC discovery document that relying applications fetch. Plan for a reverse proxy terminating TLS in front of the container, since OIDC clients expect an HTTPS issuer, and WebAuthn is bound to the origin, so the domain you register passkeys under is the domain you must keep using. Changing it later invalidates existing credentials.
Where Pocket ID is the wrong choice
The passkey-only decision is also the main failure mode. Any environment with users who cannot or will not use a passkey is out of scope: shared kiosk accounts, service accounts that need to authenticate programmatically, older browsers without WebAuthn support, and organisations with compliance rules requiring password or smartcard authentication. The README is explicit that passkey support is exclusive, so there is no configuration flag that turns passwords back on. A second limitation is scope. Nothing in the supplied material describes group management, role claims, user federation, LDAP or Active Directory integration, or administrative delegation. If your applications need to read group membership from an ID token to make authorization decisions, verify that the project supports it before you plan around it; the README does not claim it. A third consideration is the release cadence. Three releases landed between 2026-07-29 and 2026-08-18, which suggests active development but also means you should read release notes before upgrading rather than pulling the latest tag on a schedule.
Keycloak and ORY Hydra: the difference is what you operate
The README names both alternatives itself. Keycloak is a full identity and access management server: it stores users, manages realms and clients, supports password and federated login, and ships an admin console. Adopting Keycloak means adopting its data model and its upgrade process, which is heavier than a single container but gives you capabilities Pocket ID does not offer. ORY Hydra takes a different split. It is an OAuth 2.0 and OIDC server that delegates login and consent to an application you write, so the identity store is yours and the protocol handling is Hydra's. That is more flexible and more work. Pocket ID sits between them in effort but not in features: it owns both the protocol layer and the login UI, and it constrains the login UI to passkeys. Choose it when the constraint is acceptable, because the constraint is what makes the deployment small. If you need password fallback or directory integration, neither Pocket ID nor a trimmed-down Hydra will save you; Keycloak is the honest answer.
Licence, maintenance and what to check before upgrading
Pocket ID is released under BSD-2-Clause, a permissive licence that allows modification and redistribution with the copyright notice and disclaimer retained. This is not legal advice, and it does not cover the OpenID Certified trademark or the terms attached to the certification mark, which are separate from the source licence. In practice BSD-2-Clause means you can fork the provider, patch it internally, or ship it inside a product without a copyleft obligation on your own code. Maintenance cost is mostly operational: one container, one persistent volume, one TLS-terminating proxy, and a domain you must not change casually because passkeys are origin-bound. The upgrade cost is the unknown. With three releases in about three weeks, staying current means reading release notes rather than trusting semantic version numbers, and the README offers no compatibility or migration guidance of its own. Before upgrading a production instance, check the release notes for the version you are moving to, back up the persistent data volume, and confirm your relying applications still complete a login on the demo instance or a staging copy first.
Editorial conclusion
Adopt Pocket ID if you run a small set of self-hosted services, your users can hold a passkey, and you want an OIDC provider you can stand up with one Docker container. Do not adopt it if you need password fallback, LDAP or Active Directory federation, or fine-grained role management; the project's own README states that it only supports passkey authentication, so any user without one is locked out. Before committing, verify that every application you plan to connect supports OIDC discovery and the authorization code flow, and confirm your planned upgrade path against the release cadence, which moved from v2.12.0 to v2.14.0 in roughly three weeks.
Community notes