Domain expertise
A product suite where every application carried its own authentication — duplicate accounts, inconsistent mechanisms, no central policy enforcement and limited auditability.
01Context
Authentication accretes quietly. Each new application ships with its own login because that is the fastest path, and the cost arrives years later: users hold several accounts, "role" means something different in each system, security policy cannot be enforced anywhere, and no one can answer an audit question without checking four databases.
02What was going wrong
03Approach
Design identity as shared infrastructure rather than a per-application concern. Standards research first, then architecture: tenant-aware, with roles and permissions modelled as data so a policy change is configuration rather than a release, and audit logging capable of answering who did what and when.
Fine-grained permissions modelled in the schema. Changing what a role can do does not require shipping a new build.
JWT with refresh tokens, with expiry, rotation and revocation designed deliberately — the details that decide whether a compromise is contained.
Drawing the line between what belongs to the identity platform and what belongs to each application was the hardest design problem, and the one that determines whether the platform is adopted or worked around.
04What was built
05Outcome
Stated as architectural objectives and current progress, not measured business outcomes: consistent cross-product authentication, simplified user management, improved auditability, standardised authorisation, and a foundation that new applications can adopt rather than reinvent.
An ongoing internal initiative at a prior employer, presented as domain expertise. It is not a completed commercial product and no business outcome is claimed for it.
We will walk through the architecture, the constraints and the parts that went wrong — on a call, without a deck.