Various ways of authentication in REST API

This is not an April fool article by the way. .. 😀 it’s really about “various ways of authentication in REST API”.

Most of the software developers in their entire career go through a phase, when they have to use or interact with another piece of software or system. And this is when we start learning about  integration ways. Thanks to the community of software developers who invented a way called Web services or API (Application Programming Interface ). This is a method via which software systems talk to each other. They share and understand each other’s language ( data ).

There are two ways of integration :

1. SOAP (Simple Object Access  Protocol )
2. REST ( Representational  State Transfer)

We will be discussing about the latter one – REST. Will try to cover SOAP at some other time.

REST is simpler to use via HTTP protocol,  but there are many ways to authentication. Security is more needed here as we are sharing resources via Web ( HTTP ). Any session state in a REST API call is stored in the client, the server is stateless. This is why REST (Client side) has to provide all information necessary to make the request.

HTTP basic authentication :

Most simple one. We send the user name and password in the HTTP header encoded with base64. Even though it’s encoded it’s not secure as we did not encrypt it. We can send these info in SSL/TLS to be bit more secured.

HMAC authentication:

Another way is to use HMAC (hash based message authentication). In this method we send hashed version of the password.

Example : Let’s assume we have the following credentials: username “amit”, password “password1234”. Suppose we try to access a protected resource /stock/quote/google.

First, we need to fetch all the information we need, and concatenate this for a base string:

GET+/stock/quote/google

Next step is to generate a hmac:

hmacdata = base64encode(hmac("sha256", "password1234", "GET+/stock/quote/google"))

We will send this in HTTP header:

Authentication: hmac amit:[hmacdata]

If anyone would want to use the above information to send a request and get the response it will not work,  as this would change the hmacdata (Digest what we call it) and the hacker cannot generate the same digest without all the information. To be more secure we can add nonce to request header, so the server expects some more additional value as part of nonce and datetime stamp to be more secure.

The server can reconstruct the digest again, since the client sends over the nonce along with other data through header. If the datetime is not in a certain range of the current server datetime (i.e let’s assume 5 minutes), then the server can ignore the message, as it probably is a replay of an earlier send message or someone is trying to get information .

The nonce is a number we only use once. If we want to access the same resource again, we MUST change this number. This means that every time we access a resource, the nonce will be different, and thus the digest will be different, even if we access the resource in the same second. This way we are sure that no replay attacks can be done. Each request is only valid once, and only once.

OAuth

As per HMAC we are bit more secure but till the time the secret is secure . Once if anyone knows about the secret key they can use it for un-authorized access. A common way to prevent this is to use temporary tokens.

OAuth is an authentication protocol that allows users to approve application to act on their behalf without sharing their password. OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.

You can reffer to : RFC document for oAuth details.

OAuth2

OAuth 2.0 is the next evolution of the OAuth protocol and is not backwards compatible with OAuth 1.0.

Visit : oAuth 2.0 for more information on this.

I hope it helps with some information in it. Queries and comments are always welcome.

Keep reading and sharing .. as sharing is learning.. 🙂