- June 9, 2017
- Author: Arivuganesan A
- Category: Technology
Why use Authentication?
Web services could be easily accessed by any user if they knew the URL and input parameter to get an output. To keep unauthorized people from accessing the APIs, we have to authenticate the users using a checkpoint.
Different approaches for Authenticating your API
While there are several methods of authentication available, this article will look at the most popular authentication methods available, and provide the pros and cons of each.
- Basic Authentication
- Digest Authentication
- OAuth 1.0
- OAuth 2.0
Basic Authentication is similar to the standard username/password approach, where we use an username and password to authenticate the API. Here, a Base64 encoded string that contains the username and password sent to the client. Base-64 encoding is not an encryption method, just a way of taking binary data and turning it into text so that it’s could be easily transmitted.
HTTPS Basic is a good fit for a relatively unimportant internal API which requires just a simple authentication, but the lack of encryption part make it a bad choice for API’s with sensitive data as there is a high chance of exposure in case of MITM (Man in the Middle attack).
- Implementation is pretty simple, as there is no encryption involved
- Take relatively less time to respond as it has only one call
- The lack of token creation and encryption method gives Client an advantage of using less code to call the API
- The information is retrieved from the server with just one call, making it faster than other complex authentications
- SSL takes time to run basic HTTP, so this will make the response time considerably slow
- The lack of encryption makes the security risk fairly high
Digest Authentication is similar to the basic authentication with slight improvements on the authentication part. This method uses the hash function encryption method to encrypt the username and password.
Client makes a request to the server.
Server will give a random string called as a nonce to the client which is a combination of username, password, and realm with 401 unauthorized response.
The client would then use MD5 Hashing Encryption to generate a hash key (nonce, username, realm, URI, and password), which is sent with the request to authenticate along with username, password, and realm.
In Server side, the same method is used to generate the hash key and compare. Instead of using password sent by the client, it will get the password for the corresponding username from its DB which contains all the user details.
If the username doesn’t match, it will return the authentication error in response. In case the username matches with an entry the DB, it will retrieve the password, run the same algorithm and then compares the keys.
If the keys match, the user will be granted access to receive the information. Else 401 authentication error is returned as the response.
- Secure without SSL when compared with Basic Auth without SSL due to the process of encryption.
- As usernames and passwords are encrypted, the chance of cracking it is considerably less.
- Client must make two calls to get the output response, so it is a bit slower than HTTP Basic Authentication
- Password stored in the user DB is not strongly encrypted so there are chances that the data may be hacked
Unlike other authentication methods, it has two sets of credentials for authentication namely client credentials and user tokens. It is available in 2 versions: OAuth 1.0 and OAuth 2.0.
OAuth is a three-legged process, which authenticates the client in 3 steps. The Three stages are as follows:
- Temporary Credentials Acquisition
- Token Exchange
Temporary Credentials Acquisition:
In this step, a temporary token called Request token is received in the response at the completion of the initial authorization process. To acquire this token we have to send a POST request that comprises of consumer key(username), consumer secret(password), callback, signature method and signature, to the temporary credential URL typically /OAuth/request.
The server will check the signature and key to make sure the client is valid. Once the process of checking is successfully completed, token and the token secret is returned with the HTTP response. This step doesn’t grant any access to data on the server and could not be used for anything other than the authorization flow. Tokens and the token secret are used as parameters in the next step.
The next phase is the authorization process. In this step, the client will append the temporary credential key( token and token secret) as a query parameter in the Authorization URL provided by the site usually OAuth/authorize. After checking the parameters, the user could either authorize or cancel the process. If the user authorizes the client, it will redirect to the callback URL that contains the temporary token and CSRF token (oauth_verifier) which would be used in the next step.
The final step in this process is the exchange of tokens. Here, the temporary credentials such as request tokens are exchanged to long-lived credentials by the Access token. This process will be carried out by sending a POST request which comprises of consumer key, signature method, signature and request token to the token request endpoint (typically /oauth1/access).
The key and signature are checked again if the information matches, the access token is returned with a response. Thus, the client is granted access to retrieve data from the server.
- Cryptography is used to compute a digital signature
- Each message is signed independently
- Transport Independence – not delegated to HTTPS
- MITM attack may occur
- The level of complexity is more in the development phase
OAuth 2.0 is completely a new protocol and entirely different from from OAuth 1.0.
First, we have to get the permission to access the server, by sending a request with the authorization parameters.
If the Authorization Request is accepted, the server will respond with an authorization grant. That will redirect us to the URL where we could get the Access Token.
If the authorization grant is complete, the server will attach an Access Token in its response. The access token is an encrypted code, which is used to access the server and retrieve the data.
Once, we receive the token; it is sent along with the input parameters retrieve the data. The server will then validate the Access Token, and send a response with the data to the client.
- More flexible as it could handles non-web clients as well
- Easy for developers to implement the code
- Refresh Tokens Concept has been added
- In case an SSL / TLS connection is not implemented an MITM Attack may occur
That concludes the pros and cons of different authentication techniques available today. As you could see, each method has its own set of benefits and shortcomings.
To be honest, there is no right or wrong choice here – it doesn’t really matter what option you end up choosing, what matters is whether or not the method you choose matches your client requirement. So, analyze every option available to you and choose wisely.