It's much simpler for many cases. bit.ly's API is a good example. They use OAuth 2.0 which uses SSL to guarantee security and all that's necessary for most requests is an access_token parameter. You can jump through the hoops of getting an access token for the end-user if you need to, but for applications that will only be using the application's user (the one that owns the app) it's much easier to just store a generic access token. For example, the specific case that I'm thinking of is as follows: The site myawesome3dprintingsite.com allows you to design awesome 3D models with just a few clicks by their users. To make money the site publishes the users' creations to My Awesome 3D Printing Shapeways shop, where the user can be directed to order it. There shouldn't be a need for an OAuth handshake in this example. myawesome3dprintsite.com should be able to have an access token stored on their server which would be provided to any Shapeways API calls. The end-user isn't involved until they are directed to an item on Shapeways, so an OAuth handshake isn't necessary. Anyway, I think this sort of setup would allow more people to get off the ground faster. I bring up bit.ly because when you create an application there it provides you with an access token that you can immediately use to get up and running.