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

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?

So while all the redirects are annoying, they are probably better than all the hand rolled auth that failed in various ways.

- 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

Not always. AT&T goes through about 25 redirects to sign in. No SSO involved.

* 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.

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.

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.

Metrics-based and KPI-based software development has ruined quality for decades.

After all, why pay for an expensive DMS when you have Jira?

Bad UX though.

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.

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.

It's dumb and current me would just say that out loud and not participate in this circus.

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.

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.

Explaining it to the SecOps person, that was painful though.

Go to login page

Solve capcha to get to login prompt

Enter user name, get sent to next page

Enter password

Enter MFA code

Failed, try resynching MFA token

Repeat login process

Failed, try rescynching MFA token again

Failed, repeat login process and then go to troubleshoot MFA link on mfa page

Enter password again

Go to altternative factors link

Click link to send verification email

Didn't get email, click link again

Click link in verification email

Click link on login page to get a phone call with a code

Get a call but it doesn't give me a code, try again

Still no code, try again

Get a code this time from the call but the code fails verification, try again

Get a code and it gets verified, sends me to a login page

Solve a capcha

Enter username and password, get logged in

Fortunately, I have found a solution to ensure this series of issues does not reoccur.

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.

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

If anyone thinks you need more redirects than this, I'd really like to know what more you think is necessary.

Yes, but OAuth has one major upside: HTTPS only.

No one wants to create site-to-site VPN networks to flow Kerberos.

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.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica...

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.

"We" just assume that anyone who has already signed up will always be signed in.

Everyone and everything uses OAuth/OIDC.

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

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.

And I suppose the margin is too narrow to contain it?

(Care to share?)