Group items tagged

In everyday web transactions, the most common credential used is the username-password combination. OAuth's primary goal is to allow delegated access to private resources. This is done using two sets of credentials: the Consumer identifies itself using its Consumer Key and Consumer Secret, while the User is identified by a Token and Token Secret.

But while the Consumer credentials work much like a username and password, the User is represented by a Token which is different than their actual username and password. This allows the Service Provider and User greater control and flexibility in granting Consumer access.

OAuth includes two kind of Tokens: Request Token and Access Token. Each Token has a very specific role in the OAuth delegation workflow.

While mostly an artifact of how the OAuth specification evolved, the two-Token design offers some usability and security features which made it worthwhile to stay in the specification. OAuth operates on two channels: a front-channel which is used to engage the User and request authorization, and a back-channel used by the Consumer to directly interact with the Service Provider. By limiting the Access Token to the back-channel, the Token itself remains concealed from the User. This allows the Access Token to carry special meanings and to have a larger size than the front-channel Request Token which is exposed to the User when requesting authorization, and in some cases needs to be manually entered

The request signing workflow treats all Tokens the same and the workflow is identical. The two Tokens are specific to the authorization workflow, not the signature workflow which uses the Tokens equally. This does not mean the two Token types are interchangeable, just that they provide the same security function when signing requests.

OAuth uses digital signatures instead of sending the full credentials (specifically, passwords) with each request. Similar to the way people sign documents to indicate their agreement with a specific text, digital signatures allow the recipient to verify that the content of the request hasn't changed in transit.

In turn, the recipient performs the same workflow to calculate the signature of the request and compares it to the signature value provided. If the two match, the recipient can be confident that the request has not been modified in transit.

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.

The benefit of this approach compared to the HTTP 'Basic' authorization scheme is that the actual secret is never sent with the request. The secret is used to sign the request but it is not part of it, nor can it be extracted (when implemented correctly).

In OAuth, the shared secret depends on the signature method used. In the PLAINTEXT and HMAC-SHA1 methods, the shared secret is the combination of the Consumer Secret and Token Secret. In the RSA-SHA1 method, the Consumer Private Key is used exclusively to sign requests and serves as the asymmetric shared secret. The way asymmetric key-pairs work, is that each side — the Consumer and Service Provider — use a one key to sign the request and another key to verify the request. The keys — Private Key for Consumer and Public Key for the Service Provider — must match, and only the right pair can successful sign and verify the request. The advantage of using asymmetric shared secrets is that even the Service Provider does not have access to the Consumer's Private Key which reduces the likelihood of the secret being leaked.

When implementing OAuth, it is critical to understand the limitations of shared secrets, symmetric or asymmetric. The Consumer Secret (or Private Key) is used to verify the identity of the Consumer by the Service Provider. In case of a web-based Consumer such as web server, it is relatively easy to keep the Consumer Secret (or Private Key) safe.

This does not prevent using OAuth within such application, but it does limit the amount of trust Service Provider can have in such public secrets. Since the secrets cannot be trusted, Service Provider must treat such application as unknown entities and use the Consumer identity only for activities that do not require any level of trust, such as collecting statistics about applications.

Using OAuth for simple sign-in has the same user experience as HTTP 'Basic', but when used over an insecure channel OAuth provides much greater security.

The signature and shared secret provide some level of security but are still vulnerable to attacks. The signature protects the content of the request from changing while the shared secret ensures that requests can only be made (and signed) by an authorized Consumer. What is missing is something to prevent requests intercepted by an unauthorized party, usually by sniffing the network, from being reused. This is known as a replay attack. As long as the shared secrets remains protected, anyone listening in on the network will not be able to forge new requests as that will require using the shared secret. They will however, be able to make the same sign request over and over again.

To prevent compromised requests from being used again (replayed), OAuth uses a nonce and timestamp. The term nonce means 'number used once' and is a unique and usually random string that is meant to uniquely identify each signed request. By having a unique identifier for each request, the Service Provider is able to prevent requests from being used more than once.

Using nonces can be very costly for Service Providers as they demand persistent storage of all nonce values received, ever. To make implementations easier, OAuth adds a timestamp value to each request which allows the Service Provider to only keep nonce values for a limited time.

OAuth defines 3 signature methods used to sign and verify requests: PLAINTEXT, HMAC-SHA1, and RSA-SHA1.. PLAINTEXT is intended to work over HTTPS and in a similar fashion to how HTTP 'Basic' transmits the credentials unencrypted. Unlike 'Basic', PLAINTEXT supports delegation. The other two methods use the HMAC and RSA signature algorithm combined with the SHA1 hash method.

HMAC-SHA1 offers a simple and common algorithm that is available on most platforms but not on all legacy devices and uses a symmetric shared secret. RSA-SHA1 provides enhanced security using key-pairs but is more complex and requires key generation and a longer learning curve.

Not only must they both use the same algorithm and share secret, but they must sign the same content. This requires a consistent method for converting HTTP requests into a single string which is used as the signed content — the Signature Base String