Tag Archives: Open API

How to secure open API’s

What have Google, Facebook, Twitter and Amazon in common? They provide a platform on which others can build their services. Apps and websites can integrate functionality offered by the platform into their own services. But how do they provide secure access to their platform from web and apps? It seems there is an open standard supported by all major platforms: OAuth. I think governments should pay close attention to these developments and learn from it. Most governments remain closed except for some open data. Maybe they are more inclined to open up if it can be secured in a safe way.

What is OAuth?

OAuth is an open standard for authorizing apps or websites access to your data from a provider using the authentication from that provider. In other words OAuth enables a safe way, for you the user, to grant apps or websites access to your data on another website of service. For example you can give an app permission to use your Twitter information and even tweet messages on behalf of you.

How does it work?

OAuth relies on your app or website sending a signature with each request to the provider. With the signature the provider can see from which app and user the request comes. The signature is based on the content of request and the token the provider supplied. How does the app get that token so it can sign the requests for the provider?

Well first the app needs to register and obtain a consumer key. This is the part which identifies the app. Next, the user goes to provider with the consumer key and authenticates. After successful authentication the user gets the option to grant access to the app or website. When the user grants access the app receives a token. This token can be used to obtain a more permanent token which can be stored for later use. Also temporarily tokens can be used instead of a permanent one.

This of course a high level description but under the hood is a really nice security framework.

Why is it better than traditional username and password?

OAuth is more than just authentication, it also provides authorization features. So the main goal of the protocol is to give the user the ability to authorize an app or website after authenticating with the provider. The authentication is always done through a (mobile) web page from the provider. So the app or website doesn’t need to know the users credentials. Apps often store credentials for a more user friendly experience, login using a small keyboard is not really easy for most users. Instead of storing the username and password the application stores a token to connect to the service of the provider. Since only this application can use the token it is much safer then storing the user’s password.

Not only safe storage of credentials is solved for users. It also gives them the option to see what an app can do on behalf of them. And most providers have the page where users can revoke tokens to deny the app or website access.

How secure the authentication process is will be determined by the provider. If you look at Google for example, their two-factor authentication is fully supported with OAuth when you first time login.

What about my SSL check?

You can trust websites by validating the SSL certificate of a website. It ensures you who is on the server end and that your data gets encrypted. For apps there is no such thing. Of course you can rely on Apple or Microsoft to validate the apps and check it for evil functionality but Google doesn’t exercise the same rigorous control over their store. In the Play store everyone is welcome. The authorization model of OAuth provides a nice way for establishing some trust in apps. When you register your app for services from a provider, you must provide the name of your app, the app icon and the publisher name. These are typically the items a user sees when downloading an app from the store. These items are also unique for an app in the stores. This way the user can identify that he/she grants access to data to the correct app. Of course there is an option for evil apps to register but the provider can disconnect them ensuring the app has no access to the user’s data. Additional trust in apps is created when providers like Facebook and Twitter list apps that use their services in a correct and safe way.

Dutch government and apps

In the Netherlands most communication with the government requires authentication with DigiD. DigiD is a web based authentication provider relying on the SSL lock in the browser. You can inspect the certificate and see who is on the server side and all communication is encrypted. But the world is changing fast and on mobile devices you don’t always have the possibility to validate the certificate. Or even worse you cannot even see the SSL lock. Apps are also able to emulate the communication of a browser and can use DigiD. In a world moving towards mobile and apps the government needs to take some action. The confidence a citizen can have in the SSL certificate for websites must also be established for apps. How can they do that for the current situation with DigiD and how to do that for the future? Well that’s quite easy. For the short term only two measures are really needed. First enable citizens to validate the app they downloaded, e.g. a list of published or certified apps on a secure website so citizens can validate apps in that list as genuine. Second measure is to start monitoring the app stores on evil rogue apps and ensure those apps are removed as soon as possible and warn people as soon as possible. For the long term DigiD might implement OAuth to support websites and apps. That way the government gets more control on which apps and web sites uses their services. And the Dutch citizens not only get a more secure solution but also a more user friendly way of authenticating. This is also a first step for the government to be a platform with open API’s on which the government itself and third parties can offer services in the form of websites and apps. So after open standards, open source and open data hopefully the next step towards open API’s will be taken.

More, mostly technical, information on OAuth can be found on the developer web sites of Google and Twitter.