Q:

What is the benefit of the shared secret in OAuth 1.0A?

What is the benefit of the OAuth 1.0A shared secret?
From what I understand, a client can register with a protected resource server in which the client receives both a client identier and a shared secret in return. Even though I've read the OAuth 1.0A spec over and over -- I'm having a hard time understanding two questions:

Why the shared secret is needed at all? 
Why isn't the client identifier good enough for the server to validate the client? What extra security benefit, if any, does the shared secret provide? 

I'm not looking for you to quote the spec -- at this point i need more simple clarification as I'm having a hard time understanding what the spec says (it really doesn't go into detail on the shared-secret anyway).

A:

The secret is needed to generate a signature for the request. Without the signature, you cannot be sure of two things:

that a third party did not intercept the request made by the client, modify it, and then pass it along to do something entirely different
that a third party is not impersonating a valid consumer and making requests without their involvement at all

Provided that only the provider and consumer know the secrets, a signature and verification prevents these unauthorized requests. This post goes into detail about the idea behind signatures. In particular, the follow excerpt is very relevant to your question:

By itself, hashing does not verify the identity of the sender, only data integrity. In order to allow the recipient to verify that the request came from the claimed sender, the hash algorithm is combined with a shared secret. If both sides agree on some shared secret known only to them, they can add it to the content being hashed. This can be done by simply appending the secret to the content, or using a more sophisticated algorithm with a built-in mechanism for secrets such as HMAC. Either way, producing and verifying the signature requires access to the shared secret, which prevents attackers from being able to forge or modify requests.

