So much this. I work on an educational product, and we support something like 5 or 6 different school OIDC providers and have to maintain a separate implementation for each one. They all use the same base class, but there’s just a stupid amount of variation in how they actually work.

Can you share the names of these OIDC providers? I've worked some with schools and it seems like they all have settled on either Azure AD/Entra or Google, but I'd like to learn more.

Clever, Canvas, Schoology along with Microsoft and Google

> why you'd even want OIDC for most apps

If you can get away from OIDC, don't touch it. It's only usefull if you don't control the source of users, need to have some seemless login across many apps or if your app is integrated with many other apps for which you need something that work everywhere and that is a standard. OIDC and SAML are the lingua franca when you need that kind of capabilities and those scenario are just the one I've faced, there's a lot more to it

> I don't see why it is preferable over basic forms auth with a cookie.

Cookie is how you typically persist session on a browser, this is the step that usually goes after you've authenticated / been authorised, the scope of OIDC is purely in the authentication/authorisation and doesn't even specify how you should persist the session. Also the scope of OIDC goes beyond the browser

> OIDC-by-default seems like overengineering but I appreciate I'm probably missing a critical reason.

By all means, if your use case doesn't need it, don't touch OIDC/SAML it would be like using kubernetes to host your mum wordpress. OIDC and SAML are complicated because SSO is made to fit the need of companies with all sort of use cases that goes beyond simple use case like the one you seem to describe.

I wholeheartedly agree with your last sentence that is seems overengineered, but one has to assume that there are use cases that warrant such a complex auth scheme. I cannot speak to that as I have never implemented systems of massive scale.

However one thing that puts me off is that it slowly becomes the default way of implementing authentication and authorisation at work where our internal (web) services are (at best) used by 10s of people on a given day. Besides the "old" way of auth integrated much better into our existing system landscape while the "new" way requires (in our case) a Keycloak server.

Again, all that would be fine if the use cased warranted the complexity, but in my employer's case it does not.

A session cookie from app1.domain.com isn’t readable by app2.domain.com. So with plain cookie auth, you have to login to every app individually. Is there a simpler way around this than OIDC?

And what if you want to gate your services to only those users who have an org-issued yubikey? With OIDC you can delegate the device check to a single host (your IdP) and if apps speak OIDC they’ll be protected. That means MFA SSO!

Is OIDC the wrong tool for this job?

I assume from what you are describing that OIDC is probably just the right tool for this job.

In my problem domain (think internal apps that serve many different purposes with little overlap and a diverse set of users) logging in individually to every single app simply is not an issue, albeit a little annoying).

That being said we do use a single authentication backend across all apps, just not one that is capable of OIDC and is thus a lot more limited in what can be achieved with it.