Admin Dashboard

There is no admin dashboard yet. It is planned as initiative #502, and none of it is built. Until it ships, administer organizations, users and the audit log through the admin API, and clients through the gRPC AdminService. This page describes what is planned and what to use in the meantime.

#What it will do

Every organization already has a reserved {slug}-admin-console client for people to sign in with, but nothing serves its screens yet. The dashboard will:

User management is the only thing the dashboard writes. Deleting a user stays an admin API operation.

#How delivery is ordered

The work runs in waves, so that something usable exists early:

1. Groundwork. A design record for the dashboard (#522), admin tokens accepted only from an organization's own admin clients (#517), a permission for every admin operation (#518), and a web workspace with room for a second app (#523).
2. Milestone 1, a walking skeleton. Sign-in, the shell and the audit log, on the admin API that exists today.
3. Milestone 2, the read-only dashboard. Clients, insights and alerts, and the overview.
4. Milestone 3, user management.
5. Closing out. Platform alerts about the deployment itself (#603, #604), proof-bound refresh tokens for the dashboard (#602) and an operator guide (#605).

The roadmap shows the headline issues of each wave.

#How access will work

The dashboard changes how the admin API is authorized, not only how it looks. As planned:

• Only admin clients get admin tokens. Today the admin API accepts any access token the organization issued that carries the right scope and role. Only an organization's own {slug}-admin-console and {slug}-admin-m2m clients will be able to carry a scope that opens the admin API (#517).
• Permissions, not role names. Each admin operation declares the permission it needs in the API contract, and the server resolves the caller's permissions from the store on every request, so a revoked role stops working at once (#518, #530).
• More roles, granted through the API. Read-only, auditor, support and platform roles (#528), with an API to list, grant and revoke roles (#332). A grantor can only grant within their own authority, and an organization can never be left without someone who can grant roles (#542).
• Platform staff. Accounts in the main organization can act in another organization through a role they hold there (#543), and only when their sign-in meets that organization's requirements (#563). Users of other organizations never hold a role outside their own.
• Recent sign-in for destructive actions. Access tokens will carry when and how the user signed in (#526), and removing someone's access or credentials will demand a recent sign-in (#541).
• Masked personal data. Roles that may not see users' personal data get it masked (#564).
• A separate rate limit. Administrators are rate-limited per administrator instead of sharing a limit with anonymous traffic from the same address (#527).

The dashboard itself signs in with PKCE and DPoP and keeps its tokens only in memory, never in browser storage (#548). Signing out, or a period of inactivity, ends the session in every tab (#549).

#What the first version leaves out

The design record (#522) lists what version 1 does not include:

• email-based password reset,
• acknowledging alerts,
• exporting the audit log,
• memberships from one tenant organization in another, and
• per-organization alert thresholds or default time ranges.

"Configurable per organization" means, in version 1, the admin console's branding and the sign-in requirements derived from the organization's existing settings.

#Until it ships

Hardening until #517 lands. Grant the nauthera.orgs:*, nauthera.users:* and nauthera.audit:read scopes only to clients that exist to administer the server. An application client that carries one of them receives a working admin token whenever an administrator signs in to it.