3 ms·

And this is why it takes me a solid minute to log in to my CRM web app to submit my timesheets for the day, a task that takes only 5 seconds.

apitman 2y ago
Sounds like a bad implementation. There's nothing inherent to OAuth2 that makes it slow (thought the redirects to create a latency floor). If you want a good experience try logging in to my website https://takingnames.io/ https://takingnames.io/. Once you have an identity on LastLogin it's lightning fast.
- jiggawatts 2y ago
  "Nothing inherently bad" other than: 1. Tens of kilobytes of JS that is executed exactly once, so is not amenable to JIT optimisation. 2. A strictly sequential series of operations with zero parallelism. 3. Separate flows for each access token, so apps with multiple APIs will have multiple such sequential flows. Thanks to JS being single-threaded, these will almost certainly run in sequence instead of in parallel. 4. Lazy IdPs that have their core infrastructure in only the US region, so international users eat 300ms per round trip. 5. More round-trips than necessary. Microsoft Entra especially uses both HTTP 1.1 and HTTP/2 instead of HTTP/3, TLS 1.2 at best, and uses about half a dozen distinct DNS domains for one login flow. E.g.: "aadcdn.msftauth.net", "login.live.com", "aadcdn.msftauthimages.net", "login.microsoftonline.com", and the web app URLs you're actually trying to access and then the separate API URLs because only SPA apps exist these days. 6. Heaven help you if you have some sort of enterprise system that the IdP needs to delegate to, such as your own internal MFA system, some Oracle Identity product, or whatever. I've seen multi-minute login flows that literally cannot run faster than that, no matter what. This is industry-wide. I stopped using chatgpt.com because it makes me re-authenticate daily (why!?) and it's soooooooo slow. AWS notoriously has its authentication infrastructure only in the US. Microsoft supports regional-local auth servers, but only one region, and the default used to be the US and can't be changed once set. Etc, etc...
  - apitman 2y ago
    The only thing I'm really tempted to defend here is the multi-domain thing, because I'm not aware of another way to set cookies for multiple domains in a single flow, but maybe consolidate your services under a single domain like google does? Minus youtube.com of course, which is fair.
  - aaronpk 2y ago
    "nothing inherently bad" other than: (a list of things that are specifically bad implementations) In my demos the OAuth flow completes so fast you can't even tell it happened, you don't even see the address bar change to the IdP the second time you do a flow when you already have a session there.
    - jiggawatts 2y ago
      Are you in close physical proximity to your servers? Do you access your own application multiple times per day? Then you're testing an atypical scenario of unusually low network latency and pre-cached resources. At scale, you can't put everything into one domain because of performance bottlenecks and deployment considerations. All of the big providers -- the ones actually used by the majority of users -- do this kind of thing. This argument of "you're holding it wrong" doesn't convince me when practically every day I interact with Fortune 500 orgs and have to wait tens of seconds to a minute or more for the browser to stop bouncing around between multiple data centres scattered around the globe.
      - apitman 2y ago
        Big providers have more resources than anyone when it comes to having their servers close to users and optimizing performance. They can afford things like AnyCast networks and custom DNS servers for things like Geo routing. Just because they don't doesn't mean they can't. > you can't put everything into one domain because of performance bottlenecks What specifically are you referring to here?
        jiggawatts 2y ago

apitman 2y ago

Sounds like a bad implementation. There's nothing inherent to OAuth2 that makes it slow (thought the redirects to create a latency floor). If you want a good experience try logging in to my website https://takingnames.io/ https://takingnames.io/. Once you have an identity on LastLogin it's lightning fast.

jiggawatts 2y ago
"Nothing inherently bad" other than: 1. Tens of kilobytes of JS that is executed exactly once, so is not amenable to JIT optimisation. 2. A strictly sequential series of operations with zero parallelism. 3. Separate flows for each access token, so apps with multiple APIs will have multiple such sequential flows. Thanks to JS being single-threaded, these will almost certainly run in sequence instead of in parallel. 4. Lazy IdPs that have their core infrastructure in only the US region, so international users eat 300ms per round trip. 5. More round-trips than necessary. Microsoft Entra especially uses both HTTP 1.1 and HTTP/2 instead of HTTP/3, TLS 1.2 at best, and uses about half a dozen distinct DNS domains for one login flow. E.g.: "aadcdn.msftauth.net", "login.live.com", "aadcdn.msftauthimages.net", "login.microsoftonline.com", and the web app URLs you're actually trying to access and then the separate API URLs because only SPA apps exist these days. 6. Heaven help you if you have some sort of enterprise system that the IdP needs to delegate to, such as your own internal MFA system, some Oracle Identity product, or whatever. I've seen multi-minute login flows that literally cannot run faster than that, no matter what. This is industry-wide. I stopped using chatgpt.com because it makes me re-authenticate daily (why!?) and it's soooooooo slow. AWS notoriously has its authentication infrastructure only in the US. Microsoft supports regional-local auth servers, but only one region, and the default used to be the US and can't be changed once set. Etc, etc...
- apitman 2y ago
  The only thing I'm really tempted to defend here is the multi-domain thing, because I'm not aware of another way to set cookies for multiple domains in a single flow, but maybe consolidate your services under a single domain like google does? Minus youtube.com of course, which is fair.
- aaronpk 2y ago
  "nothing inherently bad" other than: (a list of things that are specifically bad implementations) In my demos the OAuth flow completes so fast you can't even tell it happened, you don't even see the address bar change to the IdP the second time you do a flow when you already have a session there.
  - jiggawatts 2y ago
    Are you in close physical proximity to your servers? Do you access your own application multiple times per day? Then you're testing an atypical scenario of unusually low network latency and pre-cached resources. At scale, you can't put everything into one domain because of performance bottlenecks and deployment considerations. All of the big providers -- the ones actually used by the majority of users -- do this kind of thing. This argument of "you're holding it wrong" doesn't convince me when practically every day I interact with Fortune 500 orgs and have to wait tens of seconds to a minute or more for the browser to stop bouncing around between multiple data centres scattered around the globe.
    - apitman 2y ago
      Big providers have more resources than anyone when it comes to having their servers close to users and optimizing performance. They can afford things like AnyCast networks and custom DNS servers for things like Geo routing. Just because they don't doesn't mean they can't. > you can't put everything into one domain because of performance bottlenecks What specifically are you referring to here?
      - jiggawatts 2y ago