This sounds like moving the problem, not solving it. I've been doing server based systems since forever and sso is this big complicated topic where people seem to bias to using either really complicated and convoluted enterprise solutions or some walled garden with lots of limitations.
In both cases you are buying into somebody else's solution. That complex framework is complex because the company behind it threw everything and the kitchen sink at it. You don't actually need most of what it needs. And that company makes money by adding more crap to it, via certification, training and consulting. It's complex by design. You can't just sit down and use it. You have to study it first. Become an expert in using it. If you've ever used Keycloak, Spring Security, or similarly convoluted solutions, you know what I'm talking about.
And then that walled garden thing (auth0 or whatever is in fashion these days) is super simple to use. Just do magic steps 1 2 and 3 and you are good to go. But don't deviate from the happy path! There is a happy path. Either you are a perfect match for it or you aren't.
The middle ground is realizing that a users table with a bcrypt encrypted password column and a few other bits and bobs isn't all that hard. Building some sane flows around resetting passwords, 2FA, emailing login links, etc. Easy.
You can actually vibe code most of this stuff these days. And I've done all this manually in the past as well. I've implemented SSO, Oauth (1 & 2), OpenID Connect, etc. I've implemented API call counting, rate limiting, 2FA, etc. I use some frameworks for most of the heavy lifting and dealing with hashing, JWTs, and all the rest. Most of the rest is just simple API plumbing. Most of these flows aren't all that complex. You need good tests and a good understanding of what the system is supposed to do. But that's a constant in this space. Trying to use somebody else's really complicated solution without that is not going to be easier, better, or faster.