Sure, I could have been clearer: I'm actually not concerned at all here about the generation and distribution of tokens.
That's a valid concern, and rightly the focus of much of the effort in OAuth. But what I'm trying to consider is a situation where that's not an issue. Imagine that I as the Service Provider have entirely solved the problem of granting Access Tokens to my satisfaction, outside of OAuth; maybe I print them out on a bit of paper and cycle down the road to hand them out to my Users. There's no meaningful Consumer in the loop here. Given that that's the case, how can I best use these Access Tokens, within the OAuth framework, to let my Users make requests of my Service? What I'm suggesting is that if I invent a Consumer whose key and secret are both the empty string, then my Users (in possession of an Access Token which I cycled down to give them) can make requests over https as described in my previous method; without worrying about constructing signatures, with a minimum of things to remember. Essentially, they can do simple string substitution into a OAuth header template, to generate valid OAuth-authenticated requests to my service. This makes their life much easier in terms of writing simple throw- away scripts against my service. I could get the same effect from using HTTP Basic with opaque tokens for usernames (and, indeed, this is what I do at the moment in reality) - I'm wondering if this could be done within OAuth authentication. Does this make my point clearer? Toby On May 15, 8:20 am, Manish Pandit <[email protected]> wrote: > On May 14, 8:37 am, Toby <[email protected]> wrote: > > > > > I'm thinking about simplified OAuth setups, minimizing the load on the > > client, in situations where the Consumer is not a terribly meaningful > > concept - where there is a Service, and Users who interact directly > > with the service (by, for example, typing in curl commands at a shell > > interface). This is the problem addressed by HTTP Auth, of course, but > > I want to see if I can make this work within the OAuth framework. > > > I'm aware of "Using OAuth for Consumer > > Requests"http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/... > > but I'm trying to approach it from a different perspective. > > > Reading the OAuth spec literally, I see nothing which requires the > > Consumer Key & Secret to be non-empty strings. If I let these be empty > > strings, then this makes construction of OAuth requests much simpler. > > > What I'm envisaging is registering one such Consumer on my service, > > and letting Users create Tokens on the back of this Consumer, for use > > in their own use-once-and-throw-away scripts. If I restrict access to > > only come through https urls, then I can ignore all signature methods > > other than PLAINTEXT. > > > This reduces OAuth authentication to a single HTTP header, looking > > like: > > > Authorization: OAuth > > oauth_consumer_key="",oauth_token="tokenstring",oauth_signature_method="PLA > > INTEXT",oauth_signature="&secretstring",oauth_timestamp="1000000000",oauth_ > > nonce="random" > > > which is trivially easy to construct, and can be typed in as a command- > > line option to curl. > > > Essentially, this would work like API tokens a la Flickr, but using > > the OAuth authentication framework. > > > To place it in the context of "Using OAuth for Consumer Requests" > > above, this lets you retain the existing three-legged framework, while > > essentially ignoring one of the legs, without (as best I can tell) > > needing to extend the spec, or rewrite libraries. > > > For what it's worth, I've managed to get this working with curl > > talking to an unpatched version of the Python OAuth library > > > Does this make sense, or am I barking up the wrong tree? > > > Toby > > Not sure if I understand - are you saying that instead of a provider > generating the tokens and secrets for the consumers, the end users > will create their own tokens and secrets? Can you explain your use > case a little further? > > -cheers, > Manish --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
