I've implemented some of OpenID Connect, "a simple identity layer on top of the OAuth 2.0 protocol". Combined with OAuth 2.0, it's one of those giant corporate

I've implemented some of OpenID Connect, "a simple identity layer on top of the OAuth 2.0 protocol". Combined with OAuth 2.0, it's one of those giant corporate specs (giant at least for security/crypto purposes) with way too many options so anybody can do anything with any algorithm and any kind of workflow. I wanted to go with a simple, minimal NaCl-based system but in the end did implement a lot of OpenID Connect in the hope it would make interoperability easier with existing client libraries. I don't want to write a client for each and every programming language other people in any related projects would want to use. That in my opinion is the value of something like JWT: you can tell people up front that that's the way they're going to get the user's ID data, no matter how much server or client implementations will be switched around. I feel that when faced with a spec like OpenID Connect and OAuth 2.0, it's not necessary to implement more than what is strictly needed. If you don't need all the flows and algorithms in your project, don't implement and don't accept them. The parts you implement should comply – why base it on a spec if you throw any interoperability out of the window – but don't waste months of trying to correctly implement all of a huge corporate spec if that doesn't make sense for the size of your project or organisation. Complete implementations might have value only if that's your main product and you need that line to sell it. I use JWT only as ID, not as session, allow only one server-chosen algorithm for signing, and rely on TLS for encryption. There's clearly a need for up-to-date "web-approved" standards to pass crypto-friendly data structures around – or maybe I'm just not familiar with any recent efforts. Normalising and serialising JSON is pretty error prone...