Nov 8, 2018

Authentication of REST API

REST API can be authenticated with an API Key. By using API key, the accessibility is not affected by password reset. They are independent from user name and password and therefore also less exposure.

Three common ways to authenticate with REST API: either with HTTP Basic Authentication or Digest Authentication.

Basic Authentication over HTTPS

The advantage of using this technology is that nearly all clients and servers support it. There is no special processing required, as long as the caller takes reasonable precautions to keep the password secret. When using an API Key with Basic authentication, you can use the API Key id ( which is often a UUID or unique string ) as the 'username' and the API Key secret as the 'password':

HTTP Basic username: value
HTTP Basic password: apiKey.secret value

Digest Authentication over HTTPS ( a Signature of the Request with the Shared Secret )

This approach is more secure compare to Basic Authentication over HTTPS. It computes a cryptographic digest of the request and sends the digest value along with the request.  If the transmitted digest matches what the REST API server computes for the same request, the request is authenticated.  It is more secure because the API Key secret is never transmitted outside of the application. But due to its complexity, Basic Authentication over HTTPS may be suitable and enough for your project.

OAuth 2.0

For publicly-available APIs, OAuth 2.0 should be on your list of requirements. As a system grows, we need a centralized approach to identity management, and a service for the whole system that can provide and manage that data in a secure way. This is where standards like OAuth2 come to offer. The fine-grained information that can be packed into an access token provides significant benefits over a simple protocol like HTTP Basic authentication. Client libraries such as Spring Security OAuth2 for Java reduce the complexity.


Don't bother with your own OAuth2 provider if your system is simple and/or client applications never have to act on behalf of a User. Use something as simple as Basic authentication. And switch to big guys' OAuth2 provider (e.g., Google) as long as it supports the features you want.