To the best of my knowledge, when Drupal acts as a provider it provides a key and a secret (from a consumer) for use by the client/application. This same key and secret are to be used by the application for all OAuth requests it makes - so this key and secret will be used to carry out the OAuth request and access token processes for all users of the client application, so therefore for multiple Drupal user accounts. Making this black and white: the key and secret will be used to authorise MANY Drupal users.

So why then is the consumer in Drupal tied to one specific user account? It would make a lot more sense for consumers to be tied to external applications and configurable in the admin area at admin/config/services/oauth in the same way that contexts are. I do not think that there should be a UID stored in oauth_common_provider_consumer since the consumer is not user specific!

This would not prevent individual users from seeing the OAuth authorisations they have made between their Drupal account and external applications.

I have seen this question asked previously in #335995 but the answer, given in 2008, does not answer this question, just says "we can assume that we can link consumer keys to the site owner/admin." without going into any more detail. Please explain to me a valid reason for this behaviour - what benefit does oauth_common_providerui gain from having a UID associated to the consumer?

Comments

kylebrowning’s picture

kylebrowning CreditAttribution: kylebrowning commented

Because nobody is willing to rewrite oauth.module to support a situation where the keys are not user specific.

If i remember correctly, it was done because those keys get that users permissions allowing you to make one user to control permissions of anyone who makes access tokens from those keys.

Im not sure it works that way anymore though.

melissavdh’s picture

melissavdh CreditAttribution: melissavdh commented

Thanks for your reply @kylebrowning, I can now see some benefit to making the keys user specific, although personally I think these permissions should be achieved without a dependency on an existing user account. This isn't made clear at all in the documentation so there is a big danger here of people registering the consumer against the admin account (as most tutorials suggest) and therefore accidentally giving administrator access to the whole site through OAuth, if this is how it still works...

At least we can use Services to limit the actual resources available for use via OAuth but I would, if I were an OAuth maintainer, still make it extremely clear to module users of the permissions setup.

I'd love to see the consumer non user specific so when I have some time I will do my best to code this up.