Secure Web API Flow

flow.md

A Rough Flow for a simple, secure web API

• Step One: Third party app developer (hereafter "the app") registers an application with the service provider (called here and afterwards "the service provider"), like Twitter or Gimme Bar. The app receives an API key, where it is made explicitly clear that storing username/password combinations is not necessary and is a violation of the terms of service for the API.

• Step Two: Over SSL/TLS, the app exchanges a username/password combination given to them by the end user, and provides it to the service provider, along with their API key in exchange for an access token.

####But wait, isn't that insecure? Why is the user giving you their password? oAuth prevents this!!!!

If the app is a malicious mobile or desktop application, the app can very easily steal your password if desired - the app can redirect you to a "web browser", which it controls, and steal your username and password if the app is a dick. This is only one avenue of several a malicious app could take. The oAuth login page is security theater, easily spoofed. If you install a mobile or desktop app, you've given them a degree of trust and access to your system.

Given this fact, there is no password security benefit to redirect to a web browser page controlled by the service provider. The service provider can actively discourage storing end user passwords (both in writing and as a part of their programming interface), and provide no legitimate purpose for the app to store a user's username and password. Exchanging a username and password (which should NOT be persisted by the app) for an access token (that will be persisted by the app) meets this need, by providing no technical reason for the app to need access to an end user's username/password combination.

• Step Three: Over SSL/TLS, the app shall access data on behalf of the end user, using the access token they obtained and their API key to authenticate.

• Step Four: There is no step four.

Author's Notes

• This does not account for allowing different permissions to an app/configuring what permissions an app gets from the end user. In such a case, a redirect to a browser may be unavoidable, since the end user will want to personally configure what access rights an application has. In such a case, I roughly like what Gimme Bar is doing (https://gimmebar.com/api/v0), though that may not be the only solution.

• Inside app, user is kicked to a web page pre-configured with a third party app ID and some kind of access request token
• Once logged in on the web page, the user will be asked to configure that permissions a third party app can have.
• Once finished, the user returns to the app. The app tries to contact the service provider and exchange their request token for an access token

• The above is still susceptible to password theft by a malicious app, but provides the end user enhanced ability to control what access a legitimate application can have to their data.

By being redirected to the ("trusted") service provider's page, the user is presumably more likely to believe that your app is not gaining access to their credentials. Greater trust presumably leads to greater acceptance of your app and the service provider's ecosystem. The trust factor, perhaps misplaced from a technical standpoint, argues in favor of the redirect step.

Shenanigans. You're saying yourself we're talking about the user's perception - if I am a malicious app, of course I will take every step to assure that the user is comfortable typing in their username/password. That probably means faking an oAuth login page (if it exists for the service provider). If I am a non-malicious application, I can give the user that "warm fuzzy feeling", but it does not enhance the security of their password. Why engage in that level of security theater when 1.) does not, in reality, enhance security 2.) makes implementing a client application more difficult and 3.) detracts from the user experience by redirecting to a web page.