|
|
|
# OAuth Hate
|
|
|
|
|
|
|
|
Yep, I end up _kinda_ hating OAuth...
|
|
|
|
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!
|
|
|
|
|
| ... | ... | @@ -16,11 +16,11 @@ It too high-level, it's not efficient at all. But that's the last of its problem |
|
|
|
|
|
|
|
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!)
|
|
|
|
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 the 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:
|
|
|
|
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!
|
| ... | ... | @@ -35,17 +35,17 @@ They also included a lot of nearly-useless authentication procedures. They also |
|
|
|
|
|
|
|
The <sarcasm>nice</sarcasm> 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!
|
|
|
|
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.
|
|
|
|
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:
|
|
|
|
If Facebook, twitter and Instagram failed to implement it, how do you think you'll do? Here's a hint:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## So... Fenrir is the answer?
|
|
|
|
|
|
|
|
I sincerely hope yes, but in regards to OAuth, anything else would really be better.
|
|
|
|
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) do the authentication.
|
|
|
|
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.
|
|
|
|
|
