A lot of people are bringing up Wirth's law or other things, but I want to get more specific.
Has anyone else noticed how bad sign-on redirect flows have gotten in the past ~5 years?
It used to be you clicked sign in, and then you were redirected to a login page. Now I typically see my browser go through 4+ redirects, stuck at a white screen for 10-60 seconds.
I'm a systems C++ developer and I know nothing about webdev. Can someone _please_ fill me in on what's going on here and how every single website has this new slowness?
The sad part is that we have an OS-managed standard for SSO called Kerberos, successfully used as part of Microsoft Active Directory, and for which most mainstream OSes still include support. This allows any application on your machine to inherit that auth without ever seeing a single login screen.
While it can't easily be used cross-companies (and thus why SAML/OIDC exists), it's perfect for internal company infrastructure, and SAML/OIDC can still be handled somewhat seamlessly by having a minimal service that verifies your Kerberos identity and immediately dispatches you back to whatever third-party service you wanted to authenticate to, with no intermediate login pages or even any kind of UI (this service doesn't need UI because your authentication is managed via Kerberos for which your OS provides the UI).
The problem is that you can't make money (nor "growth & engagement") off stable, battle-tested stuff that already exists and happily works in the background, so Okta/etc shareholders need to peddle worse solutions that waste everyone's time and processing power.
Kerberos relies on line of sight to the TGS. In the '90s and '00s, this was common place. As of COVID, less so.
Kerberos is also difficult to administer and secure (Golden Ticket?). Kerberos also requires the target service be a member of the Kerberos Realm (or otherwise trusted) which again means line of sight between the service and TGS or Realm to Realm.
And then we get into the whole ticket size issue.
Kerberos is not a good candidate for web-based AuthN.
Isn't this the same with any SSO provider? The SSO provider must be reachable by the end-user's browser during any authentication operation.
(in case of KB it must be reachable by the target services too, but in a server-to-server environment it's less of an issue)
> Golden Ticket
Isn't this exactly the same to let's say a session cookie of a web-based IdP?
The IdP could apply policies on its backend that bind the cookie to a given IP address, user-agent or other indicators, but can't this also be done for Kerberos tickets using a server-side middleware on every service you wish to access (since KB is internal-only, it shouldn't be that big of a deal)?
Isn't Kerberos explicitly designed to run over untrusted networks and not require any additional transport encryption?
You could argue that the common implementations are large piles of legacy C with questionable memory safety that could open them to exploitation by malicious actors, but that's an implementation detail rather than the protocol itself - and I believe there's at least one (mostly?) memory-safe implementation in Java called Apache Kerby.
SSO can seem intimidating to someone new to authentication implementations. I think this is in part because it is a bit complicated but also because it is an inherently invisible technology which we dont need think about as users. Sign in with fb/google on the other hand is something we all see in our day to day business and have at least some kind of mental picture of how it works. We've also seen it used as authentication for otherwise poorly implemented services so we might think that "since they managed to use it, how hard can it be?". Hence, a lot of developers and product owners choose those instead of SSO.
A lot of sites now don't even a "sign in" now. You only have a large "sign up" button, which you have to click, and then in very small text at the bottom of the sign up screen find the link for "already have an account?"
Don't you see? All that matters is those tasty conversions. They want your email. They want your conversion. What's that? You've converted already and want to login? Sorry, we've got more conversions to drive, can't be bothered.
I worked with a designer that actually told me this un-sarcastically. "My KPI is signups, not logins. Bury the login link. Existing users don't move the metric."
Metrics-based and KPI-based software development has ruined quality for decades.
Reminds me of those explorers who paid the natives for every dinosaur bone they turned in, only to be horrified when they realized the natives were breaking the bones into as many pieces as possible to collect as much currency as possible.
This is what happens when you strongly tie promotions to metrics. Make sure you have the right ones, or don't do it. Left to his own devices, the designer would probably have done the right thing. It takes a bad incentive to make someone do something like this.
Web UX designers need to find some alternative button label that users understand means both “Sign up” and “Sign in”. The site will know if your email address has an account and should then be asked does a password. Though users will still complain that the login process requires two steps: entering a username and then the backend determining whether to next serve a password or registration form.
Needing a bunch of JavaScript to make it work, which will get bungled by the devs and break it for people using password managers, making the thing even worse. Login is such a common pattern that it should be just handled by the browser.
Good point. It's unfortunate that HTTP Auth never become popular. I don't know if that was because the browser support or UX was bad or if web developers wanted more control over their sites' login flow or user information required.
1. send in plain text with http basic auth. Over https this isn't a problem, but https was expensive). This is sent on every request.
2. Use digest. This is also sent on every request, and also requires actual processing, at which point you might as well go for 4 so it looks nice.
3. Use certificates. Nobody does this on the pubic web. The only website I've ever used certificates was whatever certificate site predated let's encrypt, can't remember the name at the moment, and as someone who doesn't use client certificates it was a huge pain (blame that on the browsers though)
4. Use a form on the website with a session token, and you get control over the UI including error messages and styling. Much more user-friendly. You can trivially prevent the user from (easily) sending requests with pain text passwords by only showing sensitive pages like login over https. The user can't bookmark or share a URL with a password embedded in it. You can request more information than just username and password (Bank: do you want to see your checking account or savings account? Forum: go back to previous page or to homepage? SSO-ish (DayForce): what's the name of the org you're signing into?)
My mother signs out of her email every time she closes it, and does the same for other websites as well. She's the only one who uses her computer, and it has a password on it (mostly because Windows won't do file sharing without one). She still refuses to stay signed in.
Not everyone wants to stay logged in, and not everyone uses a single browser; I occasionally use the wrong browser profile for something because I cbf loading up the correct one; in these cases I usually load the website in a private browsing tab to avoid container/addon settings interfering. When I can't log in easily, I get quite annoyed.
My university portal login flow (Microsoft login via university SSO), frequently has me log in with password+2fa+nag screen to use microsoft authenticator, just to then randomly fail and have me do the entire thing again. It is infuriating, especially since any login cookies appear to only be valid for 1-2 days per device.
I suspect that the amount of time I spend on just logging in to websites each day is upwards of 5 minutes, and I doubt it will decrease over the coming decades. Such a waste.
First issue is likely solvable by your IT department by looking through the AAD sign-in logs for your activity.
The second is because authentication is per-device (and depending on the scenario, per-app). The token lifetime is configured by your IT department. Microsoft's default is 365 days, if I recall.
Google and Microsoft are the worst for this. When you sign on you can see it flashing through several of their products, signing you on in each, before finally redirecting you to wherever you intended to go.
It might be done for user retention reasons with the idea that people are more likely to use sites they're already signed into, but I really don't need to be signed into YouTube when I sign into my Google work account. Please just skip that and sign in a few seconds quicker.
I'm pretty sure Google does it to set all the appropriate cookies on the right domains. Microsoft probably has similar redirect flows.
You can either do the redirects all at once on login or do them once you use the service first. Since login is already a time-consuming process (username, next, password, next, 2FA, next) I think you may as well take a second to add the redirects and be done with it.
It doesn't make much sense for Google work accounts but it makes sense if those are a minority on the platform. They could definitely patch this out, but then again the login process is something that takes a second extra every month or so, so who really cares.
What does bother me is how every service wants you to enter your username and password separately now. Autofill gets confused and sometimes even stops working because the stupid hidden input fields for the password don't get shown until you click the magical "next" button, just in case you need a special third party auth service.
Either decide that work accounts are important and take out the extra YouTube redirect, or decide they aren't important and let me fill in my username and password on a single form. Both make complete sense individually but combined they're just a massive waste of time.
When I've done login screens, I usually also include a hidden password field so that the password manager can autofill... this way, it's already filled when the password field is visible after clicking "next". It's at least an improvement to the workflow for those of us using a password manager.
Explaining it to the SecOps person, that was painful though.
It's because Microsoft and Google are the two largest identity providers around. Microsoft has M365 logins that can be configured with about 12 different authentication systems, as well as the various services like outlook.com, Hotmail etc. It has to check the login against those systems and then redirect you to that system.
Modern browsers heavily restrict cookies. The redirect chain right after login, that takes you through all subdomains, is a way to evade cookie restrictions if your sites use different domains.
I use Firefox containers with Temporary Containers (https://addons.mozilla.org/en-US/firefox/addon/temporary-con...) so oh boy do I deal with this a lot. With some hacking I can stop the page at the right time to make it 'always open in X container' - there doesn't seem to be an obvious way to glob for different subdomains.
Ten years ago I worked at a very large cloud company and I spent a lot of time wrestling with the various login flows. I remember seeing a flowchart that documented over 100 service calls that happen in the course of the 4 redirects that took place during a login.
This is the worst. You can't even click an internal site link anymore without being redirected through several scummy third-party domains, so that some knucklehead product manager can claim that they are tracking "engagement" and show off "metrics" to their upper managers.
Some of it has to do with changes to browsers’ acceptance of cookies. If you need to set cookies on multiple domains you control (common for SSO), you used to be able to do it by loading a pixel image or tiny script from each domain. Now, however, that’s considered a third-party cookie, and rejected by many browsers. The only reliable way now is to redirect the whole page, and then redirect back.
OMG Yes. At my megacorp I work at they have this internal HR/401k site thing. I think it goes through 30+ redirects to get anywhere. It's INSANE. We have something called "Pitstop" and clicking on the list of tickets takes 30s+ to load.
My record is Jira successfully loading a page in around 8 minutes. It seriously sat on a white screen for 8 minutes, then boom there's the page - no interaction or F5. What on earth could it have been doing for that long??
Jira is a horrible app though. I don't understand why it's so popular.
Worse thing is the only reason we have to use it is to log our hours. Because the CIO wanted us to be "agile". Apparently logging ones hours in Jira makes us "agile". Yeah I don't know how either. Someone ticked a nice box there for themself. Now we're just creating a useless swamp of data that has no meaning because there are no guidelines on how to log everything. Normally when you implement the full process that stuff is straightforward because you have things in other places in Jira to link to. Not in this case. The only thing we have achieved is making Atlassian a bit richer.
The same with "cloud". We had to be "on cloud". So what do they do? Migrate every physical server. Every time we need a new "server", we still have to fill in the same 18-page excel sheet. Only the tab with the physical rack location has been replaced with one with AWS locations. We still have the delay of several weeks of approvals and everything runs 24/7, nothing scales automatically or is auto provisioned. This is not "cloud". This is fooling oneself. And paying too much. We're technically in the cloud but we don't take advantage of anything it's actually good at. Paying only for resources we actually use? Nope. Auto scaling demand? Nope. Quick provisioning? Lol you wish. And we can't because the infrastructure architect team has locked everything down so nothing can be automated. They only trust themselves to that as they are the high priests.
It's really time for megacorps to stop trying to be like a startup. It doesn't work, unless you basically rebuild the entire org from the ground up. Which will never happen because it will disrupt too much. Too much legacy, too many strings attached to "the business". Too many processes that will never be changed because it means the entire org would have to change.
Just work with what you have and improve that instead of trying to pretend you're something else.
- the database and/or the Tomcat server have way too low RAM and start swapping like no end
- way too many people had admin access in Jira and installed a metric shit ton of plugins
- the AD configuration is messed up and instead of only user accounts it loads (and verifies) tens of thousands of user and machine accounts at each login
Given that people absolutely love to upload multi-GB files to Jira (and will nag the admins to disable timeouts and size limit), many admins have long since relented...
After all, why pay for an expensive DMS when you have Jira?
Jira redefines how slow and clunky a piece of software can be. It reliably takes 15 seconds to update an issue. Even when doing a mass update, 15 seconds per issue, the whole way.
Your browser gets bounced between different sites that don't have the full picture because the process is optimized for the explainability of each part of the system instead of the performance of the whole system. It's something like: the website says "go to Microsoft to get signed in" and then microsoft.com says "actually Microsoft logins are now Live logins so go to login.live.com" and then that says "oh hey, you are already authorized, let me return this result back to Microsoft.com" which then says "oh hey, here's your result, pass it to yourwebsite.com". Something like that. Not exactly that. The point is: nobody has responsibility for the system. People only have responsibility for parts and Conway's Law applies.
It's a standard meant for system A to authenticate a user with system B. Ever logged in to a website with your Google account, or seen those permission screens asking you if you want to allow a third party website to access your Google account? That's OAuth.
Now, as to why many websites do this even when you login with credentials for that system (and not third party auth) - my guess is the system has separate teams for each subsystem, each hosted on different subdomains. In order to transfer auth state from one subdomain to another, you need something like OAuth since cross-domain cookies are forbidden by the browsers.
That's not really an excuse - you really only need 3 page loads:
* initial page provided by the service you're logging into - this gets your email address so it can lookup your account and determine which SSO provider to redirect to
* actual login page served by your SSO provider - here you authenticate to the SSO provider. It can occasionally cause another page load to get your 2FA code if configured, or go through further identity checks
* final "page" that consumes the query parameters sent back by the SSO provider - this is often just a 302 redirect to the home page but sets a session cookie.
The main problem is that all these pages are super bloated, with tons of unnecessary JS and BS. All the code for login page that takes a username and password should be able to fit entirely on an A4 sheet of paper - it's literally just an HTML form and a few lines of CSS.
Furthermore, even beyond inter-company SSO, there are shitty companies out there which use such flows internally even though everything is part of the same security domain, hosted on the same infrastructure and thus can be hosted on the same top-level domain and use a single session cookie. Microsoft is a pretty bad one - Teams for example will use a redirect to some other Microsoft-owned domain to get your (already existing) Office 365 session; this is completely unnecessary, they can host all those things on the same top-level domain and reuse a single session cookie seamlessly.
Because we never decommissioned the old auth server fully and we have to serve some of the page on a separate domain. Oh and the landing page URI has changed. Also we need to send you to a certain locale. And on and on..
Has anyone else noticed how bad sign-on redirect flows have gotten in the past ~5 years?
It used to be you clicked sign in, and then you were redirected to a login page. Now I typically see my browser go through 4+ redirects, stuck at a white screen for 10-60 seconds.
I'm a systems C++ developer and I know nothing about webdev. Can someone _please_ fill me in on what's going on here and how every single website has this new slowness?