Windows NT on 600MHz machine opens apps instantly. What happened?

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.

> Kerberos relies on line of sight to the TGS

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)?