3 Ways to Secure Your Web API for Different Situations
Security is an important part in any software development and APIs are no exception. Even for a public API, having control over who can access your service is a usual business requirement.
As Web APIs are stateless in nature, the security context cannot depend on server session. Each request made to the API must attach some form of credentials which has to be validated on the server.
Here are three common ways to keep your Web API secured and when to use them:
Note: The techniques discussed here is on authentication and authorization and does not encrypt transmitted messages. Message encryption is usually handled using the HTTPS protocol shared by the client and server.
HMAC Authentication
This security mechanism is common in public APIs and is relatively easy to implement. The client or application that wants to access your service will need an API Key and a Secret Key from you as the service owner. These keys are usually randomly generated strings and is given to the client beforehand. API Keys are unique to each client/application. Both the client and server will hold the API Key and Secret Key.
When the client makes a call to the API, the message content is hashed using the secret key on the client to generate a HMAC signature. This value, along with the original message and the API Key is then passed to the server’s API. On the server, the same process is repeated but this time using the private key stored on the server which is retrieved by the corresponding API key sent from the client. The generated HMAC signature is then compared against the one sent by the client. The request is authorized when both HMAC signature matches.
When to use: When you have a public API and want to control who can access your API.
Digital Signature
Digital signature relies on private-public key pair is a useful mechanism for securing server to server communication. It works by signing the message content with a private key to produce a security signature that can be verified using the corresponding public key (certificate). A key pair is usually provided by a certificate authority.
The client will provide its public key to the server. Each request is then made to the server by signing the message content using the private key. This allows the server to verify the message authenticity without knowing the private key of the client.
The difference with this method from HMAC is that the server and client does not share the same secret key, hence neither party can impersonate one another.
Important: Private keys as its name suggests must be kept private by the owner. The client holds the Private Key used to sign the message. The server holds the Public Key (Certificate) used to verify the message signature.
For two way communication, both servers will hold their own private keys and exchange public keys with each other.
When to use: When you need server-to-server or two way communication.
OAuth
OAuth is popular security mechanism that is widely used for user authentication. Similar to how a logged in session works on a website, OAuth requires the client user to “login” to the Web API before allowing access to the rest of the service.
This is achieved by exposing a single endpoint for the login process. The client will then pass the user credentials to the API, where the user is authenticated on the server. Once authenticated, a security token is generated and stored on the server and is returned to the client.
The client will then pass this token to the API in order to access restricted endpoints. The token is validated on the server side.
When to use: When you want to restrict certain parts of your API to authenticated users only.
Conclusion
The three security methods discussed here are industry standards used for different situations. HMAC Authentication is common for securing public APIs whereas Digital Signature is suitable for server-to-server two way communication. OAuth on the other hand is useful when you need to restrict parts of your API to authenticated users only.
There are other security measures such as IP white listing which are worth exploring. I will leave them for another post.
