DEV Community: Lukasz Tarczyluk

Getting Out of the Password Business

Lukasz Tarczyluk — Sat, 18 Jul 2026 09:46:04 +0000

Our old authentication system logged users in with the OAuth2 client_credentials grant.

If you know OAuth, you just winced. client_credentials exists so that a client application can obtain a token for itself, rather than on behalf of a user. It has no concept of a human being at all. But it takes two values, an ID and a secret, and if you squint, an email address and a password are also two values.

So that's what it did. Each user effectively became an OAuth client: client_id was their email address, and the registered client secret was their BCrypt password hash. The browser sent an HTTP Basic header, the server matched the credentials against that per-user registered client, and out came a token.

It worked for years. That is the recurring theme of this post.

What we actually had

The platform is a multi-tenant billing system that ingests orders and payments from e-commerce marketplaces and produces accounting documents. Authentication was entirely in-house: a Spring Authorization Server configuration of about 380 lines, issuing and signing its own tokens. Access tokens lived 24 hours, refresh tokens 48.

Issued tokens went into an oauth2_authorization table, with a startup job that deleted rows older than a couple of days. Other services didn't parse tokens at all — they called back to the auth service to introspect each one as an opaque string. The oldest component in the system sat on the hot path of every authenticated request in every other service.

Password hashes lived in a password column on the user table, and registration hashed into it directly.

None of this was incompetent. It was written when the platform was a single application, and it kept working while the platform stopped being one. The failure mode of home-grown auth is rarely a dramatic breach; it's that the thing quietly becomes load-bearing infrastructure that nobody signed up to own.

Three forces finally moved it: security standards set by our parent company across the group, enterprise customers asking to sign in with their existing Google Workspace and Microsoft Entra ID accounts, and the accumulated cost of maintaining a bespoke identity stack.

The cut-over

We moved to Google Identity Platform, primarily because our infrastructure already runs on Google Cloud — identity became native rather than another integration, with one tenant per environment.

Verification ended up taking two forms, which I'd call a mild inconsistency rather than a mistake. The auth service verifies ID tokens through the Firebase Admin SDK in a servlet filter. Every other service uses the stock Spring resource server pointed at the provider's JWKS endpoint, so token validation there is ordinary configuration rather than code we maintain. Domain-specific facts — the selected organisation, the user's internal identifier, whether the caller is a service account — ride along as custom claims minted per token.

Now the part I'd flag to anyone planning this: we cut over in a single day. Five backend repositories and the frontend all merged on the same date. There was no dual-auth period, no compatibility endpoint that let old tokens be exchanged for new ones, and no feature flag to route a percentage of traffic. The frontend switched by pointing its login route at a new screen and leaving the old one unrouted.

That was deliberate, and I'd defend it. The obvious alternative is a transition period where every service accepts both the old tokens and the new ones. But that doubles the authentication surface you have to reason about and test, and interim compatibility layers have a habit of outliving their purpose — six months later you still have two ways to authenticate and nobody wants to be the one who deletes the old path. With a single team and a fixed set of clients we controlled, one coordinated release with everybody present and watching struck me as the lower risk.

The commit history immediately afterwards shows what that costs, honestly: a week of small fires — configuration corrections, test fixtures to repair, a handful of things that only surface once real traffic arrives. That's the trade. You concentrate the pain into a window where the whole team is paying attention, instead of spreading it across a quarter where they aren't.

The most instructive failure arrived within the hour, and it wasn't in any of the code we'd just rewritten.

Five thousand accounts, zero password resets

One constraint was non-negotiable: nobody gets a "please reset your password" email. That email, sent without a breach behind it, spends trust you can't easily earn back.

The provider supports importing users along with their existing hashes, if you tell it the hash algorithm and parameters. So the migration exporter read the existing users, imported them in batches of a thousand with BCrypt declared as the hash scheme, and wrote the resulting provider identifiers back onto our own user rows.

The hashes moved across intact. Everyone's existing password kept working the next morning, verified by the provider instead of by us. Nobody had to do anything and, which was the whole point, users simply carried on.

