Auth Quickstart: Zero to Running Service
Scaffold a complete FastAPI service with ab0t-auth baked in from the start.
When to Use This vs auth_fastapi_skill
| Situation |
Use |
| No code exists yet |
This skill |
| Existing service needs auth added |
auth_fastapi_skill |
| Need to understand permission design in depth |
auth_fastapi_skill |
| Need scenario walkthroughs by industry |
auth_service_ab0t |
Scaffold Workflow
Step 1: Gather Requirements
Ask the user for:
- Service name — human-readable (e.g., "Invoice Service")
- Service slug — lowercase identifier (e.g.,
invoices). Used in permissions, audience, file names.
- Domain resources — the nouns (e.g., invoices, payments, customers)
- Actions per resource — the verbs (e.g., read, write, create, delete, send, approve)
- Maintainer email — for
.permissions.json
If the user is vague, suggest reasonable defaults and confirm.
Step 2: Copy and Customize Template
The template lives in assets/template/. Copy the entire directory to the user's target path, then replace all placeholders:
| Placeholder |
Replace with |
__SERVICE_NAME__ |
Human-readable name |
__SERVICE_SLUG__ |
Lowercase slug |
__SERVICE_DESCRIPTION__ |
One-line description |
__MAINTAINER_EMAIL__ |
Contact email |
Files to customize:
.permissions.json — Replace starter permissions with real ones derived from the user's resources and actions. Follow the {slug}.{action}.{resource} format. Set admin.implies to include all lower permissions. Never imply cross_tenant.
app/auth.py — Replace starter type aliases (Reader, Writer, Admin) with domain-specific aliases matching the permissions. Example for an invoice service:
InvoiceReader = Annotated[AuthenticatedUser, Depends(
require_permission(auth, "invoices.read", check=belongs_to_org))]
InvoiceSender = Annotated[AuthenticatedUser, Depends(
require_permission(auth, "invoices.send", check=belongs_to_org))]
app/api/items.py — Rename to match the primary resource (e.g., invoices.py). Replace the example routes with real ones using the domain-specific type aliases. Keep the same auth patterns (list with filter, get with Phase 2, create without Phase 2, delete with Phase 2, admin-only).
app/main.py — Update the router import and prefix to match the renamed module.
app/config.py — Add any service-specific settings.
Step 3: Verify Structure
After customization, the project should have:
my-service/
├── app/
│ ├── __init__.py
│ ├── main.py # FastAPI app with auth lifespan
│ ├── config.py # Pydantic settings
│ ├── auth.py # AuthGuard, type aliases, Phase 2, check callbacks
│ └── api/
│ ├── __init__.py
│ ├── health.py # Unauthenticated health check
│ └── {resource}.py # Auth-protected CRUD routes
├── .permissions.json # Permission definitions for registration
├── .env.example # Environment variable reference
├── .gitignore # Excludes credentials/, .env, etc.
├── requirements.txt # Dependencies including ab0t-auth
└── Dockerfile # Production container
Step 4: Run Locally
cd my-service
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env # Edit values
# Development with auth bypass
AB0T_AUTH_DEBUG=true AB0T_AUTH_BYPASS=true uvicorn app.main:app --reload
Verify:
GET /health returns {"status": "ok"} (no auth)
GET /items/ returns data with bypass user (auth bypassed)
- Routes return proper 401/403 JSON when bypass is off and no token is provided
Step 5: Guide Next Steps
After the scaffold is running, point the user to references/next-steps.md for:
- Adding more permissions and type aliases
- Adding check callbacks (suspension, quota)
- Wiring up Phase 2 ownership verification with a real database
- Registering with the auth service
- Multi-tenancy setup
- Middleware for blanket auth
- Production checklist
For deep dives, reference the auth_fastapi_skill:
Permission Design Quick Reference
Format: {slug}.{action} or {slug}.{action}.{resource}
| Action |
Meaning |
Risk |
read |
View without side effects |
low |
write |
Modify existing records |
medium |
create |
Create new records |
medium |
delete |
Permanently remove |
high |
execute |
Run user-provided code |
high |
admin |
Full org-level access (implies lower perms) |
critical |
cross_tenant |
Cross-org access (NEVER implied by admin) |
critical |
Common Mistakes
- Forgetting to rename placeholders — grep for
__SERVICE after scaffolding to catch any missed replacements
- Skipping Phase 2 — every route with
/{id} in the path needs verify_resource_access() after the DB fetch
- Implying
cross_tenant from admin — never do this; it must be a conscious separate grant
- Unscoped list queries — always use
get_user_filter(user) for list/search routes
- 404 after 403 — always check resource exists (404) before checking access (403)
Source: ab0t-com/auth_wrapper — distributed by TomeVault.
1---2name: auth-quickstart3description: Scaffold a new FastAPI microservice from zero with ab0t-auth already integrated. Use when creating a brand new service that doesn't exist yet, bootstrapping a project from scratch, or when the user says "new service", "start from scratch", "scaffold", "quickstart", "create a new API", or "bootstrap". Generates a complete project structure with auth guard, permission scheme, type aliases, example CRUD routes, config, Dockerfile, and registration-ready .permissions.json. NOT for adding auth to an existing service (use auth_fastapi_skill for that). Use when this capability is needed.4---56# Auth Quickstart: Zero to Running Service78Scaffold a complete FastAPI service with ab0t-auth baked in from the start.910## When to Use This vs auth_fastapi_skill1112| Situation | Use |13|-----------|-----|14| No code exists yet | **This skill** |15| Existing service needs auth added | auth_fastapi_skill |16| Need to understand permission design in depth | auth_fastapi_skill |17| Need scenario walkthroughs by industry | auth_service_ab0t |1819## Scaffold Workflow2021### Step 1: Gather Requirements2223Ask the user for:241. **Service name** — human-readable (e.g., "Invoice Service")252. **Service slug** — lowercase identifier (e.g., `invoices`). Used in permissions, audience, file names.263. **Domain resources** — the nouns (e.g., invoices, payments, customers)274. **Actions per resource** — the verbs (e.g., read, write, create, delete, send, approve)285. **Maintainer email** — for `.permissions.json`2930If the user is vague, suggest reasonable defaults and confirm.3132### Step 2: Copy and Customize Template3334The template lives in `assets/template/`. Copy the entire directory to the user's target path, then replace all placeholders:3536| Placeholder | Replace with |37|-------------|-------------|38| `__SERVICE_NAME__` | Human-readable name |39| `__SERVICE_SLUG__` | Lowercase slug |40| `__SERVICE_DESCRIPTION__` | One-line description |41| `__MAINTAINER_EMAIL__` | Contact email |4243**Files to customize:**44451. **`.permissions.json`** — Replace starter permissions with real ones derived from the user's resources and actions. Follow the `{slug}.{action}.{resource}` format. Set `admin.implies` to include all lower permissions. Never imply `cross_tenant`.46472. **`app/auth.py`** — Replace starter type aliases (`Reader`, `Writer`, `Admin`) with domain-specific aliases matching the permissions. Example for an invoice service:48 ```python49 InvoiceReader = Annotated[AuthenticatedUser, Depends(50 require_permission(auth, "invoices.read", check=belongs_to_org))]51 InvoiceSender = Annotated[AuthenticatedUser, Depends(52 require_permission(auth, "invoices.send", check=belongs_to_org))]53 ```54553. **`app/api/items.py`** — Rename to match the primary resource (e.g., `invoices.py`). Replace the example routes with real ones using the domain-specific type aliases. Keep the same auth patterns (list with filter, get with Phase 2, create without Phase 2, delete with Phase 2, admin-only).56574. **`app/main.py`** — Update the router import and prefix to match the renamed module.58595. **`app/config.py`** — Add any service-specific settings.6061### Step 3: Verify Structure6263After customization, the project should have:6465```66my-service/67├── app/68│ ├── __init__.py69│ ├── main.py # FastAPI app with auth lifespan70│ ├── config.py # Pydantic settings71│ ├── auth.py # AuthGuard, type aliases, Phase 2, check callbacks72│ └── api/73│ ├── __init__.py74│ ├── health.py # Unauthenticated health check75│ └── {resource}.py # Auth-protected CRUD routes76├── .permissions.json # Permission definitions for registration77├── .env.example # Environment variable reference78├── .gitignore # Excludes credentials/, .env, etc.79├── requirements.txt # Dependencies including ab0t-auth80└── Dockerfile # Production container81```8283### Step 4: Run Locally8485```bash86cd my-service87python -m venv .venv && source .venv/bin/activate88pip install -r requirements.txt89cp .env.example .env # Edit values9091# Development with auth bypass92AB0T_AUTH_DEBUG=true AB0T_AUTH_BYPASS=true uvicorn app.main:app --reload93```9495Verify:96- `GET /health` returns `{"status": "ok"}` (no auth)97- `GET /items/` returns data with bypass user (auth bypassed)98- Routes return proper 401/403 JSON when bypass is off and no token is provided99100### Step 5: Guide Next Steps101102After the scaffold is running, point the user to [references/next-steps.md](references/next-steps.md) for:103- Adding more permissions and type aliases104- Adding check callbacks (suspension, quota)105- Wiring up Phase 2 ownership verification with a real database106- Registering with the auth service107- Multi-tenancy setup108- Middleware for blanket auth109- Production checklist110111For deep dives, reference the **auth_fastapi_skill**:112- [permissions-design.md](../auth_fastapi_skill/references/permissions-design.md) — full schema and design principles113- [route-patterns.md](../auth_fastapi_skill/references/route-patterns.md) — all 7 route protection patterns114- [implementation-details.md](../auth_fastapi_skill/references/implementation-details.md) — all 19 type aliases, check callbacks115- [registration.md](../auth_fastapi_skill/references/registration.md) — auth service registration walkthrough116117## Permission Design Quick Reference118119**Format:** `{slug}.{action}` or `{slug}.{action}.{resource}`120121| Action | Meaning | Risk |122|--------|---------|------|123| `read` | View without side effects | low |124| `write` | Modify existing records | medium |125| `create` | Create new records | medium |126| `delete` | Permanently remove | high |127| `execute` | Run user-provided code | high |128| `admin` | Full org-level access (implies lower perms) | critical |129| `cross_tenant` | Cross-org access (NEVER implied by admin) | critical |130131## Common Mistakes1321331. **Forgetting to rename placeholders** — grep for `__SERVICE` after scaffolding to catch any missed replacements1342. **Skipping Phase 2** — every route with `/{id}` in the path needs `verify_resource_access()` after the DB fetch1353. **Implying `cross_tenant` from `admin`** — never do this; it must be a conscious separate grant1364. **Unscoped list queries** — always use `get_user_filter(user)` for list/search routes1375. **404 after 403** — always check resource exists (404) before checking access (403)138139---140> Source: [ab0t-com/auth_wrapper](https://github.com/ab0t-com/auth_wrapper) — distributed by [TomeVault](https://tomevault.io).141<!-- tomevault:4.0:skill_md:2026-05-22 -->