Authentication model

Axowl has two authentication worlds. Knowing which one you’re in determines which endpoints, tokens, and scopes apply.

1. Org-native auth (dashboard)

Org members authenticate to the Axowl dashboard. Identity is modeled as:

User — one account per email (the login principal).
ConnectedId — a per-organization membership for a User (see Connected ID). A User can hold many ConnectedIds across orgs.

Session tokens carry sub (User id) and org_id; tenancy + membership are resolved server-side by middleware before any handler runs.

2. End-user auth (your application)

Your app’s end users authenticate through Axowl-hosted login or the SDK. Axowl issues a per-org RS256-signed JWT; you verify it with the org’s public JWKS — no shared secret.

The signing key is provisioned per org and used to sign end-user tokens.
Token claims include sub (end-user id), org, cid (ConnectedId), email, app (application key), and permissions.
For server-authoritative checks, the SDK calls Introspect / CheckPermission, which read fresh permissions from the database rather than trusting the token snapshot — so revocations take effect immediately.

Why the split matters

	Org-native	End-user
Principal	User + ConnectedId	EndUser + ConnectedId
Token	Dashboard session	Per-org RS256 JWT
Verified by	Axowl middleware	Your app via JWKS / SDK introspection
Scopes	`axowl.*` internal scopes	App-defined consumer scopes