That's the real end state. We are not in the business of storing credentials anymore. Our application does not verify a password, does not compare a hash, and would have nothing useful to leak on that front if the database were compromised tomorrow.

What surprised me was how much arrived with it. Multi-factor authentication was the obvious one: TOTP, the familiar QR-code flow used by Google Authenticator and its equivalents. Enrolment, verification, recovery codes and the enforcement rules around them are weeks of careful work to build and a permanent obligation to maintain. We had never built it, and — being honest about our priorities — probably never would have. It came as configuration, as did federated sign-in for the identity providers our customers actually use. And the same foundation is what makes the passwordless work we're doing now — passkeys — tractable at all.

That's the underrated part of delegating identity. It isn't only that you stop carrying a liability. It's that a whole category of security work stops being a project you have to justify and becomes a feature you switch on.

The account that wasn't there

Scheduled jobs — billing runs, marketplace imports — authenticate as a technical user rather than as a person. Under the old system that was a real row in the database with a token persisted alongside it, updated by hand when it expired. Under the new one it's a service-account identity that mints and exchanges its own short-lived token.

On release night, every machine-to-machine call started returning 401.

The cause was not in the code. The technical user simply did not exist in the production database. It existed in development, where we'd built and tested everything, and had never been created in production. Human logins worked fine, because humans were covered by the account import. The one identity that wasn't a real person had fallen outside it.

We caught it the same evening and fixed it, because the entire team was watching a release we knew was high-stakes. That is the argument for concentrating a migration into one window: the failure surfaced while everyone was still at their desks, rather than at 3am on a Tuesday three weeks later when nobody was.

The lesson I took isn't about tokens at all. When you migrate identity, you naturally think about users — the people with passwords, the ones who will notice and complain. Service accounts have none of those properties. Nobody advocates for them, they don't file support tickets, and they fall outside the mental model you're using when you plan the work. They're also the accounts that run everything important while you're asleep.

Environment parity gets discussed as a configuration problem — same versions, same flags, same infrastructure. This was parity of data: an identity that existed in one environment and not the other, in a system whose entire job is deciding who exists.

What we quietly lost

Migrations remove things, and it's worth being honest about which.

The old system locked an account after three failed logins and emailed the user when a login arrived from an unusual location. Both were custom, both had been written by someone who cared, and both went away with the code that contained them. The provider brings its own protections against credential stuffing, so the net security position improved — but those specific behaviours weren't reimplemented, and nobody made an explicit decision to drop them. They simply weren't in scope, which is how features die.

We also left ourselves some scaffolding. Migration code tends to arrive with a comment promising it will be deleted afterwards, and "afterwards" is not a date. Cleanup work that has no deadline doesn't get one, and the only reliable fix I know is to put the removal in the plan as a task with an owner, before the migration ships and everyone's attention moves on.

The passkey work mentioned above is in progress — written and working on a branch, not yet merged.

What I'd take from it

Home-grown authentication doesn't fail loudly, it just accumulates. Ours cost us SSO deals and put a decade-old component on the hot path of every request. The bill arrives in instalments.
A big-bang cut-over is a legitimate choice, not a failure of nerve. Dual-authentication periods double the surface you have to test and tend to become permanent. Concentrating the risk into one window, with the whole team watching, can be the safer option — provided you actually watch.
Service accounts fall through the gaps in an identity migration. You plan around users, because users are the ones who notice. The accounts that run your overnight work have nobody to speak for them and are absent from every checklist you write.
Environment parity includes data, not just configuration. Same versions and same flags mean nothing if an identity exists in one environment and not the other.
Write down what you're dropping. Account lockout and location alerts were real features that disappeared without anyone explicitly deciding they should. Removal by omission is the easiest kind to miss.
Delegating identity buys more than it removes. Losing the credential liability was the goal; getting MFA and federated sign-in as configuration, and a solid foundation to build passwordless on, turned out to be worth more.
For most applications, storing credentials has become an optional responsibility rather than a necessity. It's still the right call for some. It just isn't the default any more, and it's worth asking whether you're holding it on purpose.

