[oauth] Re: new to oauth
Hi, Iam passing accessToken as null now.Even then i get the same exception that token has been expired inside SampleOAuthProvider.getAccessor() Inside this method,it is checking for tokens and since they are coming as null accessor object is set to null as a result of which we are getting OAuthProblemException(token_expired); My assumption is that what EchoServlet(as suggested by John and Robert) is following 3 legged verification. So request you to suggest 2-legged way of verification. Regards, Anuradha --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Details on OAuth Session Extension?
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 rwi...@gmail.com 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 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
[oauth] Re: Details on OAuth Session Extension?
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 a...@yahoo-inc.com mailto: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 -- Chief Architect Identity
[oauth] Scaling OAuth providers
I've started a page on the OAuth WIki specifically with best practices for scaling OAuth providers. The differences between large and small providers are large so I've approached it from both angles. Please add to it. http://wiki.oauth.net/Scaling-OAuth-providers -- 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 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 -~--~~~~--~~--~--~---
[oauth] Re: new to oauth
Sorry I believe you are correct that the EchoServlet is currently written to
only support 3-Legged OAuth. I think by changing the EchoServlet in the
following ways it should support 2-Legged.
1) Instead of
OAuthAccessor accessor = SampleOAuthProvider.getAccessor(requestMessage);
Use
final OAuthConsumer consumer =
SampleOAuthProvider.getConsumer(requestMessage);
final OAuthAccessor accessor = new OAuthAccessor(consumer);
2) You may also need to add the init(ServletConfig c) method to the
EchoServlet to load the properties file.
public void init(ServletConfig config) throws ServletException {
super.init(config);
try {
SampleOAuthProvider.loadConsumers(config);
}catch(IOException e) {
throw new ServletException(e);
}
}
Sorry again for my poor guidance,
Rob
On Fri, Oct 16, 2009 at 2:08 AM, Anuradha Thota anuradha.th...@gmail.comwrote:
Hi,
Iam passing accessToken as null now.Even then i get the same exception
that token has been expired inside SampleOAuthProvider.getAccessor()
Inside this method,it is checking for tokens and since they are coming
as null accessor object is set to null as a result of which we are
getting OAuthProblemException(token_expired);
My assumption is that what EchoServlet(as suggested by John and
Robert) is following 3 legged verification.
So request you to suggest 2-legged way of verification.
Regards,
Anuradha
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[oauth] Re: Details on OAuth Session Extension?
Hi Robert, The text in the Yahoo documentation is not factually correct - however it doesn't really matter for client developers who are calling our OAuth protected services. We currently do not allow developers to change the scopes for their consumer keys after we've issued them. The slang that we use within Yahoo is that the set of scopes is baked into the consumer key, which probably inspired our doc writer to write that the scopes are embedded within the consumer key. The actual implementation is that we record the scopes available to the consumer key in a database, and we query the database before showing the OAuth Approval screen to the user. The scopes are not encrypted inside the consumer key. It is technically possible for a yahoo consumer key to have its scopes changed after it's been issued, however we do not currently allow it. We do however, embed the scopes inside the access token. Since Yahoo Access Tokens expire, but consumer keys do not, it's technically possible for a user to authorize additional scopes for an application, as long as the consumer gets a new Access Token after the scopes have been changed. This is essentially the flow that George Fletcher mentioned previously. We have received feedback from developers that they would like the ability to request additional scopes for their consumer keys. For example, applications may want to initially request a minimum set of scopes to avoid overwhelming their new users by asking for all possible scopes. Over time, the application can ask for additional scopes when needed. Another example is that applications are upgraded over time, and newer versions of the app may want to use additional scopes as they are upgraded. Hope that helps, Allen Robert Winch wrote: 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[oauth] Re: Details on OAuth Session Extension?
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 rwi...@gmail.com 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 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
[oauth] Re: Details on OAuth Session Extension?
A feature I'd also like to have as a consumer is the reverse operation - starting with a broad scope for initial setup, then narrowing scope before storing my secret anywhere other than local memory. On Friday, October 16, 2009, Allen Tom a...@yahoo-inc.com wrote: Hi Robert, The text in the Yahoo documentation is not factually correct - however it doesn't really matter for client developers who are calling our OAuth protected services. We currently do not allow developers to change the scopes for their consumer keys after we've issued them. The slang that we use within Yahoo is that the set of scopes is baked into the consumer key, which probably inspired our doc writer to write that the scopes are embedded within the consumer key. The actual implementation is that we record the scopes available to the consumer key in a database, and we query the database before showing the OAuth Approval screen to the user. The scopes are not encrypted inside the consumer key. It is technically possible for a yahoo consumer key to have its scopes changed after it's been issued, however we do not currently allow it. We do however, embed the scopes inside the access token. Since Yahoo Access Tokens expire, but consumer keys do not, it's technically possible for a user to authorize additional scopes for an application, as long as the consumer gets a new Access Token after the scopes have been changed. This is essentially the flow that George Fletcher mentioned previously. We have received feedback from developers that they would like the ability to request additional scopes for their consumer keys. For example, applications may want to initially request a minimum set of scopes to avoid overwhelming their new users by asking for all possible scopes. Over time, the application can ask for additional scopes when needed. Another example is that applications are upgraded over time, and newer versions of the app may want to use additional scopes as they are upgraded. Hope that helps, Allen Robert Winch wrote: 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
