Topic on Talk:OAuth/Flow

Reading this comment brings up a point: http://hueniverse.com/2010/09/all-this-twitter-oauth-security-nonsense/#comment-11353

• Tools like Huggle are desktop apps.
• We intend to allow people to use these over OAuth.
• However there is absolutely no way to verify what app is making these requests. It's impossible to use a client secret which is necessary for that doe be done.
• We have to accept that we're going to allow the use of clients without the use of a shared secret to identify what application has gone rogue.
  • The only alternatives are A) Do not allow any desktop apps (Unacceptable) B) Require desktop apps to try to use a client secret they inevitably cannot keep secret (This will lead to the potential for malicious apps to reuse the anti-spam tools' client secrets leading to anti-spam tools being blocked and reverted when we try to stop a malicious app.)

Given these facts here's my conclusion:

• We have to allow clients to be dynamically registered / authorized to a single user client secret instead of always pre-registered with a client secret (otherwise we risk malicious and non-malicious apps being grouped under the same app id and ending up with a useless interface that blocks too much). However we can still let non-pre-registered apps give a name for visual purposes.
• We make sure the UI dealing with registered apps has visual indicators to indicate the difference between a named app that's been pre-registered and a dynamically registered app (specific to one user) wherever we display an apps name. This is necessary to avoid sysops mass-reverting and blocking everything that comes from an app named "Huggle" because a malicious app started ussing the name "Huggle" in all of it's unverified OAuth connections.
• We understand and accept that a single app gone rogue may be using different application ids (ie: each user that has authorized it has authorized it as a different app) and deal with this fact by making it easy for sysops to revert and block multiple apps at the same time instead of forcing them to deal with 100 app registrations separately because one app has been used by 100 different users creating 100 apps that don't use client secrets.

I should rephrase myself after reading the spec in full:

• All clients have a client identifier
• There are confidential (hosted on a server) and public (client side, applications, mobile apps, etc...) oauth client types
• confidential client types have a client_secret to verify themselves
• public clients cannot have a client_secret because it's impossible to give one to the application, give the application to the user, and expect that they cannot find some way to extract the secret from the application
• This means we can't guarantee something that comes from a public client actually comes from that public client
• And we can't reliably mass-revert a public client by it's client id

My idea on how to solve this is:

• Don't place any dependence on the client_identifier for a public client (in fact, consider not even allowing an admin to mass-revert based on client_identifier if the client is public)
• Make the difference between confidential and public visually apparent in the UI (so that editors learn to understand that if they suddenly see "Huggle" going rogue the client itself may not actually be rogue).
• Use client_identifier for mass reverts of confidential clients. But when the client is instead public skip client_identifier and allow the admin to see edits grouped by what individual authorization to the client made the change. Using this method we should allow admins to do mass reverts by selecting a number of authorizations for a public client and specifically reverting those en-masse.
• Use an intuitive UI for mass-rollbacks. When the admin inputs what criteria they want to use for doing a mass-rollback display a sample of what they are going to revert so they don't make a mistake.

Side note but I think we should permit multiple redirect_uris to be registered, and allow for wildcards.