Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you would likely end up with a lot of failed attempts to sign up with some "3rd world" provider.
PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.
I have just added OIDC support for bring-your-own-SSO to our application, and it wasn’t as bad as you make it sound: As long as the identity provider exposes a well-known OpenID configuration endpoint, you can figure it out (including whether PKCE is required or supported, by the way!)
The only relevant flow is authorisation code with PKCE now (plus client credentials if you do server-to-server), and I haven’t found an identity provider yet that wouldn’t support that. Yes, that protocol has way too many knobs providers can fiddle with. But it’s absolutely doable.
I didn't say it was impossible, just impractical and that is why majority of services that use SSO only support google, apple, twitter or facebook. You write the code specific to these few providers once and are done with it for good. There is little reason to invest time and money for adding generic support for other providers. It's just the way it is. If OIDC protocol would get streamlined a bit, we could easily have universal support. But then again, these big providers would likely be stuck in the current version and not bother adjusting to the new, simpler version, if it would come to be.
With metadata endpoint, things become much easier, that is true.
Though how would you implement it? Like, user comes to your website and wants to sign in with some foo.bar provider, do you force the user to paste in the domain where you go look for the metadata? What about facebook or google, do you give them special treatment with prepared buttons or do you force user to still put in their domains? What about people using your flow to "ddos" some random domain...?
Fedcm offers some hope here, where the browser gets some capability to announce the federation domains to the RP. It's not straightforward though, of course. In this case though it's inverted - you are providing the url of the MCP server, and the MCP server is providing the url of an authz server it supports. The client is uses the metadata lookup to know if it should include PKCE bits or not.
With DCR (dynamic client registration) you can have an unlimited number of providers. Basically, just query the well-known endpoint and then use regular OAuth with a random secret.
There's also a proposal to add stateless ephemeral clients.
DCR is cool, but I haven't seen anyone roll it out. I know it has to be enabled per-tenant in Okta and Azure (which nobody does), and I don't think Google Workspace supports it at all yet. It's a shame that OIDC spent so long and got so much market-share tied to OAuth client secrets, especially since classic OpenID had no such configuration step.
This is because the MCP folks focus almost entirely on the client developer experience at the expense of implementability
CIMD is a bit better and will supplant DCR, but overall there's yet to be a good flow here that supports management in enterprise use cases.
This isn’t fundamental to its design, though. It’s a result of providers wanting to gate access to identities for various reasons. The protocol presented here does nothing to address this gating.
