Security in mobile APIs: OAuth 2.0 vs basic HTTP access authentication

Using an optimal credential or authentication system is vital to ensure the security of an API. OAuth 2.0 has become the basic security protocol for mobile APIs development and for providing credentials to launch native applications.

Mobile application developers are increasingly basing the launch of new products on prior work with mobile APIs that provide services necessary to develop their creations. Either the mobile applications designed need access to a REST API with specific services, or it is necessary to encode a REST API to launch determined applications with specific services. In any case, the fact is that teams are increasingly required to develop mobile APIs. Their security, as in other APIs, becomes an essential element.

Unless the API has totally open access – nowadays strange but not entirely unheard of –, professionals who want to use it will normally need to identify themselves using some specific method. Using an optimal credential or authentication system is vital to ensure the security of an application programming interface, whether it is a traditional API for desktop project development or a specific one for mobile apps.

Authentication methods with mobile APIs

We have talked before about how the different API authentication methods have developed over time into the most common one used today: the OAuth method, the latest version of which is OAuth 2.0. Actually, we analyzed how open APIs based on OAuth 2.0 have become a standard in the current interface market. Is OAuth 2.0 the only authentication method? No, there is another one known as HTTP basic access authentication, based on user name and password. We will start with an explanation of this simple method, which is less used today:

• HTTP basic access authentication: this is the simpler method for meeting the requirements to access a web service. It is simple because it doesn’t require any of the usual processes in a credentials system: cookies, session IDs or access pages. The whole HTTP basic authentication process is based on standard fields in the HTTP header. Thus, it avoids handshaking: the automated process by which two entities establish authenticated communication before starting normal communication via the established channel. This means equipment can communicate with an external device only if there is successful authentication; otherwise, the communication channel is not created. The connection via modem would fail, for example. The secure development of the basic HTTP access authentication method is HTTPs.

To prevent the basic HTTP access authentication method causing the browser to launch a username and password request for each access, the browser must store this information in the cache for a prudent length of time that doesn’t reduce security excessively. These security credentials are usually stored for 15 minutes.

What is this basic HTTP access authentication method like in the real world?

1. The access credential provided to third-party developers who want to connect to a mobile API is a totally secret alphanumerical ID.

2. This alphanumerical API key is stored in a secure space on the server.

3. The developer making requests for a particular service contained in this API should place this secret ID within the HTTP authorization header along with the word Basic. The two elements together allow the server to recognize the alphanumerical credential and provide access.

GET /private/index.php HTTP/1.1

Host: example.com

Authorization: Basic alphanumerical ID

• OAuth 2.0: OAuth represents a step forward in the use of credentials for authentication of API service users. It is a major advance on the basic HTTP access authentication method. Today it is practically the only security method that is almost 100% reliable, and its reliability is based on creating unique authentication tokens for each user. If this access token is compromised, it is deleted and a new one is issued. This means that the API’s own credentials are safeguarded.

The authentication process is as follows:

1. A user launches a native application and is asked to give a username or email address and a password to identify themselves as a user.

2. The type of request used to send this credential to the API is a POST request, which ensures private delivery of secret data. This request is sent via the SSL (Secure Sockets Layer) protocol, designed to enable applications to transmit outbound data securely. SSL facilitates giving and receiving encryption keys between applications.

3. This request allows to validate user credentials and to create ad hoc an authentication or access token that will expire after a time, or if the user or developer responsible for the API believes it to have been breached.

4. This authentication token is stored in the device to facilitate access to the API’s services that support the application itself.

If we compare both methods, OAuth 2.0 provides better security criteria because any initial request for credentials is made under the SSL protocol and because the guaranteed access object is a temporary token. In the basic HTTP access authentication process, access to API services always relies on sending credentials via the web, specifically in the HTTP header, which makes it much vulnerable to third parties.

Are you interested in financial APIs? Discover all the APIs we can offer you at BBVA