Executive Summary
of active development
AI-orchestrated
of code, Java and TypeScript
automated, incl. ~420 integration
public API, documented in OpenAPI
CI/CD to Kubernetes
The Project
Identix is a self-hosted identity provider. A company installs it in its own infrastructure, and a single installation serves many independent applications (tenants), each with its own users, roles, sign-in settings and signing keys. Passwords, keys and personal data never leave the operator’s infrastructure.
Identity is the most security-sensitive part of any system: a mistake here exposes every application behind it. The project therefore had to combine broad functionality with a security architecture that holds up to scrutiny. It was designed and built, and is maintained, by one engineer.
What Was Built
Authorization server — OAuth 2.0 and OpenID Connect on Spring Authorization Server, with a separate issuer and signing keys for every tenant, refresh-token rotation and instant token revocation.
- Strict multi-tenancy — every request is confined to its tenant, and automated architecture tests enforce the rule
- Users, roles, groups and organizations, with bulk import and export and a password policy per tenant
- Two-factor authentication (TOTP) with recovery codes
- Audited impersonation — an administrator can act on behalf of a user, and every such session is recorded
- Webhooks signed with HMAC for user lifecycle events
- Audit log — append-only and per tenant, with a cross-tenant view for the operator
- Export and import of tenant configuration between installations
Admin console — React and TypeScript, in English and Russian, adapting from desktop to phone, with a built-in developer hub: integration guides and interactive API documentation.
Public API — 237 operations, fully described in OpenAPI.
Infrastructure — three services on Kubernetes with Helm charts, PostgreSQL and Redis, and three GitLab CI/CD pipelines that build, test and deploy each service. A deployment is blocked if any test fails.
Security by Design
The architecture separates trust zones. The public authorization server has no access to the database and holds no private keys: all data and all token signing live in an internal service reachable only inside the cluster. Signing keys are stored encrypted and decrypted only in memory, so compromising the public node exposes neither keys nor data.
Security work was part of the method, not an afterthought:
- Threat model built with STRIDE: protected assets, attacker profiles, trust boundaries and a countermeasure for every threat
- Security documentation for auditors, with controls mapped to OWASP ASVS Level 2 and the IETF best practices for OAuth 2.0 and JWT
- Security audit completed successfully; all findings were remediated
The Method
One engineer acting as architect and AI orchestrator, working by Specification-Driven Development. The work began with a written specification (requirements, data model, security invariants), and every significant decision was recorded as an architecture decision record before implementation.
AI agents generated code, tests and documentation from that specification; the engineer reviewed every change, owned the architecture and the security model, and was accountable for every commit. The infrastructure (Kubernetes manifests, Helm charts, CI/CD pipelines) was built by the same person in the same way.
Development was not continuous: the project advanced in stages with breaks between them. Counting only the days on which work was actually done, the platform took 40 working days.
Tech Stack
Comparison with Traditional Development
| Typical traditional team (estimate) | This project (AI-driven) | |
|---|---|---|
| Timeline | 6–9 months | 40 working days |
| Team | 4–6 engineers | 1 engineer |
| Infrastructure and CI/CD | Separate DevOps engineer | Included, same engineer |
| Security | Threat model and audit often postponed | STRIDE threat model, audit completed |
| Documentation | Written after the fact, if at all | Specification and ADRs from day one |
| Automated tests | Varies | ~1,700 |
Conclusions
Identity and access management is not an obvious showcase for fast delivery: it combines a large feature set with uncompromising security requirements. Identix shows that the method holds here too.
One engineer. 40 working days. A multi-tenant authorization server, an admin console, a public API of 237 operations, about 1,700 automated tests, Kubernetes and CI/CD, and a security architecture backed by a threat model and a completed audit.
The decisive factor was not the speed of code generation but the discipline around it: the specification first, decisions recorded, every change reviewed. That is what makes the system maintainable, and what would let another team take it over.