What was the supposed purpose for oath 2.0?
OAuth 2.0 and the Road to Hell
21–30 of 73 posts
Re: OAuth 2.0 and the Road to Hell
#22https://en.wikipedia.org/wiki/Second-system_effect strikes again?
This is simply brilliant.
It's fascinating.
I sometimes think that these people who puch for the "second system" really have no idea the problems they are bringing about. That is, it is innocent.
Hate me for saying so, but there are just a lot of people working in software who lack a sense of wisdom. Folks like Fred Brooks who can see the madness are few and far between. Even rarer are those who both see the stupidity and take action to stop it.
Re: OAuth 2.0 and the Road to Hell
#23Yes, this is sad. And it happens all the time. Exactly the same thing happened to the whole Semantic Web effort at W3C. It basically got overtaken by enterprise and now it is of little interest or use to regular web developers.
No.
The W3C semantic web efforts were run by academics, and were never of interest to enterprise OR to web developers.
Re: OAuth 2.0 and the Road to Hell
#24Interestingly I am developing a single-signon provider as we speak, and I chose OAuth 1.0. I did it mainly because the libraries (jersey-oauth in my case) seemed more mature for 1.0, and the fact that 1.0 is a standard, whilst 2.0 is a draft at the moment.
I do realize that it's slightly more complicated for the client developer, but all things considered I think documenting my API in the best possible way will outweigh the perceived disadvantages.
Re: OAuth 2.0 and the Road to Hell
#25Earlier quoted context omitted.
Just stick with 1.0a?
And if you use Python, rauth will make the experience much easier: https://github.com/litl/rauth/#readme .
If you're consuming an API you use whatever the platform decides on. In that case, this library is helpful. However, I think the real open question is: if you are providing an API, what do you choose?
Re: OAuth 2.0 and the Road to Hell
#26Earlier quoted context omitted.
And if you use Python, rauth will make the experience much easier: https://github.com/litl/rauth/#readme .
If you're consuming an API you use whatever the platform decides on. In that case, this library is helpful. However, I think the real open question is: if you are providing an API, what do you choose?
I think at this point you choose either OAuth 1.0a or to roll your own. If it's not in your future to be a public API, I'd go with rolling your own if you are comfortable writing that kind of code.
Re: OAuth 2.0 and the Road to Hell
#27I 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. Hey here's a really good way to handle things and if you do it this way it has some really great benefits.
Why aren't these things like javascript frameworks where everyone has an idea. I don't think it's practical that every sdk and framework will use one security system that was agreed upon. It's just not going to happen. Everyone has unique requirements.
I think he's just upset that more people have concerns and needs and nobody can compromise to solve all of them. Well yeah. Naturally. They wouldn't be needs if people could just overlook them for someone else's idea on how to do it. They would just be problems people are looking for someone else to solve.
Re: OAuth 2.0 and the Road to Hell
#28Earlier 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?
No, the HMAC-SHA1 signature is the only crypto needed in OAuth 1.
Like literally every programming language should have an implementation of HMAC-SHA1 around and lacking that, at least a SHA1 implementation. It's pretty trivial to build HMAC- if you have around. A working python implementation is literally 12 lines long.
Now if you don't have a SHA1 implementation in your programming language, that's a different problem.
Re: OAuth 2.0 and the Road to Hell
#29Yes, this is sad. And it happens all the time. Exactly the same thing happened to the whole Semantic Web effort at W3C. It basically got overtaken by enterprise and now it is of little interest or use to regular web developers.
No. The W3C semantic web efforts were run by academics, and were never of interest to enterprise OR to web developers.
Yes, academics too. Also I am seeing lots of very loud enterprise software people around those standards. Yes, those are very small enterprise software companies.
Re: OAuth 2.0 and the Road to Hell
#30https://en.wikipedia.org/wiki/Second-system_effect strikes again?
This is simply brilliant. It's fascinating. I sometimes think that these people who puch for the "second system" really have no idea the problems they are bringing about. That is, it is innocent. Hate me for saying so, but there are just a lot of people working in software who lack a sense of wisdom. Folks like Fred Brooks who can see the madness are few and far between. Even rarer are those who both see the stupidit…
I think there's a "human factors" problem in action with second systems. The first system needs to be allowed to age before the second one becomes worthwhile - simply because more understanding will exist of both the problem domain, and how it was solved before.
And if it's different people doing the second one, watch out.