I am reading:
http://oauth.net/core/1.0a

And this is how I understand how 2 legged oAuth might work.  If I get
something wrong, please let me know.  I am using it as a means of
authenticating requests to an API

1) I tell my SP application to generate a Consumer Key and a Consumer
Secret.  The Consumer Key is not used to aide in the creation of the
consumer secret.  For the sake of the example, lets say I get my 2
keys as follows (php style)

$consumer_key = hash('md5', 1);
$consumer_secret = hash('md5', 2);

from this point my understanding of of 2 legged is to basically take
out the oauth_token bits

So the Consumer takes their $key and $secret, and now wishes to make
requests against the API

I would imagine all we would need at this point is what is described
in
6.1.1.  Consumer Obtains a Request Token (http://oauth.net/core/
1.0a#auth_step1)

The consumer builds a request to the API, assumes that the consumer
and service provider have agreed on how the signature will be
constructed?

The consumers  request looks like this ( I don't need realm):

Authorization: OAuth,
oauth_consumer_key="$consumer_key",
oauth_signature_method="HMAC-SHA1",
oauth_signature="$signature",
oauth_timestamp="$time",
oauth_nonce="$nonce",
oauth_version="1.0"

In the above $consumer_key is the $consumer_key generated from hash
('md5', 1)

$signature
My understanding of $signature is that it is the way for the Service
Provider to know that the incoming request is coming from someone that
knows the Consumer Secret, to that end, the Service Provider need to
be able to reproduce the signature.  The signature method tells the
service provider how the signature was hashed

So for the sake of the example, the Consumer produces the signature as
follows (again, PHP style):
$signature = hash_hmac('sha1', $consumer_key, $consumer_secret);

Now, the $signature could be generated a different way, so long as it
was hashed under the provided oauth_signature_method.
eg (adding a shared salt that both the consumer and the service
provider know about):

$signature = hash_hmac('sha1', $consumer_key.$shared_salt,
$consumer_secret);

Now, in both cases, when the Service Provider receives the request it
can look at the signature, and perform it's own hash, under the same
rules that the consumer generated their hash.  Assuming service
providers hash is equal to the signature, the Service Provider knows
the request is signed, and can continue.  This is the reason the
consumer does not want to let anyone know what it's secret is.  The
$consumer_secret is effectively the password.

Do I have the right idea for oauth_signature/$signature?

above $time would just be time();

oauth_nonce / $nonce, aside from marking request, so they cannot be
used again, this is another place where the request can effective be
signed. so long as both the service provider know how it was created,
so that it can validate it.  One possible way to create this value
would then be:

$nonce = hash('md5', $time.$consumer_secret.$consumer_key);

Assuming the service provider knows the Consumer is using $time as
part of the hash(which it will be receiving in oauth_timestamp), it
should always generate a unique value.

The service provider will store the $nonce's so that it can check to
ensure one is not being reused.  It would be up to the service
provider to decide when / if to ever remove stored nonce values.

Do I have the right general idea for oauth_nonce/$nonce


In a 2 legged situation, this should be all that is needed, since an
individual user's authorization is not required.  Is that correct?
Each request to the service provider can now be verified as coming
from a specific consumer.

I really appreciate anyone who takes the time to read this and point
me in the right direction if I have something wrong.



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

Reply via email to