@ALostInquirer
Let me know if it ends up making any sense. I use this (alongside a few other ways of authenticating), and I still find the details a bit hard to follow. Configuring it in an application is the easy part; figuring out how it all interacts with your own system can get complicated if you need more info than what’s provided in the user info endpoint (honestly more of an enterprise problem than something we deal with outside of the office)
There are open issues for Kbin, Lemmy, Mastodon, MissKey, Firefish, and Pixelfed about OIDC. Some projects have implemented limited OpenID/OAuth2 services for logging in with Google/Facebook/Apple, but for most services this really depends on someone getting their hands dirty and implementing the OIDC properly.
All projects seem to have much bigger fish to fry in the mean time. I don’t think we’ll see this happen without an external (team of) volunteer(s) taking up the tasks and implementing the feature in some kind of unified way.
I don’t think this should be particularly hard for most services, except maybe Lemmy, because many projects already support external authentication. This just needs some implementation, testing, and perhaps a security review to make sure you cant authenticate yourself into other people’s accounts.
As an engineer who has wasted far too much time at work updating, fixing, and implementing integration with identity providers, I can totally empathize with why this hasn’t been done yet. These fucking standards are so complicated to understand let alone implement.
It’s unfortunate the federated part of OpenID died. There are plenty of OpenID clients for all kinds of languages that will Just Work if you just pass them the right four magic variables and something like Keycloak is surprisingly easy to maintain once you’ve got it set up right.
