How web services punish you

I’ve noticed that in order to use the APIs of some web services, they are requiring applications (web based or otherwise) to obtain per-user API keys. This is essentially a generated password (separate from the normal login password) specifically to allow an individual application access to a specific user’s data via an API. It requires the user to manually request an API key for each individual application they wish to grant access to, and then enter it into that application. Sometimes the user is instead forced to manually verify every single action.

In other words, it punishes the user because the web service doesn’t trust the 3rd party application. This is wrong. Its not the user’s fault.

This has come up many times for Ubiquity command authors trying to provide easy and novel access to web services. It means that if commands want to use a web service’s API, they need a setup procedure before they can be used. Which is stupid, because a command already has access to the login cookie, and the login information in the password manager.

I’m not saying that I’m providing a solution for all of this. There are already plenty of other existing methods to choose from – some of which may fit, some of which may be just as bad. What I am saying is that while granularity in access control can be seen as a good thing, it should not come at the user’s expense.

One thought on “How web services punish you

  1. If you’re describing a UI that forces a user to copy and paste a key to another service, then that’s stupid, because it’s easy enough to make a protocol that handshakes between the services after the user’s permission.

    But getting the user’s permission per-application isn’t stupid at all. unless ZERO information is being shared with the other service (including username), then I’d prefer the web service verify that I want that information shared (if I haven’t marked it public).

Comments are closed.