The best outcome isn't the SSO integration customers asked for. It's that "how do you store passwords?" now has a very short answer: we don't.

When You Inherit Software That Can No Longer Be Built

Lukasz Tarczyluk — Sat, 18 Jul 2026 08:26:26 +0000

There is a particular kind of silence that falls over a room when you ask a simple question and nobody can answer it.

The question was: how do we build this?

The system in front of us was a set of pricing applications at a large European bank — the components that answer "what is this instrument worth today" for the front office. They consumed live market data from Reuters feeds, applied the bank's own valuation logic, and served the result to booking and settlement systems downstream. They had been running for over a decade and, by every operational measure, were working fine — restarted once a week, otherwise left alone.

And nobody could build them.

The developers who had written them had left the organisation years earlier. What remained was a deployed artefact — one image, built at some point in the past by someone who understood how all the pieces fitted together, running unchanged ever since. The source code existed. The build did not. No one still employed knew how to assemble a deployable package from that source together with its full set of dependent technologies.

If you have never encountered this, it sounds like negligence. It isn't. It's entropy. It happens slowly, to well-run organisations, and by the time anyone notices, the people who could have explained it are three jobs away.

What "unbuildable" actually costs

A frozen system that works is easy to rationalise. It works. Leave it alone.

The cost is invisible until you need something.

A defect appears. You cannot fix it — you can only work around it in the systems downstream. A dependency turns out to have a published vulnerability. You cannot upgrade it; you compensate at the network layer and write a risk acceptance instead. A regulation changes, and this is finance, so regulations change. You cannot implement the change where it belongs.

And underneath all of it the runtime itself is ageing out. The Java version eventually loses support, and with it your ability to run on infrastructure anyone is willing to maintain.

Every one of these turns into a workaround somewhere else, and each workaround makes the next change harder. The frozen component quietly exports its rigidity to everything around it.

So the first deliverable of the project was not a feature. It was the recovery of the ability to change the software at all.

The archaeology phase

Before proposing a target, we had to understand what was actually there.

Archaeology is the right word, because there was nothing else to go on. No internal documentation had been left behind — no architecture notes, no runbook, nothing explaining why any of it was shaped the way it was.

External help was thin too. Oracle's OCEP was never widely adopted; the vendor documentation is sparse and the community around it is small enough that searching an error message often returns nothing at all.

The product did ship a visual editor that rendered the event-processing flows — the one artefact that would have explained the transformations at a glance. It ran in a browser, and it required Flash, which had been end-of-life for years. On a bank-issued machine you install nothing that isn't on the security-approved software list, and an obsolete browser plugin was never going to be on it. The tool that would have explained the system existed, and was unreachable.

So I read the XML instead. Line by line, file by file, reconstructing what each transformation did and how the stages fed one another, until the shape of the system existed somewhere other than inside a program nobody could run anymore.

That is the unglamorous centre of most legacy work. Not clever refactoring — patiently rebuilding an understanding that was never written down in the first place.

Two things dominated the architecture that emerged from this:

OSGi, inside the applications. Each pricing application was built as an OSGi bundle system — decomposed into modules with dynamic loading, versioned interfaces, and a service registry.

A separate event-processing server, outside them. For event handling, the applications published events to a dedicated Oracle Complex Event Processing (OCEP) server that ran alongside them, with its rules and streams configured outside the application code.

Both are legitimate technologies, chosen by capable people for real reasons. In this system, though, both had become expensive — in operational complexity, in the amount of context a developer must hold before making a safe change, and in the number of ways a deployment can fail.

The question I kept asking was not "how do we migrate this" but "what requirement made this necessary?"

For OSGi: the promise is hot-swapping modules at runtime without restarting the process, and running multiple versions of a dependency side by side. Did these applications need that? They went down on a schedule every week regardless, and nobody had hot-deployed a bundle in years. The dynamic module model was carrying no weight.

