Hi Pelle, When we built our OAuth implementation, we considered many possible solutions, including solutions very similar to the ones that you described. We even built a few prototypes.
However, only after thoroughly investigating all other alternatives, we found that we could not implement OAuth 1.0 without using the Session Extension. The only other alternative would be to continue using our proprietary BBAuth interface. We have talked to other SPs who have similar requirements, so it is possible that other SPs may also use the Session Extension in the future. Again, I do appreciate the feedback, perhaps there are some things that we can do to make things easier for client developers. For instance, since the Access Token is not long lived, perhaps we can relax the signature requirement. Our developers generally have more problems debugging signature issues compared to implementing the session extension. Allen Pelle Braendgaard wrote: > I'm sorry but I can't help thinking that it is wrong putting the > scalability burden on your users and not handling it internally. I may > be wrong but I think there is little to none support for the Session > Extension protocol in any of the libraries. > > Couldn't a similar system be created without session extension where > individual servers/datacenters/clusters have you request validation of > the token from a central security authority and store the resulted > data locally in a memcache or similar with a 10 minute expiry? That > would eliminate all but the initial database request. I've outlined > this approach here: > > http://stakeventures.com/articles/2009/10/06/why-yauth-is-not-oauth-4 > > It wouldn't even need to verify it, it would only need to return a > http 200/403 for the token and still let the heavy work be done > locally in the server. > > An alternative approach would be to verify it 100% on the server but > have a federated Token Revocation List. If a user revokes the token > this gets added to a central revoked token feed that all the federated > servers subscribe to. > > All I'm saying is there are lots of solutions that don't involve > adding additional burden to your users. > > I think the Yahoo scheme is clever and I do like the idea of > encrypting data within the token. > > If you had to do it. I don't think that there would be any security > issue with encrypting the scope within the AccessToken as long as it > is signed. I of course don't know what is in Yahoo's token, but it > would seem obvious to me that it would need to include both consumer > and token secrets to completely eliminate the database call. > > A real lesson from this is that OAuth is still new so there is still > very little knowledge out there on how to scale it. I think we should > probably start a new thread on this and turn it into a wiki page that > people can use. > > P > > > On Thu, Oct 15, 2009 at 11:49 PM, Robert Winch <[email protected]> wrote: > >> Allen, >> >> Thank you for your reply...it was very helpful. I had some thoughts on how >> to best implement the OAuth Session Ext, but wanted some feedback from the >> community to make sure I am not missing something. Your response has >> confirmed that I was on the right track. >> >> The one thing that I am still wondering about is the question that I worded >> poorly. Let me try to rephrase. I noticed that the Yahoo documentation >> states "the scopes (permissions) are embedded within the Consumer Key and >> cannot be changed. If you change the scopes for a particular application, >> Yahoo! issues a new Consumer Key." [1]. I was thinking it would make more >> sense to embed scopes in the AccessToken (as you have stated). This allows >> consumers to make requests to numerous different sets of resources without >> needing to have a different consumer key generated. The reason why I ask >> this is to ensure that I have not overlooked something. Are there problems >> (i.e. security concerns) with putting scopes in the Access Token? Perhaps I >> misunderstood the documentation and the scopes are actually in the Access >> Token (this appears likely from the way I am understanding your response). >> >> Thanks again for your help, >> Rob >> >> [1] http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html >> >> On Thu, Oct 15, 2009 at 3:17 PM, Allen Tom <[email protected]> wrote: >> >>> Robert Winch wrote: >>> >>>> I would like to leverage OAuth without having to hit a database to >>>> validate each request. In addition, I would like to avoid using public >>>> key's >>>> since the performance is slower and distribution of the public keys can be >>>> difficult. These requirements have led me to investigating the OAuth >>>> Session >>>> Extension. >>>> >>> Hi Robert, >>> >>> You've listed many of the reasons which led to Yahoo's adoption of the >>> Session Extension. >>> >>>> * Why does Yahoo embed the scopes inside the consumer id and not the >>>> access token? This would allow scopes to change per request. Are there >>>> problems with doing it this way? >>>> >>> How and where the SP embeds the scopes into the credential is really up to >>> the implementor. I'm a little unclear as to what you mean by having the >>> scopes change per request. >>> >>> In Yahoo's implementation, we embed the scopes into the Access Token, and >>> the Protected Resource endpoint decrypts the Access Token and verifies that >>> Access Token has the proper scope before returning the resource to the >>> Consumer. All Yahoo OAuth Protected Resources are able to verify an Access >>> Token locally, in memory, without having to do a DB lookup. Eliminating the >>> DB lookup is very desirable since many of Yahoo's services are globally >>> distributed and are built on heterogeneous platforms, making it very costly >>> and difficult for query a central OAuth DB to ensure that both the user is >>> valid, and the consumer is authorized. >>> >>> In the very unlikely event that a Protected Resource is compromised (aka >>> hacked), we'd like to be able limit our exposure by only allowing >>> credentials with limited lifetimes to be present on our front end hosts. In >>> aftermath of a security compromise, a Service Provider would need to revoke >>> all Access Tokens that were sent to the compromised server, because the >>> Attacker may have copied them. Service Providers that implement the Session >>> Extension may choose to just wait for all Access Tokens to expire before >>> restoring service. Consumers can just refresh their Access Tokens (using the >>> Session Extension) without forcing users to reauthorize the Consumer. >>> >>> >>> >>>> * How is the consumer id created (to include scopes)? >>>> >>> This is really up to the SP. One possible implementation would be to >>> somehow encrypt (and sign) the scopes into the consumer key. >>> >>> >>>> * How is the access token formulated to include information on validating >>>> the signature? >>>> >>> Without going into too many details about our OAuth implementation, our >>> servers are able to decrypt an Access Token and determine the secret needed >>> to verify the oauth_signauture, as well as the userid of the user, and the >>> scopes that have been authorized. >>> >>> Hope that helps, >>> Allen >>> >>> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
