Session handling rework on a customer portal

The portal had accumulated three generations of session handling: an old cookie-based session, a token issued for the mobile app, and a third mechanism added for a partner integration. They did not share a notion of what a session was, so signing out invalidated one of them, sessions could outlive a password change, and support had no way to end a session on a device a customer had lost. A penetration test raised two findings in this area and a customer complaint raised a third, which is what got it funded — it had been a known problem for two years before it was a funded problem.

Backend engineer, and the person who wrote the design, on a team of five for around six months. I worked with the mobile lead and a partner-integrations engineer because the changes landed in three codebases at once, and with a product owner whose main concern, reasonably, was that nobody should be logged out unexpectedly. I ran the weekly working session where the three of us agreed what would ship together, which was more of the job than the code was.

I owned the session service: one record of a session with a device, an issue time and a reason for ending, plus the rules for what invalidates what. I wrote the migration path that let the three old mechanisms keep working while being progressively backed by the new store, and the shim that made the partner integration's tokens look like sessions without the partner changing anything. I built the support tool that lists a customer's active sessions and ends one, which was the feature the support team had been asking for. I did not do the mobile client work or the partner-side coordination.

The main call was to make sessions server-side records rather than move to self-contained tokens, which was the fashionable answer and was proposed in the first design meeting. Self-contained tokens make revocation hard, and revocation was the entire reason the work existed — I would have been building a revocation list to work around the property I had just chosen. The cost is a lookup per request, which we measured and cached and which turned out to be irrelevant next to everything else the request does. I also decided that a password change ends every session except the one performing it, which sounds obvious and had not been true.

The rule from the product owner was that no existing customer could be signed out by the migration, which ruled out any approach that invalidated old sessions on cutover and made the shim necessary. The partner integration had a contractual notice period for interface changes, so anything visible to them was off the table for the duration. We released behind a flag, ramping by cohort over five weeks, and we did roll back once at ten per cent when an edge case around a long-lived mobile refresh flow logged out about four hundred people. That was a bad afternoon and the reason the ramp after it was slower.

Both penetration-test findings closed at retest. Sign-out now ends every session for that customer across every surface, which is the plain-language outcome I would give a non-technical person. Support gained the ability to end a session on a lost device, used a few dozen times a month, which they had previously handled by forcing a password reset. Median session-lookup overhead came out at about two milliseconds, well inside the budget we agreed up front. The four hundred people we logged out during the ramp were, in the end, the price of finding that case before we did it to everyone.

The mobile lead found two assumptions in my design that only break on a device that has been offline for weeks, which is a normal state for a phone and not one I had modelled. The partner-integrations engineer built the shim's contract test suite. The support team lead specified the session-ending tool by describing the calls she actually gets.