Skip to Content
We are live but in Staging 🎉
Overview

Dodil AppID

Dodil AppID is identity for the end users of the applications you build on Dodil — your customers, business users, and guests. You create a pool, point your app at its issuer URL, and AppID handles sign-up, sign-in, password reset, email verification, sessions, and tokens. A hosted, brandable login page ships with it; so does a JSON API if you’d rather build your own screens.

It is deliberately modeled on the Supabase-Auth shape — an auth service for your app’s users — not an enterprise IdP you have to configure realm by realm.

Two identity planes — never mixed

Dodil has two kinds of people, and two services to match:

platform plane ──► Dodil IAM        org users, service accounts, dk_ API keys
                                    issuer: id.dodil.io  (who builds the app)

app plane      ──► Dodil AppID      the app's own end users
                                    issuer: appid.dodil.io/{org}/{pool}  (who uses the app)

The two planes never share an issuer, and an app user is never a platform principal — a token minted by your pool cannot touch K3 buckets, Ignite apps, or the registry. Your backend verifies pool tokens by iss and aud; the platform verifies its own the same way.

The pool

A pool is the unit of app identity. Each pool owns:

  • an Ed25519 keypair → its own issuer https://appid.dodil.io/{org}/{pool}, JWKS, and OIDC discovery document
  • a user store — managed by default, or your own K3  bucket or Postgres, with live migration between them
  • connections (how users sign in: email + password, Google, and other OpenID Connect providers)
  • settings and policies — signup on/off, email verification, token TTLs, redirect URIs, rate limits, CORS origins
  • a role → permission catalog, expanded into every access token
  • app tenants — sub-organizations inside the pool (workspaces, subsidiaries) with per-tenant roles
  • branding for the hosted pages and transactional emails

A pool is rows plus a keypair — there is no per-pool server, realm, or infrastructure to operate.

What you get out of the box

  • Hosted sign-in at {issuer}/login — sign in, sign up, forgot password, all brandable (logo, colors, dark mode, layout, custom copy) via a JSON branding document.
  • OIDC authorization-code flow with PKCE (S256, mandatory) for SPAs and native apps — plus direct JSON password/refresh_token grants if you own the UI.
  • EdDSA-signed JWTs with your roles, permissions, and tenant memberships as claims; rotating refresh tokens with reuse detection that burns the whole session family.
  • User management from the console, dodil appid CLI, or REST API — invite, ban, roles, password resets, session revocation.
  • Branded emails for verification and password reset.
  • Sign in with Google (and other OpenID Connect providers) alongside email + password. Each enabled provider gets a “Continue with …” button on the hosted page.
  • Single sign-on across apps that share a pool: a person signed in to one app is signed in to the others.
  • Each person’s AI assistant signs in as them. Claude.ai and ChatGPT can connect to your app’s MCP server; each person signs in and approves the assistant, and its token carries only their roles. See Sign-in for Ignite apps.
  • Service clients for machine-to-machine calls between your apps (client_credentials), with roles from the same catalog.

How it fits with Dodil

  • The control plane rides platform auth. Creating pools and managing users happens with your normal Dodil sign-in (dodil auth login); an org owner can always manage their org’s pools.
  • User data can live in your bucket. Point the pool’s user store at a K3 bucket and the users are your rows — query them over the pg wire  like any other table.
  • Made for Ignite apps — no auth code. Attach the pool to an Ignite  app (--user-pool) and the gateway runs the whole sign-in, then hands your handler a verified identity in a header. Each person signs in as themselves; nobody shares a login. See Sign-in for Ignite apps, and Keep each customer’s data separate for the row-level half.
  • Not the builder’s login. dodil auth login, the CLI and the Dodil MCP server sign in you, the builder. Your app’s users live in a pool, on a separate plane.

In this section

  • Quickstart — create a pool, sign up a user, run the full login flow in minutes
  • Core Concepts — pools, connections, tokens, tenants, user stores, the two planes
  • Auth and Access — who may manage pools, and how end-user auth actually works
  • CLI Guide — the dodil appid commands
  • API Reference — the control-plane REST API and the public issuer API
  • Recipes — sign-in for Ignite apps, keeping each customer’s data separate, hosted login for an SPA, verifying tokens in your backend, owning your user store

CLI: dodil appid — see Install the CLI .

What’s shipped (latest release 0.15.2, October 2026). Sign-in methods: email + password, Google (tested end to end), and Microsoft Entra ID or any other OpenID Connect provider through the same discovery-URL connection. GitHub is not supported (it isn’t OpenID Connect). Not yet available: SAML, magic links, and multi-factor authentication. This documentation only describes what works today.

Quickstart