(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.
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.
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
If you look at my original comment in this thread, I mentioned that to log in to something like Microsoft 365 via Azure Entra ID, the browser has to connect to a bunch of distinct DNS domains. About half of these are CDNs serving the JavaScript, images, etc... For example, customers can upload their own corporate logos and wallpapers and that has to be served up.
Just about every aspect of a CDN is very different to an IdP server. A CDN is large volumes of static content, not-security-critical, slowly changing, etc... Conversely the API is security-critical, can't be securely served "from the edge", needs rapid software changes when vulnerabilities are found, etc...
So providers split them such that the bulk of the traffic goes to a CDN-only domain distributed out to cache boxes in third-party telco sites and the OAuth protocol goes to an application server hosted in a small number of secure data centres.
To the end user this means that now the browser needs at least two HTTPS connections, with DNS lookups (including CDN CNAME chasing!), TCP 3-way handshake, HTTPS protocol negotiation, etc...
This also can't be efficiently done as some sort of pre-flight thing in the browser either because it's all served from different domains and is IdP-controlled. If I click on some "myapp.com" and it redirects to "login.idp.com" then it's that page that tells the browser to go to "cdn.idp.com" to retrieve the JavaScript or whatever that's needed to process the login.
It's all sequential steps, each one of which bounces around the planet looking up DNS or whatnot.
"It's fast for me!" says the developer sitting in the same city as both their servers and the IdP, connected on gigabit fibre.
Try this flow from Australia and see how fast it is.
Exactly. Even in a relatively dense location, I have a new automation that runs when my cameras detect a person, both blaring a siren outside as well as notifying me in the house. Now about half a dozen times, it has stopped someone from getting farther than a few feet on the property, whereas without it I had people sneaking around looking for unlocked doors.
Sarcasm is usually conveyed through any of tone of voice, facial expression, or gesticulation; none of which transmit through the written word. Standard operating procedure is to add something like /s.
Check out the actual spec, there's nothing in IndieAuth that relies on third parties. The whole point is so you can authenticate as your own domain to other things. There are some helper services that let you authenticate via Twitter/GitHub in case your website doesn't support IndieAuth natively. https://indieauth.net
ActivityPub by definition doesn't work with a static site. But check out this project which offloads the ActivityPub parts for any site assuming you can make a request there as part of your static site build process https://fed.brid.gy/
> edit: Also, why doesn't webmention.io display its own mentions to utilize the two-way communication it advertises? Seems like a no-brainer to show prospective users an example of it working in action
This is a good idea, and if I were re-making this service new in 2021 I would definitely do this. However I launched this in 2012 as a barebones implementation to get webmentions working for a few of my websites and never bothered to develop it much past that point.
The good news is everyone who receives webmentions can decide what it looks like themselves! In fact you'll see quite a lot of variation in how these are displayed on people's websites. Everything from a list of comments, to just a list of URLs, to a grid of faces with no text!
eta: There is also no requirement that the receiver of a webmention displays it! You could just as well use it for private notifications of the links.
(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.
reply