This blog post will categorize Application Programming Interface (API) Security into 4 basic techniques and describe the risk and trade-offs for each technique. The 4 techniques are Unencrypted, Encrypted with Password, Encrypted with Token and Mutual Transport Layer Security (mTLS). Understanding API Security is key to making sure your applications are appropriately secured.

Modern SaaS Platforms and Cloud Computing environments use APIs for countless services. Whether it is interacting with the Cloud Provider to get status on specific resources, queries to retrieve data from applications or even Internet of Things (IoT) device, there will most likely be an API.

Each API provider will come up with their own unique implementation of API security. However, you can group API Security into 4 major groups: Unencrypted, Encrypted with Password, Encrypted with Token and Mutual TLS (mTLS).

When building an API, consider the caller: is it a person or a computer? Consider the sensitivity of the data being exchanged. Given the sensitivity and risk of the API, choose the API Security model and tune it appropriately. For example, an API being invoked by another computer may have a 32 character password, which would not be practical for a person.

Unencrypted APIs

Unencrypted APIs have no security! Basically, this API will respond to anyone who invokes the API correctly.

Pro’s:

• Easiest to Implement
• Easiest to Use: the caller does not need to create an encrypted connection or have any prior knowledge to invoke the API
• Requires minimal computation and does not require any cryptography libraries

Con’s:

• 100% insecure

Appropriate Use Cases:

• Public or non-sensitive information, e.g., Time of Day, Heartbeat, etc.
• IoT Devices and other simple devices

Encrypted APIs with Password

This is the most commonly used technique and is used by both people and computers. For people, its typically a Username and Password. For computers, it may be a Username and Password or simply a shared secret between the Client (caller) and the API service.

When using a Password, it is very important to encrypt the connection! If the connection is not encrypted, it is possible for anyone to read the Password and bypass the security control.

However, the biggest concern with this approach is ensuring the Password is secured. The most common way to try to ensure the Password is secure is to enforce regular Password rotations and storing the information in a secure place. Taking these extra steps will make this technique pretty secure!

Pro’s:

• Industry standard
• Commonly available tools and packages to implement this approach
• If the caller ensures they secure and rotate their Password, this is pretty effective

Con’s:

• If the Password is compromised, there is probably no good way to tell
• May not be strong enough for very sensitive data

Appropriate Use Cases:

• Most computer platforms
• Most APIs and Website’s where the data is not too sensitive

Encrypted APIs with Token

The next step in improving the Security Profile is to replace the Password with a Token, e.g., JSON Web Token (JWT), OAuth Token, etc. Tokens are more secure because both the Caller and API Service have a trusted neutral party, or Identity Broker, which issues the Tokens. Both the Caller and API Service trust the Identity Broker to issue and validate Tokens.

With this technique, the Caller authenticates to the Identity Broker. The Identity Broker then issues a Token to the Caller. When invoking the API, the Caller sends the Token it has to the API Service as part of the request.

That API Service independently verifies the Token with the Identity Broker to validate the Caller and then issues the response.

A good example of this is Facebook or Google login. When you authenticate to Facebook or Google, they are issuing a Token which is kept in your Browser. When you access a different Website, that Website independently verifies the Token with the Issuer (Facebook or Google) and then let’s you use their service.

Pro’s:

• If the time-to-live (TTL) of the Token is short, then this is a very effective method
• Industry Standard
• Commonly available tools and packages to implement this approach

Con’s:

• For this to work, both the Caller and the API Service need to register with the Identity Broker
• Both the Caller and API Service need to make sure their authentication, typically a shared secret, to the Identity Broker is properly secured
• Need to ensure the TTL is appropriate for the specific use case

Appropriate Use Cases:

• Most computer platforms
• From a practical perspective, this is what many systems use for sensitive data

Encrypted APIs with Mutual Transport Level Security (mTLS)

In the previous encryption methods, there is one certificate, used by the API service to secure the connection. With mTLS, both the Client and the API Service have their own certificate and both are used to create the connection.

Conceptually, you can think of the certificates on either side as secret. However, since certificates use cryptography and can be verified by either side, which makes this is an extremely powerful technique.

The biggest drawback of this approach is both sides need to be pre-configured for this type of connection. In the case of the API server, it must know about this particular Client and what services it can access. This puts a very large burden on the API Service to be updated as Clients are added, modified or dropped.

Pro’s:

• State of the Art Security
• No shared secret and no Identity Broker
• Connection independently verified by Client and API server

Con’s:

• Each Client needs to be approved and independently onboarded
• Not scalable: due to the burden of onboarding Clients, this technique is not suitable for large number of Clients

Appropriate Use Cases:

• When security is very important and the Clients are known

Summary

It is important to use the right API Security technique based upon the sensitivity of the information and the size of the population using the API. Note, these are just the “basics”, it is possible to come up with many different variations for a particular use case. For example, using mTLS, you could add Passwords to authorize different users for different levels of service.

Finally, remember that computer-to-computer APIs are limited in their authentication techniques. With a person, you can use a second factor, e.g., cellphone, to further authenticate the user. Computers are limited to the files and configuration they have for authentication. See my other blog on Authentication and Authorization

Happy computing!