Skip to main content
All documentation

Single sign-on and identity

Set up sign-in, connect applications and keep identity access within the correct organisation and domain.

Workflow
  1. Choose sign-inUse /login for regular sign-in or /sso/login for configured SSO and passwordless options.
  2. Select tenantChoose the application-owning tenant and confirm the user's active membership there.
  3. Register applicationSet its owner, protocol and provider values using the management interface.
  4. Test accessCheck identity, tenant membership, role and policy with a permitted account.
  5. Maintain accessMonitor audit events; disable retired connections and revoke stale credentials.

Sign-in URLs and recovery

Use /login for the regular site account flow and /sso/login for SSO-aware sign-in. Registration, recovery and passwordless flows are under /sso. Old OAuth authorisation pages redirect in-flight users to current SSO equivalents. A URL does not prove a provider is enabled; check tenant and application state.

  1. Open the URL for the intended sign-in flow.
  2. If a provider is absent, ask its tenant administrator to check configuration.
  3. Use SSO recovery prompts for lost factors or expired passwords.

Tenants, domains and identity

A tenant owns its applications, domains, members, policies and delegations. Verified-domain discovery routes a person but does not authenticate or grant membership. Customer administrators configure organisation SAML or OIDC. Resolve identities by tenant, issuer and immutable subject; never link accounts on email alone.

  1. Select the tenant before changing a member, provider or domain.
  2. Complete the displayed domain ownership check and confirm verified state.
  3. Resolve duplicate identities through the authorised tenant workflow.

Applications and social providers

Applications have separate protocol registration, policy and lifecycle. Platform social-provider settings differ from a user's linked identity. A callback may require profile completion, but a working callback does not grant application access: membership, assignment and policy also apply.

  1. Record tenant, owner, protocol and registered redirect or metadata values.
  2. Configure the provider in its management screen; protect its credentials.
  3. Test sign-in and confirm the tenant and application decision.

Roles and delegation

Site roles and tenant permissions are separate. Governance can set parent organisations, limits and expiring administrator delegations. Delegates receive selected permissions in one tenant; higher, sibling and unrelated scopes are denied. Active membership, role hierarchy and application policy all matter.

  1. Give the administrator active membership in the target tenant.
  2. Grant only required permissions and set an expiry.
  3. Revoke the delegation when work ends; check its audit entry.

MFA, passkeys and recovery

Sign-in may require MFA, passkey or other passwordless verification, or stronger step-up. Bootstrap, challenge, setup and recovery are distinct stages; completing one does not satisfy a later protected action. Administrators need authentication-management authority for supported tenant authenticators and enrollment campaigns.

  1. Complete passkey sign-in or verify a new authenticator during enrollment.
  2. Recover with an offered method, then replace compromised factors.
  3. For denial, note its reason and ask an authorised admin to inspect policy.

Management and lifecycle

The generated management contract is at /api/auth/management/openapi.json. It lists operation schemas and security requirements. Use the protected workspace for human administration. Tenant and application activation, suspension, retirement and rollback are recorded lifecycle changes with version and audit history.

  1. Open the OpenAPI document and locate the required management operation.
  2. Check its permission, tenant context and documented inputs.
  3. After a lifecycle change, confirm state and audit history.

Frequently asked questions

Which sign-in URL should I use?

Use /login for regular sign-in and /sso/login for SSO-aware sign-in.

Does domain discovery grant access?

No. Authentication, membership, application assignment and policy checks still apply.

Can email link an identity automatically?

No. Linking uses tenant, issuer and subject; resolve conflicts through authorised review.

Why can I sign in but not open an app?

Sign-in is not an assignment. Check membership, role hierarchy and application policy.

Where is the management contract?

Read /api/auth/management/openapi.json for current operations and security requirements.

Can delegates manage every tenant?

No. Delegations are limited to their tenant, selected permissions and expiry.

Related pages