The admin and account consoles

rIDM ships two browser consoles in its Next.js UI (ui/):

• the admin console at /console/, where administrators manage tenants, users, clients and everything else the admin API offers;
• the account console at /account/, where end users manage their own profile, security and connected applications.

Both are static pages served wherever the UI is, the same host as the login pages: by the server itself in the container image (the embedded UI), or by next dev or any static host serving the ui/out export. UI_URL tells the server where that is (it defaults to PUBLIC_URL, the embedded UI’s origin), because the consoles’ built-in clients redirect there. See Deployment overview.

Neither console has privileges of its own. Each is an ordinary OIDC public client of the tenant you sign in through, and every action it takes is an API call made with your token, checked like any other.

The admin console

Open https://id.example.com/console/ (or wherever UI_URL points).

Signing in

Signed out, every console page shows a card asking which tenant to sign in through. Global administrators use master; the administrator of acme alone uses acme. The last tenant used is remembered. The browser then goes through that tenant’s normal login page, including a forced password change or a second factor if one is due, and comes back to /console/callback/ with an authorization code that the page exchanges with PKCE.

The client it signs in with is ridm-admin-console, built into every tenant: public, PKCE only, no consent step, and urn:ridm:admin as its only audience. It is created at start-up and with every new tenant, and its redirect URIs are kept in line with UI_URL. It cannot be deleted. See Administrator access for what makes a user an administrator.

Tokens live in the tab’s sessionStorage, not in cookies or localStorage, so each tab signs in on its own and closing it forgets them. The access token is refreshed shortly before it expires, with refresh-token rotation. Because admin tokens are bound to the browser session, Sign out (RP-initiated logout) ends both the console and the tenant session at once. If the API starts refusing the token (a revoked session, a removed role), the console drops back to the sign-in card with a notice.

A user who signs in but holds no admin permission gets 403 from the API, and the console says “This account has no administrator permissions”.

Finding your way

• Command bar: across the top, with the tenant you are looking at, the search field, the theme switch and a bell that lights up when something needs attention (locked accounts, open invitations, a signing key about to stop publishing, webhook deliveries given up on); it opens the overview’s “Needs attention” list.
• Sidebar: grouped as Identity, Applications, Security, Integrations and Tenant, and filtered by your permissions from GET /admin/me, so it only lists pages you can open. Entries with a list show how many there are; Users shows how many invitations are waiting. Below the tablet breakpoint it becomes a drawer.
• Tenant switcher (global administrators): pick the tenant every page acts on. The choice travels in the URL as ?tenant=acme, so links deep-link into a tenant. Tenant administrators always act on their own tenant.
• Search (Ctrl K / ⌘ K, or /): console pages you may open, plus users and clients of the current tenant whose username, email, client ID or name starts with what you type (two characters or more).
• Breadcrumbs at the top of the page say where you are; a user’s or a client’s detail opens as a panel over its list, and the address (?user=…, ?client=…) still deep-links to it.
• Theme: system, light or dark, kept per browser. The tenant being administered decides whether the switch is offered and what applies otherwise (see Appearance below).

Lists: filters, sorting and bulk actions

Every list is one table: filters sit above it as chips, the rows load as you scroll or with “Load more”, and the footer says how many are loaded. Filters, sort order and search live in the address (?q=ada&status=locked&sort=username&dir=desc), so a reload, a bookmark and the back button land on the same view. Users and clients sort on the server (click a column header); the other lists sort what they have loaded.

Where a list has a checkbox column, selecting rows raises a bar at the bottom with the actions that apply to all of them at once: enable, disable or delete users; revoke invitations; delete IP rules. Every row is attempted even if one refuses, and one message sums the run up (“2 of 3 users deleted; 1 failed: …”). Destructive actions, single or bulk, ask first.

Appearance

Settings → Appearance decides how the sign-in pages, the account console and this console (while it administers the tenant) look:

• Skin: signal-v2 (the default: dark command bar, tinted ground, the page as a sheet), signal, vault or registry. A skin is a set of tokens and a few layout switches; every page works in all four.
• Primary and contrast colours: a hex pair (six presets, or your own). The primary drives actions, navigation, links and focus; the contrast marks what must read as different (selection, the tenant mark, attention). The page shows both tonal ramps and the readability checks for light and dark.
• Light/dark policy: follow each person’s device, or always light or dark; and whether people may switch on their own device.
• Headline and tagline: with the Signal v2 skin, a headline turns the sign-in page into a split layout with a brand panel; the other skins keep the single card.
• Logo, favicon, background colour, support link, footer links and custom CSS, as before.

The login-page preview on the right follows every change. The settings are part of the tenant document (settings.branding), see Tenants and tenant settings.

Keyboard shortcuts

Single keys work when no text field has focus; ? lists them.

The g sequence waits one second for its second key; Esc cancels it, and a held modifier (Shift ahead of ?) does not count as the second key.

Pages

With only a read permission, a page shows its data but disables or hides the controls that would change it. An organization administrator sees that one organization’s members, domains, roles and invitations and nothing of the tenant’s own pages.

Saving as you go

Detail pages and Settings have no Save button. Each change is applied on the page at once and sent as a merge patch when typing pauses (600 ms, and at most 2.5 s into continuous editing; also when the tab is hidden or closed). The header shows “Unsaved changes”, “Saving…”, “Saved”, or the API’s reason for refusing, after which the stored values are reloaded. Actions such as assigning a role or adding a group member apply at once.

Secrets the API returns once (a client secret, a temporary password, a webhook signing secret, a personal access token, a dynamic registration initial access token) are shown in a dialog that says so. Copy them before closing it.

The account console

Open https://id.example.com/account/. Signed out, each page asks which organisation (tenant) to sign in through; ?tenant=acme fills it in and the last one is remembered. After signing in, the user comes back to the page they asked for.

The account console signs in with the built-in ridm-account-console client, whose tokens carry the urn:ridm:account audience and reach only the self-service API under /t/{slug}/account/. A token acts only on its own user, only in the tenant that issued it, and only while its browser session is alive.

Every security change (a factor, a device, a session, the password, a contact detail, the export, deletion) needs a sign-in from the last fifteen minutes, including the second step once the user has one. If it is older, the console sends the user through sign-in again and back to where they were.

Administrators govern what the account console allows with settings.account:

settings.mfa_methods and settings.auth.passkey decide which second factors the Security page offers (see MFA policy), and the identity providers configured for the tenant decide which upstream accounts can be linked.

Administrators cannot delete themselves from the account console; another administrator has to.

The account console and the sign-in pages wear the tenant’s appearance (skin, colours, light/dark policy) and offer the light/dark switch when the tenant allows it; see Appearance.