cantera

The AEC frontend stack

Three open projects with one seam between each pair: aec-auth owns everything token-shaped, cantera renders, and the APS emulator makes the whole flow runnable before anyone has approved an Autodesk app. Each works alone; together they are the five-minute ACC path.

Your Next.js app

canteraui registry

Sign-in card, scope picker, connection cards, and the wired pages. Installed as source with the shadcn CLI — typed props in, callbacks out, no fetching.

the block's /api/auth/* route handlers
aec-authnpm package

Everything token-shaped: consent redirect, code exchange, single-use refresh rotation, vault custody, signed session.

OAuth over HTTPS, to one of:
APS / ACCproduction

Autodesk Platform Services with your own client id and secret.

@emulators/apsdev and demos

A stateful OAuth sandbox embedded in this site at /emulate/aps. Same origin, seeded users, zero credentials.

cantera renders inside your app and calls the block's route handlers; those handlers run on aec-auth, which holds the tokens and talks OAuth to Autodesk. The last hop is a swap: APS_AUTH_BASE_URL points either at real APS or at the embedded emulator, and nothing above it changes.

Three pieces, three jobs

Where the line is

The rule is one sentence: cantera never implements OAuth mechanics beyond a block's thin route wiring. A component takes an OAuthConnection and renders it. It does not know whether the token behind that connection is fresh, where it is stored, or how it will be refreshed — because refresh, storage, and rotation are aec-auth's job, and splitting that job across two projects is how token bugs get written.

@cantera/acc-sign-in is the seam made concrete. It installs a working /sign-in page, the /api/auth/* route handlers, and one lib/acc-auth.ts that configures aec-auth's vault and session. The handlers are thin: start the flow, exchange the code, sign out. Everything underneath is the package's. @cantera/connections-page then reuses those exact routes as a registry dependency rather than growing a second copy of them.

Runnable without credentials

The emulator is embedded in this site at /emulate/aps through @emulators/adapter-next, on the same origin as the app, so the demos work on any deployment URL without a redirect URI to register. Point APS_AUTH_BASE_URL at it and the sign-in block runs its real flow against seeded users: consent screen, code exchange, single-use refresh rotation, scope validation that rejects an unknown scope the way Autodesk would.

Two caveats worth knowing before you copy the setup. The emulator's store is in memory, so a demo connection disappears when the server recycles — expected here, and the reason the demo restarts cleanly. And ACC_AUTH_DEMO exists only so this showcase can run with a fallback session secret; it belongs nowhere near a deployment that guards real accounts.

Environment variables the acc-sign-in and connections-page blocks read
VariableMeaning
APS_CLIENT_ID / APS_CLIENT_SECRETYour APS app credentials.
APS_AUTH_BASE_URLOptional auth origin override — absolute, or relative like /emulate/aps for an embedded emulator. Unset means real APS.
SESSION_SECRETHMAC key for the session cookie. Required in production — the block fails closed.
ACC_AUTH_DEMOEmulator-backed demos only: allows the insecure fallback session secret. Never set it anywhere that guards real accounts.

Built on the stack

Products that install cantera and run on aec-auth. Each one is also where the next domain's types and adapters get proven before they land in the registry.

See it running

  • The demo — the full Autodesk sign-in flow against the embedded emulator.
  • Connections — the manage-grants page, with connect, reconnect, and disconnect.
  • Philosophy — why the UI layer is a registry and what every item is held to.