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 <a...@yahoo-inc.com> 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
