14 ms·

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 gotte

• thefourthchime 3y ago
  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.
  • verall 3y ago
    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??
    • mschuster91 3y ago
      IME that's usually because: - 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
      • verall 3y ago
        It's probably the plugins, but even then I would have assumed that timeouts would have made it impossible to load a page that slow.
        • mschuster91 3y ago
          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?
    • wkat4242 3y ago
      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.
    • rootusrootus 3y ago
      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.
  • kaba0 3y ago
    Hell, Microsoft managed to “login loop” me multiple times on Firefox, where it ended up infinite redirects until some limit (browser?) were hit.
    • Nextgrid 3y ago
      Commonly happens on Outlook here.
• matwood 3y ago
  It's the SSO and the prolific usage of 3rd party auth providers. There's probably also a check in there to make sure you're not a bot. So while all the redirects are annoying, they are probably better than all the hand rolled auth that failed in various ways.
• pdntspa 3y ago
  It's SSO, which communicates via tons and tons of redirects
  • reaperducer 3y ago
    It's SSO, which communicates via tons and tons of redirects Not always. AT&T goes through about 25 redirects to sign in. No SSO involved.
    • pdntspa 3y ago
      Are you sure?
    • nullindividual 3y ago
      It's SSO behind the scenes between services within ATTs environment. It's just not "SSO" to you, the end user.
  • Nextgrid 3y ago
    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.
• billyjobob 3y ago
  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?"
  • verall 3y ago
    I haven't figured this one out either - why show the user how difficult it will be to use before they sign up? That's supposed to be for after.
  • Solvency 3y ago
    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.
    • ryandrake 3y ago
      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.
      • Tade0 3y ago
        I've split tickets into smaller chunks because the number of tickets closed was my KPI at the time. It's dumb and current me would just say that out loud and not participate in this circus.
        • mikrotikker 3y ago
          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.
• Nextgrid 3y ago
  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.
  • nullindividual 3y ago
    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.
    • Nextgrid 3y ago
      > 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)?
• kitsunesoba 3y ago
  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.
  • jeroenhd 3y ago
    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.
    • tracker1 3y ago
      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.
  • Peanuts99 3y ago
• lukeschlather 3y ago
  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.
• aimor 3y ago
  I pay my water bill on my phone using cellular data because some part of the sign-in process hits an address that's blocked by the adblock DNS I use.
  • nerdponx 3y ago
    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.
    • Nextgrid 3y ago
      This is also a security and GDPR liability, if only it was enforced.
• tomjen3 3y ago
  Could be anything from a SPA that has to be reloaded entirely to loading a ton of 3rd party JS to work with all those login with options.
• devnullbrain 3y ago
  I use Firefox containers with Temporary Containers (https://addons.mozilla.org/en-US/firefox/addon/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.
• MatmaRex 3y ago
  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.
• _Algernon_ 3y ago
  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.
  • nullindividual 3y ago
    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.
• rufus_foreman 3y ago
  The last time I logged in to AWS, the process went something like this, I may have left out or mistaken a step or two: 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.
  • dredmorbius 3y ago
    Fortunately, I have found a solution... And I suppose the margin is too narrow to contain it? (Care to share?)
• marklar423 3y ago
  That would be OAuth - https://en.wikipedia.org/wiki/OAuth https://en.wikipedia.org/wiki/OAuth. 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.
• daigoba66 3y ago
  > what's going on here and how every single website has this new slowness Everyone and everything uses OAuth/OIDC.
• immibis 3y ago
  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.