Project / Baseline

Standalone baseline roadmap.

The dependency-ordered product contract ComplicatedAuth must satisfy before any integration-specific adapter is built.

Boundary: this roadmap is intentionally integration-neutral. Core tables and APIs model ComplicatedAuth resources. A future connector may translate an external contract into these resources, but it must not redefine them.

What “baseline” means

The baseline is a coherent service a customer can adopt on its own: customer accounts, strong authentication, delegated authorization, durable credentials, support intake, auditability, and predictable operations. A generated client or connector is not evidence that these platform behaviors exist.

Work proceeds in dependency order. Public endpoints are added only when their persistence, authorization, idempotency, concurrency, error, and operational semantics are implementable and documented.

Current delivery map

Phase 01In progress

Platform and database safety

Delivered and verified

Serialized, checksum-verified, append-only schema migrations
Database-backed idempotency claims, processing leases, request-hash conflicts, exact HTTP response replay, and bounded cleanup
Durable background jobs with deduplication, SKIP LOCKED claims, recoverable leases, bounded exponential retry with jitter, dead-lettering, and retention-worker acceptance
Payload-free job inspection and audited dead-letter replay through an operator-only database CLI
A deduplicated recurring maintenance job with bounded cleanup for expired authentication, OAuth, idempotency, rate-limit, invitation, email, session, and completed-job records
Shared, expiring login throttles with per-surface policies, keyed identifiers, capped counters, and fail-closed dependency behavior
Versioned AES-256-GCM data-encryption keyring with authenticated resource context, active-key writes, and retained old-key decryption

Remaining acceptance

Stable public origins, backup/restore drills, and multi-replica release tests

Phase 02Delivered

Customer identity and Tenant membership

Delivered and verified

Owner signup, bootstrap and strong HTTP-only console sessions, and Tenant isolation
Owner, admin, developer, support, and viewer roles enforced by API middleware
Idempotent one-time-token invitations, member listing and administration, final-owner protection, and member removal
Session inventory and per-session revocation, including current-cookie clearing
Console member, invitation, acceptance, and account-session surfaces
Non-enumerating Tenant Member email verification and password recovery with hashed one-time proofs, encrypted delivery payloads, shared throttles, asynchronous SMTP, and revocation of sessions and OAuth artifacts
Invitation email delivery that keeps acceptance proofs hidden from Tenant administrators
Non-enumerating five-minute login attempts whose one-time client secrets stay in browser memory and whose password verification never creates a session
Required user-verified Tenant Member passkeys or directly attested security keys, first-credential bootstrap, bounded credential inventory, strong-ETag rename/removal, and multi-authenticator browser acceptance
Lost-authenticator recovery that removes all management WebAuthn credentials and requires fresh enrollment after email proof and password reset

Phase 03In progress

OAuth and OpenID Connect

Delivered and verified

Tenant-owned public and confidential OAuth Applications with opaque client IDs, exact redirects, ETag concurrency, tombstoned deletion, and role enforcement
Idempotent expiring confidential-client secret resources with one-time return, exact replay, overlap limits, last-used metadata, and revocation
Configured issuer discovery, encrypted durable RSA signing keys, automatic bounded rotation, and active/retiring JWKS publication
Authorization code with mandatory S256 PKCE, state, nonce, explicit consent, pairwise subjects, five-minute one-time codes, RS256 ID and UserInfo-bound access tokens
OAuth-standard token errors, confidential/public client authentication, UserInfo revocation checks, RFC-style token revocation, and self-service consent revocation
Console registration, credential, consent, account-grant, and one-time-secret surfaces plus PostgreSQL protocol acceptance
RFC-style Resource Server indicators and short-lived access tokens bound to either UserInfo or one exact delegated API audience

Remaining acceptance

Refresh-token rotation only if a concrete offline-access use case justifies its additional theft and replay surface
Formal conformance testing, clock-skew policy, signing-key operator workflow, and production issuer verification

Phase 04Delivered

Authorization and delegated APIs

Delivered and verified

