Here are some related extensions to OAuth. The first extension (Accessor Secret) is a prerequisite for the others, but the others may be adopted independently. For example, a Service Provider may support HMAC-SHA1-Accessor but not support a Variable Accessor Secret.

To discuss these extensions, please use the Accessor Secret thread in the Google Group OAuth Extensions.

Extension: Accessor Secret

The Service Provider MUST enable Consumer Developers to establish an Accessor Secret, in addition to the Consumer Key and Consumer Secret. The procedure for establishing the Accessor Secret is entirely up to the Service Provider. The Accessor Secret MAY be empty, or MAY be the same as the Consumer Secret.

If either participant doesn't support this extension, the Accessor Secret MUST be the same as the Consumer Secret. (This is compatible with OAuth Core.)

Extension: HMAC-SHA1-Accessor signature method

This signature method is just like HMAC-SHA1 (OAuth section 9.2), except that the Accessor Secret is used instead of the Consumer Secret. That is, the key is the values of the Accessor Secret (not the Consumer Secret) and the Token Secret, encoded and concatenated with '&'.

This signature method MUST NOT be used when the Accessor Secret and Consumer Secret are the same, and SHOULD NOT be used to sign a request for a token. (The HMAC-SHA1 method may be used in either case.)

A Service Provider MUST reject a request with this signature method, unless it supports this signature method and the Accessor Secret extension.

Extension: PLAINTEXT-Accessor signature method

This signature method is just like PLAINTEXT (OAuth section 9.4), except that the Accessor Secret is used instead of the Consumer Secret. That is, the signature is the values of the Accessor Secret (not the Consumer Secret) and the Token Secret, encoded and concatenated with '&'.

This signature method MUST NOT be used when the Accessor Secret and Consumer Secret are the same, and SHOULD NOT be used to sign a request for a token. (The PLAINTEXT method may be used in either case.)

A Service Provider MUST reject a request with this signature method, unless it supports this signature method and the Accessor Secret extension.

Extension: Variable Accessor Secret

The Consumer MAY choose a separate Accessor Secret for each Access Token. If it's different from the established Accessor Secret, the Consumer MUST send the chosen secret as a parameter named oauth_accessor_secret, in the request to obtain a Request Token (OAuth section 6.1.1). This parameter MAY be absent, in which case the established Accessor Secret MUST be used. (That's the Consumer Secret, if either participant doesn't support the Accessor Secret extension.)

A Service Provider that doesn't support this extension SHOULD reject a request with an oauth_accessor_secret parameter.

Security Considerations

An Accessor Secret enables an attacker to abuse a legitimate access token. So a variable Accessor Secret SHOULD be kept private, and SHOULD be transmitted only via secure channels. SSL or TLS is RECOMMENDED for this purpose. But an Accessor Secret that's empty or widely distributed usually can't be kept secret, so there's little reason to protect it.

These extensions can improve security when a Consumer has a trusted part that's shared by all Users, and a less trusted part for each User, and the less trusted part sends requests directly to the Service Provider for access to Protected Resources. The Consumer Secret SHOULD NOT be revealed to a less trusted part. This prevents an attacker from obtaining access tokens by getting the Consumer Secret from the less trusted part.

Similar Systems

Facebook authentication supports a similar pattern. A 'Desktop Application' doesn't use its application secret to sign access requests. Instead, it uses a secret chosen by Facebook and returned from facebook.auth.getSession. The nearest analog in OAuth would be an empty Accessor Secret; that is, the Access Token Secret alone is used to sign access requests.