LukerOAuth Hate
Yep, I ended up kinda hating OAuth...
I mean, have they done anything right? it was so bad that the main leader and developer left a couple of months before the 2.0 became RFC, and made them take out his name from the contributor list!
but let's be rational...
There have been many discussions and videos (that video is a highly recommended watch) on why OAuth literally sucks, so I'm not going to repeat all the technical information again, I'll just give my impression.
Why you should hate OAuthv1
'cause it is ugly.
It too high-level, it's not efficient at all. But that's the last of its problems.
It took them too much time to develop, they wanted to support even PHP4 web hosting (which was a mess), and ended up with a protocol where the interoperability between implementations is 0.
It's like they didn't care about security. SSL was not even mandatory (like, what?). Sure, they have the magic crypto stuff in the messages, but and attacker still can get access if SSL is not used. (really useful crypto!)
My favourite part of the RFC is the nonce in the first messages. basically, this nonce is sent from the client to the server, but never sent back. The server is supposed to keep track of every nonce and parameters used with that nonce to avoid replay attacks. The meeting when they decided that it was a good idea was probably something like this:
The interoperability between libraries and services is 0, since the authentication pages must be provided for each service. And you can use GET or POST as you want (wtf?). Basically, you need to write one application for each service, or keep a huge database of possible servers and their pages. Nice!
Oohh, but you can authenticate the application! Really useful, when the secret must be hard-coded into your application. Do I need to say more? The binary is the same for everyone! Secret? Really?
I'm mot a mathematician but 2 is more than 1, right?
Yeah, and 3 is better then 2. Except when it's the number of years it took them to come up with this "thing".
They also included a lot of nearly-useless authentication procedures. They also made SSL a recommendation on some pages, a requirement on others.
The nice part of this protocol framework is that you can do whatever you want. There are 5 (FIVE) ways of authenticating an user. Of which one is literally just "put your stuff here, whatever it is".
There's too much choice, the interoperability problems got even worse, and all the "optional" parts (nonces and states) are actually needed if you don't want to risk an attack on your servers. It's so easy to implement that even Facebook and Instagram had to change their server implementation because it was broken!
And yeah, the useless application authentication is still there.
If Facebook, twitter and Instagram failed to implement it, how do you think you'll do? Here's a hint:
Guess what? Version 3!
But with a different name. It's called 'OpenID-Connect', it works on top of OAuth2 (...???) and standardizes the possible framework choices, introduces autodiscovery (which is optional, great), and a lot more complexity.
It's dead Jim. Let it go.
So... Fenrir is the answer?
I sincerely hope yes, but in regards to OAuth, anything else would be better, really.
The big difference is that OAuth is above the HTTP layer, so it seems easy to implement. Fenrir will need the protocol application (for example apache for HTTP) to expose the right calls to let the application (for example the web page) receive the authentication information, but the programmer won't have to reimplement crypto and singing by himself.