Skip to content
ArchXS

Practice

Cybersecurity and digital identity

Security rarely fails for lack of tools, more often for lack of boundaries nobody drew. We design identity and access control as part of the system architecture, not as a layer added at the end.

Cybersecurity and digital identity
Fig. 01Trust boundaries drawn deliberately: isolation enforced in the database, an audit trail that cannot be overwritten, and a server that takes nothing on trust.

How we look at it

Whether you have authentication matters less than where the trust boundary runs and what happens when the client is untrusted. The systems we design assume everything on the user's side can be forged, so the server replays and validates operations with its own engine instead of taking results on trust. The same logic covers the model provider: personal data is redacted before it leaves the organisation. And it covers us: a control the database or the pipeline does not enforce is merely a good intention.

What we have built

We wrote our own SPI extensions for Keycloak 26, an authenticator and credential provider for sign-in by cryptographic signature under EIP-191, with a single-use, time-limited nonce against replay attacks, OTP as a second factor and passkeys on webauthn4j; a second, independent system runs its own SPI, so this is a working method, not a one-off. In mobile apps: Authorization Code with PKCE S256 and the platform key store. In multi-tenant systems the database enforces isolation, row-level security plus attribute-based control per tenant, and the audit trail is a SHA-256 hash chain in an append-only table with a trigger that blocks updates and deletes; that pattern runs in three of our systems. Every upload passes a fail-closed antivirus scan and a MIME whitelist. In CI: dependency scanning, static analysis, a CycloneDX SBOM and artifact signing. In a public game arena the server replays every ranked game with its own engine and rejects illegal moves and impossible times, and the fact that the user's API key never leaves the browser is enforced by a test. Boundaries are sometimes physical too: one product runs a dedicated identity-server instance on an isolated network, so two systems cannot see each other's resources even after a configuration mistake.

What follows

Access control returns from being scattered through application code to places that can be audited: the identity provider, the database, the pipeline. Changing a security policy becomes a configuration change, not a sweep through a dozen repositories. And when the auditor asks for the trail, it exists, and it could not have been fixed up after the fact.