[oauth] Re: Distinction between Request Token and Access token
Thank you both for your fast replies. Indeed, I was wrong when I said that the distinction between both tokens would dramatically increase the response time. I misunderstood the spec, as I thought that one pair Request Token -- Access Token only granted access to one protected resource (namely, one URL). I see that there are no limitations in that aspect, and a single pair of tokens grants access to multiple protected resources. I'm not sure whether this is good or not. Maybe in some Web applications it would be desirable a finer grained protocol that can grant access to some specific (and no more) resources. For example, instead of the canonical example of a photo hosting service I can think about a site hosting medical records - extremely confidential information. I mean, there is a BIG difference between allowing an application acting as Consumer to know if I've had a flu recently, and giving it free access to all the information concerning my health. This all or nothing approach taken in OAuth may not fulfill the requirements of some Web applications. And on the other, the problem of temporal states between tokens still remains. I don't know how this issue would affect to the performance of large-scale Web applications. In other words, does OAuth scale well? Thanks a lot for your help, I really appreciate it (receiving a PhD is easier with the help of a community ;-) ). Greetings, Jorgito --~--~-~--~~~---~--~~ 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: Reminder: OAuth IETF Mailing List oa...@ietf.org
I'll start with the IPR question. The IETF has a very simple set of rules with regard to its IPR policies. The full rules are available at: https://datatracker.ietf.org/ipr/about/. In general, everyone is an individual, and most of the IPR requirements are about copyrights. There is a disclosure requirement for patents, which in general says that if you are aware of any patent related to the work being done, you must disclose it. This is a personal requirement, not for your company. Most companies do not require strict review before IETF participation. But you should check with your employer. An important note about IETF work (usually an RFC) is that it is only guaranteed to give you some copyright license. There is no requirement for RFCs to be free (and some actually have royalties associated with them). It is the decision and responsibility of the editors to apply a licensing policy. With regard to OAuth at the IETF, I plan to duel license it under the IETF rules and the OWF license once it is ready. I hope it will be ready before the IETF WG charter is finished so that it can be stated clearly. If you are active on this list, you should have no problem joining the IETF list. --- It is hard to tell what will be in scope for the IETF version of OAuth. I expect the spec to be cleaned up, made easier to read, and mostly address interoperability and security issues. I am not expecting much in terms of new features, at least not as part of the core charter. The most important thing is that we are going to break backward compatibility in some places to accommodate stronger security requirements. We are also going to make the protocol somewhat less flexible, such as removing support for URI query parameter (just an example, not a proposal or decision). Right now OAuth is more of a framework than a truly interoperable specification. There are just too many options. Another example is the fact that the HTTP methods of the three calls are not explicitly defined (should be a POST). Strictly speaking, OAuth allows all these changes since it has many extension and deviation points built in as part of its design. So you could think of the IETF version as being a fully-compliant sub-type of OAuth, that is more restrictive. The importance of this work is that it will have impact on those implementing it, assuming they will want to support the newer version. So the interest in this work is as important as it was in the original specification. I'll put it this way: if you care about the details, you need to join the new effort. EHL --~--~-~--~~~---~--~~ 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: Authentication API protected with OAuth
Most of the major providers that I know use SSL behind netscalars too for their login servers. Usually netscalers persist the connections with the origin servers so there is still huge performance improvement while securing the data in transit in the internal network. Of course passwords still have to be sent over post not just to get them off of server logs but to prevent the browsers from storing it in users history. -Praveen On 1/30/09, George Fletcher gffle...@aol.com wrote: Agreed. I don't think this solution works for everyone. Though from that post it seems that unless the site is using SRP the password is going in clear-text over the wire (SSL) for sites that store salted hashes. (I just used Live HTTP headers to verify a major online service provider and this is the case. The password is in clear-text over SSL) If the site uses something like a netscaler to offload their SSL, then the clear-text password is in the clear inside the company's network. Hopefully, most sites using this scheme make sure the password is specified in a POST to ensure it's not being stored in clear-text in the server's log files:) Thanks, George Brian Eaton wrote: On Wed, Jan 28, 2009 at 6:41 PM, George Fletcher gffle...@aol.com wrote: The request is only valid if the receiving authentication system can generate the signature using the password for that user. Lots of authentication servers can't do that, because they do not keep a clear-text version of the user's password. Instead they store a salted hash. I love Thomas Ptacek's summary of password storage schemes: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ -- Chief Architect AIM: gffletch Identity Services Work: george.fletc...@corp.aol.com AOL LLC Home: gffle...@aol.com Mobile: +1-703-462-3494 Office: +1-703-265-2544 Blog: http://practicalid.blogspot.com --~--~-~--~~~---~--~~ 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] Java OAuthClient.access
I propose to extend the Java oauth-core library to better support
accessing protected resources, as follows. Please let me know if this
is a bad idea, or there's a better way.
In brief, I propose to add a method to OAuthClient:
/** Send a request and return the response. */
public OAuthResponseMessage access (OAuthMessage request,
ParameterStyle style) throws IOException;
Unlike the existing 'invoke' method, it won't try to decide whether
the response indicates success; it will merely return the response. A
typical caller would evaluate the response, something like this:
OAuthClient client = ...;
OAuthAccessor accessor = ...;
OAuthMessage request = new ...;
request.addRequiredParameters (accessor);
OAuthResponseMessage response = client.access (request,
ParameterStyle.AUTHORIZATION_HEADER);
switch(response.getHttpResponse().getStatusCode()) {
case 200: ...
case 400: ...
I'm a little worried about feature creep: this is a step toward a
general purpose HTTP client library. But it's a tolerably small step,
I hope. I don't want to try to reproduce all the features of the
Apache HTTP client libraries.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
