OpenID Certified at 30 MB: What Pocket ID and Tinyauth's Formal OIDC Conformance Actually Proves for Your PaaS Admin Login

For years, the conversation about who gets to guard a production admin surface had an unwritten rule: if the identity provider wasn't Keycloak, Okta, or something equally heavyweight, it didn't make the shortlist. "It's popular on GitHub" was never an answer that survived a security review. That rule just lost its foundation. In the summer of 2026, two of the smallest self-hosted identity providers in existence passed the OpenID Foundation's formal conformance suite: Tinyauth v5.1.0 became OpenID Certified for the Basic OP profile on June 25, 2026, and Pocket ID now appears in the Foundation's certified-implementations registry at v2.10.0 with three profiles — Basic OP, Config OP, and Form Post OP.

Here's the short version of what that means, up front. Certification proves protocol conformance: the authorization code flow, token handling, discovery metadata, and error behavior of these servers were tested against the same suite Keycloak passed, and they behaved correctly. It does not prove operational security — deployment hardening, CVE response, or session hygiene are out of scope. But for the specific question "why should a 30 MB binary be trusted to gate our platform's admin dashboard?", a platform operator can now point at a formal, third-party-verifiable credential instead of a star count. And the footprint gap is real: Pocket ID ships as a 27.9 MB compressed distroless container image (33.4 MB for the standard image), and Tinyauth is a single statically linked Go binary weighing 37.7 MB on amd64 (35.7 MB on arm64) — while Keycloak is a JVM application server that lands an order of magnitude heavier before it serves its first login.

What the OpenID Conformance Suite Actually Tests​

The OpenID Foundation runs a free, public conformance test suite that any implementer can point at their server. Certification is self-certification with teeth: you run the suite against your deployment, the suite exercises the protocol exhaustively, and if every test passes you submit the results along with a certification fee to the Foundation. In return you get the legal right to display the "OpenID Certified" mark, and your results are published in the Foundation's registry where anyone — including the security team reviewing your architecture proposal — can inspect them.

The profiles matter, because each one certifies a specific slice of protocol behavior:

• Basic OP covers the authorization code flow — the flow virtually every server-side web app and every kube-apiserver OIDC integration uses. Passing it means the server issues, signs, and validates tokens correctly, handles state and nonce properly, and returns spec-compliant errors instead of improvising.
• Config OP certifies the discovery document (/.well-known/openid-configuration) — the machine-readable metadata that lets clients configure themselves against the issuer without hand-copied endpoints.
• Form Post OP covers the form_post response mode, where the authorization response comes back as an auto-submitted form rather than query parameters — keeping tokens and codes out of URLs, server logs, and browser history.

Why does the Foundation bother? Because identity is the one place where a subtle interoperability bug is indistinguishable from a vulnerability. An IdP that skips nonce validation or accepts an unsigned token doesn't fail loudly — it fails silently, in production, in the exact scenario an attacker constructs. Proof-of-conformance is the safeguard, which is why certification is already a hard prerequisite in ecosystems like open banking, where regulators require certified implementations before a provider can participate at all.

The Certification Scoreboard: Lightweight vs. Heavyweight​

Here is where the registry gets interesting. Compare what's actually certified, at what size:

Two things jump out. First, Pocket ID's three certified profiles are more than ZITADEL's one — a passkey-only IdP maintained by a small team now carries broader certified coverage than a commercial cloud-native IAM product's registry entry. Second, note who is absent: authentik, Authelia, and Dex — all substantially more established than either newcomer in the self-hosted world — do not appear in the OpenID Foundation's certified-implementations listing at all. That's not evidence they're broken; plenty of correct implementations never go through certification. But it inverts the old credibility hierarchy. The two smallest options on the menu are now the ones holding the formal credential, while some far more widely deployed projects rely on exactly the "it's popular, it's audited by usage" argument the lightweight IdPs used to be dismissed for.

The size numbers deserve honest precision rather than a rounded equivalence. Pocket ID's compressed distroless image at 27.9 MB genuinely sits under 30; Tinyauth's binary, with its entire web UI embedded, runs 35.7–37.7 MB depending on architecture. Both are "30 MB class" the way Keycloak is "500 MB class" — the point is not the exact megabyte but that either one fits in the memory headroom a Keycloak deployment reserves for JVM garbage collection.

What Certification Does Not Prove​

This is the section a security reviewer will (rightly) push on, so it deserves the same concreteness as the good news. The conformance suite tests the protocol surface — nothing else. Specifically, certification says nothing about:

