Hi Robert, As I'm sure you've figured out from the extension spec, it allows a Consumer to "upgrade" scopes in a dynamic way based on user consent. This is the model we use at AOL where users can be presented with a consent dialog if they have not yet consented to allow the Consumer to access that particular resource. I believe this is an important feature, not only for developers (they only need to keep track of one consumer key/token and one access key/token per user) but also for users who can selectively release information as it is requested and only under their consent.
Thanks, George Robert Winch 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] > <mailto:[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 > > > > > -- Chief Architect Identity Services AOL LLC --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
