If we have to implement all those things, is there really much of a remaining lift in implementing OIDC, apart from bringing in a library into a web app?
Yes, implementing both OAuth2 as well as OIDC according to spec is a significant development effort and countless teams and companies fail at pushing through, shipping incomplete or insecure implementations. If you’re greenfield, OAuth2/OIDC is with 99% certainty not the right fit for you anyways.
Username + Password with a cookie store is much better understood and harder to get wrong than implementing a full OIDC suite (server + client). If you're talking federated login, that's what OIDC is for. If you're talking "login", your opinion is misguided.
We might not be talking about the same thing. The thread was comparing to other OAuth servers, and then libraries, but nobody is talking about implementing it from scratch.
That being said, if you're working on a greenfield app where you need auth, using an OAuth/OIDC server is much better and faster than creating yet another membership system for that app. That's a major advantage of identity federation.
Lets say there are no restrictions, what type of authentication flow would you recommend looking into? I was under the impression that OAuth2 was pretty much the goto standard nowadays.
OpenID Connect with the authorization code flow using PKCE is the newest and best standard, and now works the same for both client-side and server-side apps.
Sorry, but following a standard for federation is not a substitute for building a log in system, which is what most people want when building "a web app".
