I’ve been messing around with…

I’ve been messing around with the WooCommerce code for OAuth, and unfortunately it has API consumers (that is, applications) tied to users. This is a pretty limited method, but it simplifies the code and flow a lot. The question is, do we want core to be limited to this extent, or do we need to think about something more complicated? With this sort of flow, we can show the user’s API key/secret on their profile page, and they just need to fill that in to their application. (We could also add an xAuth flow, where the application can request those keys via Basic authentication.)

Alternatively, we treat consumers as an entirely separate entity, which can then prompt users to authorise them. This is the more traditional OAuth flow that you see with Twitter, Facebook, etc. This increases the application complexity a bit, but allows a site admin to manage applications rather than having it managed per-user. It also allows “rogue” (misbehaving/compromised) application keys to be revoked, rather than requiring each user to regenerate a key/secret.

I’m on the fence about this one. There are benefits to both approaches, and I’ve summarised these below:

One-consumer-per-user Independent consumers
Setting up User copies key/secret from profile page into application Application developer registers via site admin, application directs user to authorise the application
Managing All applications share key/secret Applications registered via admin panel
Revoking Users have to regenerate keys and change all existing applications Admin revokes application
Site UI Key/secret fields on user profile page Consumer management settings page

If you can think of any other points here, post in the comments. I think it’s fairly split between the two at the moment, so I can’t really decide.