Desktop apps and the lack of client secrets to verify who's asking for permission
Fragment of a discussion from Talk:OAuth
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.
