Admin Dashboard

Docs version v1 (main) · Nauthera is pre-1.0, in a design-partner program · Updated November 4, 2026

The server ships an admin dashboard for every organization. It reads the organization's OIDC clients, identity providers, users, sessions, audit log, threat signals, email relay and the problems operators report. Its writes are user management: creating and inviting users; suspending, blocking, reactivating and unlocking them; emailing a reset link or requiring a new password; deleting them; forgetting their remembered browsers; granting and revoking their roles; ending their sessions; and sending a test email. Editing a user's profile, and managing organizations and clients, are done through the admin API and the gRPC AdminService. Still planned lists the work tracked under initiative #502.

#Where it is served

The binary embeds the dashboard and serves it on the public listener, on the issuer's own host:

There is nothing to deploy or turn on. An ingress that sends the issuer's host to the server serves the dashboard too. Every dashboard page is served with no-store and its own Content-Security-Policy: scripts and connections from its own origin only, under Trusted Types, and no framing. The dashboard calls the admin API at /v1/admin/… on the same origin.

#Theme

The dashboard wears the organization's branding: the organization's default branding (spec.branding on its Organization), with the branding of its reserved {slug}-admin-console client laid over it field by field (see Branding). An organization's own administrators, signed in at its issuer, see its whole theme: colors, typography, radius and the other design tokens, its logo, name and light or dark mode. A platform administrator who opens another organization sees only a reduced, contrast-checked part of that organization's theme: its colors, typography and radius. In both cases the banner naming the organization being administered, confirmation dialogs and destructive actions keep styles no theme can override, and the viewer's own light, dark or system choice wins over the brand's mode. The dashboard never edits branding.

#Signing in

The dashboard signs administrators in with their organization's reserved {slug}-admin-console client:

• The authorization code flow with PKCE, at the organization's own issuer. The client's redirect URI is {issuer}/admin/callback and its post-logout address is {issuer}/admin/signed-out.
• Access tokens are DPoP-bound to a key the page cannot export, and held only in memory, never in browser storage. A reload, or an expired token, signs in again with a silent prompt=none redirect that returns to the same address.
• Every authorization asks for a sign-in no older than 12 hours (max_age). An older provider session asks for the password again.
• The sign-in follows the organization's second-factor policy, passwordless sign-in included, since the console has no policy of its own. It is never spared the second factor on a remembered browser or in a trusted network zone: a step-up must prove a fresh factor.
• Signing out ends the provider session too, through RP-initiated logout, and lands on the signed-out page. Every other open dashboard tab is signed out with it, and so is a dashboard left without input for 30 minutes.
• Recent sign-in. Some actions need a sign-in no older than auth.admin.max_auth_age (default 15m, at most 24h), and a second factor when the deployment requires one (mfa.required). The server answers an older token with an RFC 9470 step-up challenge. The dashboard then signs the administrator in again and repeats the action.

Open the dashboard at the organization's address and choose Sign in. Only people who hold an admin role can use it; see Who may use it.

#The screens

Every page of an organization lives at …/admin/orgs/{slug}/…. The frame around them has the navigation, a banner naming the organization being administered, and a search that finds pages, users and clients by name or ID, and audit events by ID, request ID or trace ID. Trace IDs are offered only when the server records traces. The account menu sets the language (English, German or French), the time zone (local or UTC) and light or dark appearance, and signs out. Pages that read data over time have a time-range control: presets from the last 15 minutes to the last 90 days, or a custom range of up to 90 days, with auto-refresh every 30 seconds to 15 minutes. The range, filters and page are kept in the address, so a link opens the same view. Lists page forward and back, with a button back to the first page.

Suspending, blocking, reactivating and unlocking a user, requiring a new password, deleting a user, forgetting remembered browsers, ending sessions, and granting and revoking a role ask for a reason, which is recorded on the audit event. Ending one session signs the browser out of it, retires the refresh tokens it issued, and tells the applications it reached over back-channel logout. All of them but ending one session need a recent sign-in. A change shows only once the server has applied it. Long dialogs scroll inside the window.

