Add sign-in to your app by setting one field.

Deploy your app with a user pool and the gateway handles the entire browser login before your code runs — the hosted page, the redirect, the session cookie, the refresh. Your app ships no login page, no /auth routes and no session handling. It reads a header.

This is the entire integration.

A pool is the unit of app identity. Connections are how people get in. The deploy flag points your app at the pool — and from that moment the gateway is doing the work.

# a pool is the unit of app identity
dodil appid pool create --group crm-suite

# how people get in
dodil appid connection add local         --pool crm-suite
dodil appid connection add oauth:google  --pool crm-suite \
  --client-id … --client-secret …

# point the app at it — this is the whole integration
dodil ignite app deploy crm-core --auth pool:crm-suite

Turn on Google. That's the whole task.

Paste a client id and secret, flip the toggle. No redeploy, no library, no callback route in your app — the hosted login picks it up on the next sign-in.

Everyone who signed up, in one list.

Invite someone, reset a password, assign a role, ban an account. Revoking sessions signs that person out of every app in the pool at once.

Define them once. Read them off the token.

X-Dodil-User:
  {"sub":"au_9f2c…",
   "email":"[email protected]",
   "connection":"oauth:google",
   "app_roles":["agent"]}

X-Dodil-User-Jwt: eyJhbGciOiJFZERTQSIs…

The parts nobody enjoys writing.

Your app's users are not your Dodil users.

Your Dodil account is a platform principal — it can touch buckets, repos and deploys. The people who use the app you built live in their own pool, with their own issuer and their own signing keys. The two never share an issuer, and a platform grant can never arrive inside an app token. Your customers signing up does not widen your blast radius.