Prompt 06 — Authentication, invitation onboarding, and account security

Required context

• Approved authentication/encryption ADRs
• Current sign-in, invite, key import, and account screens
• Product shell and shared form components
• Security/privacy rules and threat model

Prompt

Replace the prototype sign-in and key-management experience with a production-grade, tenant-aware onboarding and account-security flow while preserving actual encryption guarantees.

1. Separate production and development access

• Remove bearer-token entry from production UI.
• Keep any local token login behind an explicit development-only environment gate, with tests that it is absent from production builds.
• Do not accept arbitrary tenant slugs from unauthenticated users unless the tenant-discovery design explicitly requires it.

2. Invitation flow

Implement:

1. Validate secure invite token and state.
2. Show tenant name, inviter/purpose where safe, role/request type, expiry, and privacy notice.
3. Authenticate through allowed methods.
4. Confirm profile and tenant membership.
5. Register device/recovery material according to the approved encryption mode.
6. Confirm access and route to the intended task.

Handle expired, revoked, already-used, wrong-account, wrong-domain, tenant-suspended, and network/error states without leaking tenant membership.

3. Authentication options

Implement only approved providers and plan gates. Support a coherent order such as:

• Enterprise SSO/OIDC/SAML when configured
• Microsoft/Google OAuth when allowed
• Passwordless or passkey where approved
• Break-glass account policy for tenant security admins

Do not present unavailable buttons.

4. Key/recovery UX

Translate system behavior into plain language:

• Device access status
• Backup/recovery health
• Add a device
• Restore access
• Rotate security material
• Reauthorize after rotation

If subject-private mode can lead to permanent loss, explain it clearly before completion and provide a verifiable backup check. If tenant recovery exists, show who may initiate it, the approval/audit process, and notification behavior.

Do not display or log key material. Do not upload a key file before identity is validated unless the approved threat model explicitly requires it.

5. Account and security center

Build pages for:

• Profile
• Connected sign-in methods
• MFA/passkeys if supported
• Active sessions and devices
• Recovery/backup status
• Security activity
• Notifications preferences
• Privacy/data export/delete requests according to policy
• Sign out everywhere

Use confirmation and reauthentication for sensitive actions.

6. Enterprise tenant configuration

Provide admin flows for:

• Verified domains
• SSO setup and test mode
• Enforcement policy and staged rollout
• SCIM relationship where available
• Session timeout
• MFA policy
• Break-glass accounts
• Invite expiry and domain restrictions
• Authentication audit events

A failed SSO configuration must not lock out all administrators.

7. Security and tests

• CSRF/session fixation/open-redirect protections appropriate to the stack
• Secure return URL allowlist
• Token expiry, replay, revocation, and one-time semantics
• Rate limiting and abuse controls
• Tenant isolation on invitation resolution
• No secrets in client bundles, logs, analytics, or error messages
• End-to-end tests for invite, SSO fallback/test, recovery, and access denial
• Accessibility tests for all auth states

Acceptance gates

• Production login contains no bearer-token path.
• Invitees land on the intended task with tenant context.
• Lost/recovery behavior matches the approved ADR and docs.
• Sensitive actions require appropriate reauthentication.
• Error states do not reveal hidden tenant or account information.