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="PLAINTEXT",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
-~----------~----~----~----~------~----~------~--~---
