Why are SSO and mobile pay not standard interfaces that anybody can build a provider for? Why is there "Login with Google" or "Login with Apple" instead of "Login with [my default configured SSO provider]". Or "Pay with [my default configured pay provider]"
Even worse, many times vendors/sites only support a subset of these providers, making SSO not really SSO at all.
I'm sure the reasons are out there, but I haven't researched it in-depth. It seems to me there should be a common agreed upon spec that all vendors adhere to. If not, it will probably be legislated to this standard sometime in the future
I believe what you're looking for for SSO is RFC 7591[0], which describes how to register with an oauth IdP on the fly. RFC 8414[1] describes well-known locations to get metadata about the registration process. So the standards are there, and in theory you could have a login form where e.g. someone types their email (or the browser autofills it), and that kicks off an oauth login to that domain, doing client registration on the fly if the server has never talked to that domain before. I've never seen it in the wild though. Would be nice.
I think tailscale supports exactly that? You give them your email address and they check the web finger endpoint of the domain for your configured SSO provider. https://tailscale.com/kb/1240/sso-custom-oidc
Because of "growth & engagement". Somewhere around 2010, technology shifted from being a tool to empower the user to a tool to waste the user's time with spam. Things shifted from offering a service and collecting a fair fee to spamming the user or collecting their data (so it can be used to further spam the user down the line).
An open standard isn't something any of the current providers want since otherwise users can easily substitute them with different alternatives and no longer "engage" with them.
Because user verification varies significantly between businesses, and so they need to vet and trust SSO vendors to uphold the standards they require. If there are a million sso vendors, who knows what standards each upholds.
The difference is that you can be reasonably sure that an email will be delivered to the user's address that they specified, and there is a common understanding that sharing your email credentials will result in immediate financial loss. The communication is out-of-band, as SMTP is not an authentication protocol, so the user must perform some affirmative action (such as clicking a link in the email) to authenticate the request.
With SSO, the claim that a user is authentic lies completely with the provider. If there is a bug in the implementation, a user could be authenticated when they should not be, and the actual account owner may never even be notified that such an authentication occurred.
With oauth/oidc, the service that's requesting the token doesn't even specify the username. What would the IdP send back if the user is not authenticated? The concern is it will just issue a token for a random user? Or that someone will break into another account on the IdP's login form?
I don't see any difference with email besides convenience. If an email provider has a bug, they might allow someone else to read your email and click the link without any notification to the actual account owner that such an authentication occurred. In fact, if a provider has oauth and webmail, the two probably use the same authentication system (e.g. they use the same session cookie and login form, or the webmail might use the oauth service as its auth). Even native email clients are using oauth these days. This is a good thing. It lets you store a token with limited permission in your email client instead of storing a password for SMTP that also gives you full permissions to everything the account can do.
Also most oauth implementations I've seen actually do have a dashboard in your user settings where they record which services you've provided tokens to, and what scopes those tokens have.
If you're worried about CSRF, that's what the state parameter is for, and it's the consuming service that needs to use it appropriately, so you don't need to worry about whether the IdP did it right. If the IdP gives the wrong state back, the login will fail when your service checks it.
To support "Login with Google" you have to do some config on the Google side. You have to tell them, this ils my app, this is the URL you have to redirect back to after authenticating, and do on. Otherwise there would be security problems.
Passkeys are great(-ish) for authentication, but don't offer identification at all.
It's just not in scope (and I think that's a good thing; the two problems are pretty different, and WebAuthN is already extremely overloaded with features serving conflicting goals).
Even worse, many times vendors/sites only support a subset of these providers, making SSO not really SSO at all.
I'm sure the reasons are out there, but I haven't researched it in-depth. It seems to me there should be a common agreed upon spec that all vendors adhere to. If not, it will probably be legislated to this standard sometime in the future