Two-legged OAuth is similar to a client supplying its credentials to the
server via the
Authorization header using basic or digest
authentication with no delegation involved. Note that the OAuth
specification does not specify this style of authentication, but it is
widely used as a means of authenticating a client with a server.
You want to know how to implement two-legged OAuth to authenticate client requests.
Two-legged OAuth involves the following steps:
The client requests the server for a consumer key and a consumer secret out of band. The consumer key is an identifier for the client. The consumer secret is a secret shared between the client and the server.
When making a request to access a protected resource, the
client includes an
Authorization header containing
the consumer key, the signature method and signature, a timestamp,
a nonce, and optionally the version of the OAuth protocol.
The server verifies the signature before granting access to the resource. This approach is called two-legged since there are just two parties involved in the authentication flow.
Use two-legged OAuth when the server needs to the authenticate the client to provide access control, logging, metering, rate limiting, metrics, etc.
Two-legged OAuth is well suited for cases involving several
clients accessing protected resources on a server. The server can
issue a consumer key and a secret to each client and require that
clients submit an