Hi Guys, I am not trying to troll with this post, but I do feel that this is very important if we don't want OAuth to fragment.
I have intentionally been avoiding work with Yahoo's OAuth implementation until a client of mine asked me to do so. Doing that I've been working on Yahoo support in the Rails OAuth Plugin. http://github.com/pelle/oauth-plugin/blob/019761c04b690cb92bf4dc7280e977f0e1c6eb36/lib/oauth/models/consumers/services/yahoo_token.rb So I missed this proposed OAuth Session Extension standard the first time around. In case you don't know what this is, I didn't until recently. This is the reason everyone is having difficulties writing OAuth apps towards Yahoo using standard libraries. Google "yahoo oauth" and you will find lots of links to threads of people trying and giving up on this. The spec is here: http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/spec.html The Yahoo description is here: http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html I was wondering then, what is the reason for this "YAuth" standard? A look in the spec gives no clue of the reasoning for this extra complexity and I finally discovered it in the original proposal on the OAuth Extensions list: http://groups.google.com/group/oauth-extensions/browse_thread/thread/8413622c6e585054# Allen Tom from Yahoo says "Large service providers may have difficulty adopting OAuth in its current form. In order to simply integration for developers, we'd like to conform with the current OAuth specification as much as possible. We'd like to propose the following OAuth Session extension for SPs who have web services which run mostly independently from from their Auth service." So in order to simplify integration for us they have given us a really complex standard we have to deal with. Allen continues: "Very large service providers may have a distributed architecture in which the service endpoints are able to cryptographically verify the authentication credentials without calling back to a central database. Permission revocation is implemented by issuing consumers a relatively short lived session credential, and requiring consumers to periodically obtain new session credentials from a central authorization service. The authentication service performs the necessary checks before issuing new session credentials." So the problem is one of Yahoo's internal architecture. I can appreciate the mathematical beauty of cryptographically verifying the credentials, but this seems a case of outsourcing your architectural debt to your customers. I assume this also explains the giant 800 byte tokens Yahoo issues. "Although it is technically possible for SPs to build an OAuth translation layer on top of their existing services, the cost may involve additional latency and decreased reliability if OAuth verification required a query to a database located in a very distant datacenter. " Exactly, it is possible even in a very large and distributed SP to do so. Just look at Google, who were able to cleanly work within the OAuth standard. I find it extremely bad and damaging to the OAuth world as a whole when you can't stick with standards. I have no problems with true extensions, such as the OpenID/OAuth extension as they are optional. But the OAuth Session Extension or YAuth as I think it really should be called requires core changes to the basic OAuth layer for us who actually implement these things. So what do I want from this rant? I want Yahoo to face up to their responsibilities to their developers and implement what they advertise they implemented an actual OAuth compliant SP. The IPR group bent over backwards to the requests from Yahoo legal to get them into the OAuth process. Now they want all of us developers (the foot soldiers of the OAuth war) to handle their dirty work. I would prefer Yahoo sticking with BBAuth than calling what they support OAuth. OAuth is complicated as it is for the average developer as evidenced by many of the questions I get on my blog, on the mailing lists, stackoverflow etc. Developing the Ruby OAuth library and the Rails plugin, I've tried to hide the complexity for your average developer. YAuth directly sabotages this as it destroys the whole standard OAuth flow, that developers are finally able to understand. Yahoo needs to implement OAuth if they want the support of us developers. Until they do so, I will remove support for Yahoo from the OAuth Rails Plugin library. I will implement Yahoo support for my client, but I have stopped development of it for the OAuth Ruby Plugin as I think that will only encourage such behavior in the future. Yahoo has great people working within them whom I really respect. If they won't change their flow they should at least be willing to put some of their developers at work to support the developers. P -- http://agree2.com - Reach Agreement! http://extraeagle.com - Solutions for the electronic Extra Legal world http://stakeventures.com - Bootstrapping blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
