Enterprise identity and onboarding

Hyperoru treats identity as part of the evidence boundary. A provider assertion can prove who signed in, but it cannot silently create workspace authority.

Secure your account with MFA

Open Workspace settings → Security and enroll a TOTP authenticator. Confirm the first code, then store the one-time recovery codes outside Hyperoru. Recovery codes are shown once and each code can be used only once.

The security view lists active browser sessions and their authentication method. Revoking a session takes effect immediately. Enrollment, recovery, step-up, and factor changes rotate session identifiers so an earlier session cannot inherit new authority.

Connect an organization provider

Workspace owners can add any standards-compliant OIDC provider. Supply its issuer, client ID, client secret, verified email domains, and optional claims mapping. Hyperoru validates discovery endpoints, encrypts the secret, and saves the provider in Testing.

Choose Test sign-in to complete a state-, nonce-, and PKCE-protected login. A successful test verifies token issuer, audience, signature, subject, email, and domain before activating the provider. SSO can be optional or enforced only after activation.

Understand identity linking

Hyperoru links OIDC to the existing canonical user only when the provider subject, verified email account, and invitation resolve safely. A matching email never grants access on its own. New workspace membership requires a pending invitation, and mapped roles are capped by that invitation. OIDC can never grant owner or platform-operator access.

If identities disagree, the login is denied. The operator console records a pseudonymous failure reason for support without exposing the asserted email.

Resume onboarding

The onboarding journey keeps your last verified stage:

1. verify the account;
2. create or choose the workspace;
3. invite the team;
4. describe organizational context;
5. connect evidence sources;
6. confirm first-audit readiness;
7. complete setup.

Optional stages can be deferred. Policy blockers such as unverified email or required MFA cannot be skipped. Provider secrets and access tokens are never stored in onboarding progress.

Recover safely

If SSO is degraded, an owner can disable the provider without removing local users, memberships, or history. Platform operators can revoke sessions or unlock a recovery credential only through an audited action with a reason. Keep two recoverable owner accounts and exercise the break-glass path before enforcing SSO.