• Deployment hardening. A certified IdP behind a misconfigured reverse proxy, with TRUST_PROXY open to the world or TLS terminated carelessly, is still a hole. The suite never sees your deployment.
• Vulnerability response. Certification doesn't measure how fast a project ships security patches. The evidence there is the track record: Tinyauth published v5.1.3 on July 30, 2026 as an urgent patch for a path-handling access-control bypass (GHSA-r27r-rr9v-vv37), and Pocket ID's v2.12.0 (July 29, 2026) also led with security fixes. Both projects patched promptly — but that's an observation about maintainer behavior, not something the certificate guarantees.
• Authentication strength. The suite validates the OIDC flows after a user authenticates. Pocket ID's passkey-only design and Tinyauth's TOTP support live entirely outside the tested surface.
• Session storage, LDAP sync correctness, rate limiting, availability, supply-chain integrity. All out of scope.
• Future versions. Certification is version-pinned. Tinyauth's certificate names v5.1.0; the binary you deploy today is v5.1.3. Pocket ID certified v2.10.0 and has shipped v2.11.0 and v2.12.0 since. Point releases rarely touch protocol code, but "we run a certified implementation" technically means "we run a descendant of a certified version" — say that plainly in your security review and nobody can accuse you of overclaiming.

The correct mental model: certification retires one specific class of doubt — "does this small project actually implement OIDC correctly, or does it just mostly work?" — and leaves every operational question exactly where it was. That's still a big deal, because protocol correctness was precisely the doubt that a small team couldn't previously answer with anything better than "read the code yourself."

Putting a Certified Lightweight IdP in Front of a PaaS Admin Surface​

So what does this change in practice for someone running a self-hosted platform — a PaaS control plane, a Cluster API management cluster, an internal deploy dashboard? The two projects slot into that architecture in different ways, and the difference is worth understanding before picking one.

Tinyauth is forward-auth middleware. It sits behind your reverse proxy — Traefik, Nginx, or Caddy — and the proxy asks it "is this request authenticated?" before anything reaches the upstream app. Gating a platform admin dashboard with Traefik looks like this:

# docker-compose labels on the admin dashboard service
labels:
  - "traefik.http.routers.admin.middlewares=tinyauth"
  - "traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik"

Every request to the admin UI now detours through Tinyauth; unauthenticated users get a login screen, and the app behind it never needs to implement auth at all. Configuration is entirely environment variables, which is exactly what you want for a component that must be reproducible from a git repo.

Pocket ID is a full OIDC provider. Your platform's dashboard registers as an OIDC client, users sign in with passkeys only — there is no password to phish — and the certified discovery document (that Config OP profile) means any conformant client can self-configure against it. This is also the route for Kubernetes itself: kube-apiserver accepts any conformant OIDC issuer via --oidc-issuer-url and --oidc-client-id, so the same Pocket ID instance that gates your dashboard can issue the tokens your operators use with kubectl against a Cluster API management cluster. Pocket ID's scoped OAuth tokens (added in the certified v2.10.0 release) extend the same story to non-human operators — AI agents and MCP servers get narrowly scoped credentials instead of a shared admin cookie.

This matters directly for platforms like Bex.co, the open-source, AI-native Render alternative — a self-hosted PaaS's admin surface is precisely the "small fleet, high stakes" case these IdPs now credibly serve: the whole point of running the platform on machines you own is that no SaaS vendor is holding the keys, and a 30 MB certified IdP means the identity layer doesn't have to be the one component that breaks the self-hosted, resource-light posture of the rest of the stack.

When Lightweight Is Enough — and When It Isn't​

A decision framework, compressed:

A certified lightweight IdP is the right call when:

• The protected surface is an admin team, not a customer base — tens of operators, not thousands of end users.
• You want passkey-first (Pocket ID) or proxy-level gating with minimal moving parts (Tinyauth).
• The ops budget for identity is one container and zero dedicated maintainers.
• Your relying parties speak standard OIDC — which, post-certification, you can verify against the discovery document rather than hope.

Reach for Keycloak or ZITADEL instead when:

• You need multi-realm / multi-tenant identity — separate user pools per customer with federation between them.
• SAML is non-negotiable because of enterprise relying parties.
• You need dynamic client registration: note that neither lightweight IdP certified the Dynamic OP profile, and Keycloak's six-profile certification exists precisely because large deployments exercise all of them.
• User federation at scale (large LDAP/AD estates, social login brokering) is the actual job.

The forward-looking read: certification is becoming table stakes for self-hosted identity. Two years ago, no lightweight self-hosted IdP was certified; today two are, and both treated it as a launch-worthy milestone. The next time a security-conscious team asks why a minimal OIDC provider should guard the control plane of a fleet, the answer is no longer a GitHub star count. It's a registry entry at openid.net — the same registry Keycloak is in — plus an honest list of what that entry does and doesn't cover. That's a conversation lightweight self-hosted identity couldn't have in 2024. It can now.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.