I implemented a minimal OpenID Connect server internally a few years back when it was difficult to find something for our specific use case in Go. I think that

I implemented a minimal OpenID Connect server internally a few years back when it was difficult to find something for our specific use case in Go. I think that while the general idea is good, the spec is a mess: it's too flexible in all the wrong ways, so every large player implements it slightly differently, leaving you with no clear path to go yourself; and actually making the protocol (... concept?) less secure than it could be. I kept thinking that for our use case, a simpler aead token or perhaps something like Maracoons (if there would be more battle-tested libraries for it...) would suffice. In the end I implemented a partial solution with one flow and one JWT signing algorithm so the other services could rely on existing client libraries for their respective programming languages. Of course none of it ended up being used, as SAML (there's another can of worms...) support became a requirement and some large framework was brought in for that corporate software feel-good factor... I agree with the sentiment that it would be nice if there would be new development in this area, even (or especially) if none of the big players are involved, but non-trivial crypto protocols and frameworks seem to need a lot of momentum to break out of their local ecosystems. It's not easy to design something that fits different use cases yet doesn't break at the joints.