You know the conventional wisdom that the “close” button in elevators isn’t really hooked up to anything. That it’s just there to make you feel good? “Keep me logged in” is digital identity’s version of that button. Why is using authenticated service on the web so unpleasant?
Note that I’m specifically talking about the web, as opposed to mobile apps. As I wrote before
, compare your online, web experience at your bank with the mobile experience from the same bank. Chances are, if you’re like me, that you pick up your phone and use a biometric authentication method (e.g. FaceId) to open it. Then you select the app and the biometrics play again to make sure it’s you, and you’re in.
On the web, in contrast, you likely end up at a landing page where you have to search for the login button which is hidden in a menu or at the top of the page. Once you do, it probably asks you for your identifier (username). You open up your password manager (a few clicks) and fill the username and only then does it show you the password field1. You click a few more times to fill in the password. Then, if you use multi-factor authentication (and you should), you get to open up your phone, find the 2FA app, get the code, and type it in. To add insult to injury, the ceremony will be just different enough at every site you visit that you really don’t develop much muscle memory for it.
As a consequence, when most people need something from their bank, they pull out their phone and use the mobile app. I think this is a shame. I like the web. There’s more freedom on the web because there are fewer all-powerful gatekeepers. And, for many developers, it’s more approachable. The web, by design, is more transparent in how it works, inspiring innovation and accelerating it’s adoption.
The core problem with the web isn’t just passwords. After all, most mobile apps authenticate using passwords as well. The problem is how sessions are set up and refreshed (or not, in the case of the web). On the web, sessions are managed using cookies, or correlation identifiers. A correlation identifier is a unique string that can be used to link requests. Ultimately, the the HTTP community added a correlation identifier called a “cookie” (which took its name from a correlation identifier used in unix). HTTP cookies are generated by the server and stored on the browser. Whenever the browser makes a request to the server, it sends back the cookie, allowing the server to correlate all requests from that browser. Web sites, over the years, have become more security conscious. As a result, most set expirations for cookies. When the cookie has expired, you have to log in again.