61–70 of 73 posts
It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contri…
Earlier quoted context omitted.
Tricky and unnecessary crypto code: you mean HMAC, or something else? I've written code for Amazon EC2 that used HMAC and it wasn't too bad, and I'm now trying to evaluate whether to use OAuth 2, OAuth 1 or something else. Is there other cryptographic coding in OAuth 1 apart from the HMAC signature?
The biggest problem I had with OAuth 1 was that if you messed up anything chances are all you got back from the server was "Signature Invalid". You're then stuck trying to find out where you had gone wrong with no guidance. The last time was due to an incorrect content type on the post. A coworker accidentally had the key and secret the wrong way around. Both scenarios has the same error and you're often stuck gropin…
It saddens me to see OAuth 2.0 in this state. As someone who’s made really minor contributions to 2.0 (and thus listed as a contributor in the spec), I have been really looking forward to it being finished and ready for production use (where production use means no more drafts). I stopped following the mailing list last year because most of the threads seemed all too familiar or out of my realm of knowledge to contri…
I don't understand any of this. Microsoft develops and publishes 'protocols' (used lightly) and everyone hates them because they are pushing workable code out on everyone else... Bunch of people in a committee take three years trying to build the security token system to end all security token systems and have yet anything to show for it and we are sad? Why are people trying to do this anyway? oAuth is just an idea.…
Why aren't these things like javascript frameworks where everyone has an idea. Because OAuth is a protocol designed to enable systems developed independently and as such it's useless unless there's an high degree of standardization. It's like saying "why can't we all use our custom version of IP/TCP/HTTP/TLS". It simply wouldn't work. Everyone has unique requirements. Not really; the reality is more "Not everyone has…
Yeah I totally disagree. It could be like any other system, just have a .NET dll, a Ruby gem, whatever to facilitate the basics of that protocol. There's nothing amazing about oAuth. It's hardly a protocol in it's own right. It's just an agreement on transferring some data (some signed, some not signed) on top of another protocol. There's no magic sauce. You don't need standardization because anybody could build a Ruby gem to support any variation of it. Whether people choose to do that is a different question.
I don't understand any of this. Microsoft develops and publishes 'protocols' (used lightly) and everyone hates them because they are pushing workable code out on everyone else... Bunch of people in a committee take three years trying to build the security token system to end all security token systems and have yet anything to show for it and we are sad? Why are people trying to do this anyway? oAuth is just an idea.…
" I don't understand any of this. Microsoft develops and publishes 'protocols' (used lightly) and everyone hates them because they are pushing workable code out on everyone else... " Have you ever tried to write an interoperable authentication system using Active Directory? I'm particularly thinking of the UDP LDAP query and the multiple-byte-order (little-endian and big-endian!) response. " Hey here's a really good…
That doesn't disprove my point. Just because you don't like their approach doesn't mean they don't get points for having an approach. So far oAuth is vaporware and not consistent in almost every implementation yet still effective because it's just an idea.
Because it doesn't really work unless everybody does it the same way.
I disagree. It's not hard to adapt to using oAuth+Twists for a given provider. It's not like it's some secret handshake nobody knows and you can't get into the cult meeting. It's just signing data and exchanging tokens. We don't need a universal standard. We need a universal understanding of the problem we are trying to accomplish and various recommendations for how you might solve it. I think the work on oAuth is already complete.
Earlier quoted context omitted.
http://en.wikipedia.org/wiki/List_of_web_service_specificati... In short, it's collective name for many Web Services specifications that are still heavily in use in "enterprise" world. It's a mess.
WS-* is big because it solves many, many problems. It's also big in the chatty sense because it's XML-based. That does not make it a mess. WS-Trust, WS-Federation etc. have already solved problems that OAuth 2.0 attempts to solve, which doesn't make it bad, as Eran states. Bad is subjective. Whether someone chooses to use it or not depends entirely on the requirement. Choice is good.
- Choice in plug type for electrical devices - Choice in power adapter connection for cell phones - Choice of driving on the left side or the right side of the road - Choice of location for the brake pedal in your car.
Most anything that is used to interface two items, as is oAuth, is better with fewer choices. Choices increase complexity and cost for both sides of the connection and reduce the number of solutions that are compatible. However, for some reason this fact is often lost on technologists.
Earlier quoted context omitted.
http://en.wikipedia.org/wiki/List_of_web_service_specificati... In short, it's collective name for many Web Services specifications that are still heavily in use in "enterprise" world. It's a mess.
WS-* is big because it solves many, many problems. It's also big in the chatty sense because it's XML-based. That does not make it a mess. WS-Trust, WS-Federation etc. have already solved problems that OAuth 2.0 attempts to solve, which doesn't make it bad, as Eran states. Bad is subjective. Whether someone chooses to use it or not depends entirely on the requirement. Choice is good.
- Choice in plug type for electrical devices - Choice in power adapter connection for cell phones - Choice of driving on the left side or the right side of the road - Choice of location for the brake pedal in your car.
Most anything that is used to interface two items, as is oAuth, is better with fewer choices. Choices increase complexity and cost for both sides of the connection and reduce the number of solutions that are compatible. However, for some reason this fact is often lost on technologists.
Upon reading the spec, it seemed that OAuth2 is really just some rough guidelines. Pick and choose what you need for the particular flow you're implementing.
Earlier quoted context omitted.
Why aren't these things like javascript frameworks where everyone has an idea. Because OAuth is a protocol designed to enable systems developed independently and as such it's useless unless there's an high degree of standardization. It's like saying "why can't we all use our custom version of IP/TCP/HTTP/TLS". It simply wouldn't work. Everyone has unique requirements. Not really; the reality is more "Not everyone has…
"Because OAuth is a protocol designed to enable systems developed independently and as such it's useless unless there's an high degree of standardization. It's like saying "why can't we all use our custom version of IP/TCP/HTTP/TLS". It simply wouldn't work." Yeah I totally disagree. It could be like any other system, just have a .NET dll, a Ruby gem, whatever to facilitate the basics of that protocol. There's nothin…