Creating a user with an invitation needs an email relay; without one the form says so and offers to set a password instead. The invitation is written in the language chosen in the form and names the administrator who sent it. A user an identity provider created has no password but is not waiting on an invitation, so none is offered.

An organization the administrator cannot reach, or one that does not exist, shows a refusal page instead of the dashboard, with a link back to their own organization. A failed request shows its request ID, and its trace ID when the server records traces, to hand to whoever runs the server.

#Threat analytics

The Threats page reads the audit log as sixteen signals, each a fixed set of actions and outcomes counted over the page's time range. Each tile shows the count, a comparison with the equal period before, a trend line colored by its status, the threshold it is judged by and what to do about it, and links to the audit log filtered to exactly the records it counted. Nothing on the page changes anything.

A signal is quiet with nothing counted and normal below its thresholds. It is elevated or critical when its rate over the whole range reaches that rate, so a threshold means the same over 15 minutes and over a month. It is also elevated when the count is at least two or three times the period before's (the ratio depends on the signal) once it reaches a small floor. The thresholds are built in, taken from what NIST SP 800-63B-4, the OAuth RFCs and the major identity providers publish; there is no per-organization setting yet. A banner at the top counts the elevated and critical signals.

Beside the signals, Sign-in attack shape reads the period's refused password sign-ins: how many, how many named no account, from how many addresses, against how many accounts. Fewer than 20 is too few to read. Otherwise it names the pattern, with advice: credential cracking (10 or more failures per account), password spraying (many accounts, or mostly unknown identifiers, from fewer than 10 addresses), credential stuffing (the same from 10 or more addresses), or no single shape. Behind the refused sign-ins ranks the addresses, accounts, clients and network zones they came from or were aimed at, most first, over at most the last 31 days.

The counts see what the audit level records. Every refusal is recorded whatever the level, but an action excluded by pattern blinds the signal that counts it, and refusals the edge coalesces count once per summary. Each card loads on its own. Answers are cached per organization and window, longer for longer windows, so every administrator watching the page shares one computation.

The page needs threats.read; the rankings need audit.read, and the address ranking users.pii.read too, so a reader without them still sees the rest. The refused sign-ins in spared zones count only where the organization's policy spares the second factor in a zone, where a guessed password is a whole sign-in. Every other signal is also exported as Prometheus metrics with alert rules.

#Who may use it

The server decides every permission. The dashboard hides or explains what the server would refuse. Each admin operation needs an OAuth scope, which the {slug}-admin-console client registers, and a permission, which the user's roles grant. The server reads the user's roles from its database on every call. See Admin API & Users for the roles.

An administrator acts in their own organization. A main-org user with a platform role (platform-viewer, platform-auditor or platform-owner) opens any organization's pages from the organization switcher in the top bar, from the Organizations page or by the slug in the address, and signs in only once.

The first administrator is a main-org user named in auth.admin.subjects, who is granted platform-owner, which holds every permission. From there, roles are granted on each user's Roles tab. A platform owner can grant a tenant organization's own user org-owner there, and that owner then grants roles in their organization. See The first administrator.

#Granting roles

The Grant roles dialog groups roles by where they count, this organization or the platform, marks each with its level (Read, Support or Administer), and marks as Privileged every role that holds more than orgs.read, clients.read and insights.read. Several roles can be granted at once under one reason. It offers only the roles the server says you may change:

• Only org-owner and platform-owner hold roles.assign.
• You grant or revoke a role only when your own roles cover everything it grants, so an org-owner hands out every organization role, the owner role included, and no platform role.
• Nobody changes their own roles.
• Platform roles are granted only in the main organization.
• Revoking the organization's last active account that can grant roles is refused, and nothing changes.

The user is emailed when a role they hold is granted or revoked, through the organization's relay when it has one (see Email). A role counts from the user's next request.

#Still planned

Deleting a user needs users.delete and a recent sign-in, in the dashboard as in the API. The roadmap shows the same work.

#Admin API only