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 -~----------~----~----~----~------~----~------~--~---
