Management console tour. · ComplicatedAuth

Account setup

Create the administrative boundary.

Tenant Members administer ComplicatedAuth. Project Users are separate identities that belong to one customer application.

ComplicatedAuth Tenant Member sign-in screen — **Tenant Member login**Password verification continues into a passkey or security-key ceremony; only then does the console receive a strong HttpOnly session. Project User login happens in customer applications.

Customer operations

One Tenant-wide Support Case inbox.

Owners, administrators, and support members can triage Project-linked questions, feedback, and bugs without exposing internal correspondence to customer workloads.

Inbox01

Structured triage

Filter by status, category, and Project; inspect the reporter and consented diagnostics; assign, prioritize, and transition with ETag protection.

Conversation02

Public + internal

Append customer-visible replies or operator-only notes, upload constrained attachments, and keep content out of lifecycle events and audit payloads.

Correlation03

Generic external references

Link a remote ticket without making its provider, identifier, status, or schema part of the core Support Case contract.

OAuth and delegated APIs

Protocol resources stay separate from Projects.

OAuth Applications identify clients. Resource Servers identify exact API audiences. Administrative scope grants bound what a Tenant Member may approve; no client registration silently implies delegated access.

OAuth clients01

Registration + credentials

Create public or confidential clients, manage exact redirects with ETags, overlap-rotate expiring secrets, and copy values only once.

Resource Servers02

Audience + scope catalog

Register one immutable exact audience, define immutable capability tokens, maintain consent descriptions, and inspect the current scope-v1 policy version.

Client grants03

Administrative upper bound

Assign a non-empty scope subset to each client/audience pair; changes revoke affected server-tracked access tokens.

Consent04

Human-readable approval

Review the client, return host, exact audience, and registered capability descriptions before approving or denying.

My account05

Grant revocation

See identity and Resource Server consents separately and revoke each client/audience grant with its associated server-tracked tokens.

Tenant access

Roles are enforced, not decorative.

The Tenant Members page lists role, status, and email-verification state. Owners and administrators can invite non-owner members; owner-only invariants remain enforced by the API even if concurrent consoles submit changes.

Members01

Role administration

Manage owner, admin, developer, support, and viewer access with final-owner protection.

Invitations02

One-time acceptance

Create invitations idempotently, deliver fragment-based links by email without exposing them to administrators, inspect safe metadata, and revoke pending invitations.

Account03

Authenticators + sessions

Add, name, rename, and remove passkeys or attested security keys; review assurance and revoke sessions without exposing reusable values.

Authenticated workspace

Operate a Project from one console.

These screenshots use synthetic local data. No production credentials or customer records are shown.

Northstar Web Project overview showing user, origin, service-account, WebAuthn, and activity summaries — **Overview**At-a-glance counts, relying-party configuration, recent security activity, and the next integration action.

Northstar Web Project settings showing identity, environment, status, and relying-party fields — **Project settings**Manage lifecycle fields and the exact relying-party identity used by WebAuthn ceremonies.

Northstar Web service accounts section with controls for scoped workload identities and credential versions — **Service accounts**Create stable backend identities, grant scopes, and issue independently expiring credential versions whose secrets appear only once.

Northstar Web users section listing a synthetic Project User and account state — **Project Users**Provision application identities, inspect verification and credential state, and take lifecycle actions.

Northstar Web activity section showing synthetic Project and Project User audit events — **Activity**Review security-relevant changes with actor, target, event type, and timestamp.

Current surfaces

One workspace, five Project sections.

Origins are currently consolidated into Settings and the old Origins URL redirects to an anchor.

Overview01

Operational summary

Metrics, WebAuthn configuration, recent activity, and the integration prompt.

Settings02

Project + Origins

Lifecycle, environment, RP settings, lock state, and exact allowed origins.

Service accounts03

Workload credentials

Grant exact scopes, issue expiring versions, overlap deployments, observe last use, and revoke independently.

Users04

Identity administration

Provision, verify, disable, replace passwords, revoke sessions, and remove credentials.

Activity05

Project audit trail

Cursor-paginated security events with actor, target, and timestamp.