Tenant-owned Resource Servers with immutable exact audience identifiers, ETag concurrency, tombstoned deletion, status lifecycle, and monotonic policy versions
Immutable delegated scope tokens with mutable consent labels, descriptions, status lifecycle, idempotent creation, and affected-token revocation
Explicit versioned OAuth Application-to-Resource Server grants whose scope set administratively bounds user consent
Resource-indicator validation at authorization, consent, and code exchange plus resource-bound JWT access tokens rejected by UserInfo
A stable token-derived principal + Tenant + resource + operation + bounded context decision model with capabilities, scope-v1 policy version, validity, and machine-readable denial reasons
Console Resource Server, scope, client-grant, delegated-consent, account-grant, and lifecycle surfaces plus PostgreSQL and browser acceptance

Phase 05Delivered

Credential lifecycle

Delivered and verified

Stable Project service accounts with exact least-privilege scopes, human metadata, status lifecycle, strong ETags, and workload audit attribution
Nested expiring credential versions with environment-specific prefixes, keyed hashes, one-time secret return, fingerprints, creator, expiry, last use, and revocation reasons
Idempotent account and credential creation with exact 24-hour response replay, changed-request conflicts, and independently idempotent credential revocation
Deploy-observe-revoke rotation with a maximum two-active-version overlap; no destructive rotate RPC and no secret in ordinary reads
Immediate credential, account, Project, scope, and exact Project-path enforcement plus bounded account inventory and cursor-paginated credential history
Console management, generated contracts, SDK and example configuration, PostgreSQL acceptance, browser acceptance, and operator documentation

Phase 06In progress

Support cases and feedback

Delivered and verified

Tenant-owned Support Cases, messages, constrained attachments, generic external references, and immutable case events
Bug, feedback, and question categories with reporter, exact Project isolation, diagnostic consent, ETag-protected lifecycle, assignment, and priority
Tenant-wide operator inbox plus scoped customer-backend access with explicit public and internal correspondence boundaries
Versioned field encryption, idempotent mutations, audit-safe metadata, retention deadlines, generated contracts, console workflow, and PostgreSQL/browser acceptance
Deduplicated retention jobs with multi-replica-safe leases, bounded retry, stale-job cancellation after reopen, transactional purge, and content-free system audit

Remaining acceptance

Define production attachment malware scanning or quarantine before operators open customer files

Phase 07In progress

Production contract and documentation

Delivered and verified

Canonical OpenAPI contract, generated Go and TypeScript types, independently deployable API-reference snapshot, and drift checks
Architecture, security, integration, operations, production, release, and implementation-status documentation
Tenant Member assurance, authenticator lifecycle, account-recovery, maintenance retention, and dead-letter replay operator documentation

Remaining acceptance

Production HTTPS origins, metrics and alerting, release compatibility gates, and staging end-to-end verification

Migration contract

Every deployed *.up.sql file is immutable. Startup obtains one PostgreSQL advisory lock across replicas, verifies every applied filename and SHA-256 checksum, and fails if history was changed or removed. Older filename-only records are sealed once using the bytes in the first checksum-aware release. Schema evolution always uses a new six-digit migration.

Idempotency contract

The internal store scopes a key to an authenticated principal and named operation. The first attempt owns a bounded processing lease. Concurrent identical attempts receive a retry interval; a different request hash conflicts; a completed attempt replays the stored HTTP status, headers, and body exactly. An expired retention record may be reused. A stale worker cannot overwrite the result after its lease is superseded.

This capability is not automatically promised by every mutation. An endpoint supports retries with Idempotency-Key only after that parameter, canonical request hash, retention window, conflict behavior, and replay semantics appear in OpenAPI.

Baseline release acceptance

A customer can sign up, verify ownership, recover access, invite members, assign roles, and strongly authenticate.
An administrator can register a generic OAuth Application and complete authorization code with PKCE.
Access tokens cannot cross Tenant or resource boundaries, and a viewer is denied mutating operations.
A workload can issue, overlap-rotate, observe, and revoke a scoped expiring credential without duplicate results on retry.
A customer can create a Support Case and an operator can process it through an audited lifecycle.
Retries, concurrency, restarts, multiple replicas, key rotation, retention, backup, restore, OpenAPI drift, and documentation links are verified release gates.