This wiki is no longer active and is left here for historical purposes. Please visit oauth.net for up-to-date information.
View
 

AccessorSecret

This version was saved 10 years, 3 months ago View current version     Page history
Saved by PBworks
on October 24, 2007 at 2:24:23 pm
 

Here are two related extensions to OAuth. To discuss them, please use the Accessor Secret thread in the Google Group OAuth Extensions.

 

Extension: Accessor Secret

 

When signing a request for access to a Protected Resource, an Accessor Secret MUST be used instead of the Consumer Secret. This is a new secret, not the Access Token Secret and not the Consumer Secret. Like the Consumer Secret, it's established as part of the agreement between Consumer and Service Provider.

 

The Accessor Secret MAY be empty, or MAY be the same as the Consumer Secret. The latter enables interoperation with an OAuth participant that doesn't support this extension.

 

Extension: Dynamic Accessor Secret

 

The Consumer MAY choose a separate Accessor Secret for each Access Token. It sends the chosen secret as a parameter named oauth_accessor_secret, in the request to obtain a Request Token (OAuth section 6.1.1).

 

If this parameter is absent, the Service Provider will use the established Accessor Secret. (That's the Consumer Secret, for a Service Provider that doesn't support the Accessor Secret Extension.)

 

Security Considerations

 

An Accessor Secret enables an attacker to abuse legitimate access tokens. So a dynamic 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 encrypt it.

 

These extensions can improve security, for a Consumer that 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 less trusted part needs to know the Accessor Secret, but need not know the Consumer Secret. So, an attacker can't abuse the less trusted part to obtain the Consumer Secret and then obtain tokens.

Comments (0)

You don't have permission to comment on this page.