For OCEP: the promise is high-throughput stream processing with complex temporal rule matching over continuous event streams. What was it actually doing? Routing a modest volume of events between the applications — work that belongs in a few lines of in-process code, not in a dedicated server standing alongside them.

This is the uncomfortable finding that a legacy migration often surfaces: the complexity is not load-bearing. It was a reasonable bet by capable engineers under different assumptions, and those assumptions stopped being true years ago. Nobody re-examined it, because the system worked, and because re-examining it required exactly the build capability that had been lost.

Choosing boring on purpose

The target architecture was deliberately unambitious: rebuild each application as an ordinary Spring Boot service on a current Java LTS — dropping the OSGi bundle model inside it, and replacing the external OCEP server it published to with plain in-process publish/subscribe (Guava's EventBus, at the time), which covered the entire real requirement in a fraction of the surface area.

This is the part that tends to attract argument, because the industry reflex runs the other way — towards shared platforms and extracted infrastructure. But nothing here was being shared to any purpose: both pieces were an entire extra tier to run, secure, patch and understand, in exchange for capability the applications did not use. Taking it away and letting each stand on its own removed cost, not capability.

The decisive criterion, though, was the one we started with: any Java developer must be able to build and release this. That single requirement eliminated every option that preserved the old packaging. A conventional Maven build producing a conventional Spring Boot artefact is not an interesting technical choice. It is an interesting organisational one, because it means the system's future no longer depends on knowledge held by specific people.

Boring technology is legible technology. Legible technology survives staff turnover.

The constraint that shaped everything: don't move the contract

While this was underway, the bank went through a corporate integration and several internal upstream systems were replaced with the acquirer's equivalents. The market data feed itself was unaffected — what changed was the systems sitting behind it. New connectors were needed.

And here was the hard constraint: a substantial number of legacy systems consumed these applications, some against older versions, and they had to keep receiving byte-for-byte identical responses. We were changing what was behind the interface. We were not permitted to change the interface — not the shape, not the field ordering, not the numeric formatting, not the rounding.

That last one matters more than it sounds. Financial output is full of details that a rewrite quietly "improves": a trailing zero, a scale on a decimal, a null rendered as an empty string. Every one of those is a production incident in a downstream system you have never heard of.

The approach was straightforward but disciplined:

Map the new sources back onto the existing response model rather than designing a better one.
Capture real production responses from the running system as a reference corpus.
Verify equivalence of the new implementation against that corpus before cut-over — not "looks right", but identical output for identical input.

Recorded production traffic is the only honest specification a legacy system has. The documentation describes intent. The code describes mechanism. Only the observed output describes what downstream consumers actually depend on — including the behaviours nobody meant to promise.

Closing the loop

The last piece was the one that made the rest durable: a CI/CD pipeline that builds from source, runs the tests, and promotes through environments onto a container platform. Ordinary, in other words — which was the whole point.

The before-and-after is the clearest measure of the project.

Before: an artefact nobody could rebuild, left untouched for years, with every change request answered by a workaround somewhere else.

After: any Java developer on the team can build and release a new version in minutes.

No latency numbers, no throughput graphs. The system priced instruments the same way on the last day as on the first. What changed is that it became possible to change it — and that turned out to be the capability the organisation had actually lost.

What I'd take from it

"It works" is not the same as "it's fine." A system you cannot rebuild is a system with an expiry date; you just don't know the date.
Ask what requirement justified the complexity. Often the requirement is gone and only the complexity remains. Sophisticated technology chosen for reasons that no longer apply is just cost.
Optimise for who can operate it, not for elegance. If only one person can build it, you don't have software — you have a dependency on that person.
Recorded output is the real contract. Not the docs, not the schema. Behaviour that consumers depend on is behaviour you promised, whether you meant to or not.
Restoring changeability is legitimate work. It doesn't demo well and it has no user-visible feature attached, but nothing else you want to do is possible until it's done.

The most valuable thing we delivered was not a rewrite. It was ending the silence that follows how do we build this?