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.

• Apps in one group share a customer account. Different groups in the same organization issue distinct subjects to the same email address. The organization signs both tokens with its signing key.
• Token claims include sub (the member ID in this app group’s member scope), org and org_slug, cid (the ConnectedId badge — issued to every end user), is_employee (whether the customer has a verified employee link), email, app (the client key, also the token’s aud), app_group, 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.

Note

Server-side permission checks read the stored permissions at the time of the call, which is fresher than the JWT’s permissions claim. See Permission scopes.

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	platform.* internal scopes	App-defined consumer scopes