With the rise of microservices and connected systems, more and more data is being based back between services using APIs.
Authentication for an API defines who has permission to access secure data or endpoints. This is especially important for APIs sharing sensitive information, APIs that allow end-users to make changes, or for companies that charge some cost for accessing data via API. And while securing an API for an individual human end-user is one undertaking, there are additional considerations as we authenticate systems for an increasing number of non-human entities.
As APIs become more secure, proactive monitoring systems are adapting to make it possible to access secure systems externally to:
- Test the functionality and performance of authentication systems, and to
- Test the speed, performance, and reliability of API transactions on the other side of that authentication
For the purposes of this post we’ll consider two main types of authentication protocols:
- Direct authentication: end-users submit credentials or a key directly to an API to access secured data or endpoints
- Ticket-based authentication: end-users submit credentials to a central authentication server that supplies a ticket or token that can be used to access only specific data or endpoints
We’ll walk through some high level details about each type of authentication and look at how proactive monitoring systems may be configured to monitor APIs secured by each type.
A good example of direct authentication is HTTP Basic Authentication. HTTP Basic Authentication is a standard part of HTTP, and it can be used for API endpoints or any HTTP URL. You simply send a username and password – encoded together in base64 – as part of your request to the API. The benefit of HTTP Basic Authentication is that it’s easy to implement and is typically included in standard frameworks. On the downside, HTTP Basic Authentication offers no advanced options and may be easily decoded.
Another example of direct authentication would be using API keys or tokens. API keys are just a long string of hexadecimal digits, i.e. 34d83d84f28d146aeae0e32f7803c88d, that can be sent instead of a username or password to authenticate access to an API endpoint. API Keys are essentially the same as a set of username and password credentials, but they provide a layer of abstraction that is useful. For example, multiple end-users could share a single API key.
When using any type of direct authentication, it’s important that you also use SSL/TLS or https:// at the start of the API endpoint URL. Using SSL/TLS will ensure that the HTTP Basic Authentication credentials or API keys aren’t exposed in the URL.
Interested in learning more about SSL/TLS and how to optimize for performance? There are a number of excellent articles on the Zoompf blog.
Monitoring APIs with HTTP Basic Authentication
If you are using basic authentication to secure your APIs, it’s super simple to include that authentication when configuring an external monitor to check for API performance. Simply include the username and password in the request headers.
While some systems will accept a username and password directly in the URL string and convert that to an Authorization request header value for you :
the most common and reliable way to set up a monitoring request with HTTP Basic Authentication is to go ahead and encode that username:password value in base64 and send that value over in an Authorization header:
It’s important to note that while it’s easy to encode usernames and passwords into base64, it’s also very easy to reverse or decode so that a system can authenticate a request. You can try this yourself with an online base64 encoder/decoder. Because base64 is so accessible, it’s important to protect this type of direct authentication with SSL/TLS.
Monitoring APIs with API Keys
From a monitoring standpoint, it’s fairly simple to replicate the process of hitting an endpoint with an API key in the URL or with request headers. Supply the key and just remember that if it ever changes you’ll need to update your monitoring test’s configuration as well.
Note that different systems may accept API keys in different ways – for example, as part of the POST data instead of as a request header – so check with the API you are monitoring to understand how to properly transmit the API Key.
While there are certainly some conveniences to implementing direct authentication, we may need to add an additional layer of security to our APIs. Ticket-based authentication systems rely on central authentication servers that act as intermediaries, accepting credentials from end-users and then sending back tickets, tokens, or keys that allow the specific end-user to access only specific secured data. Ticket-based authentication is ideal for any scenario where you’re protecting sensitive information, allowing an API to create objects or make changes, or if you’re charging some cost for use of your API.
Understanding Ticket-based Systems
We might think of ticket-based authentication as similar to how we might obtain keys to test drive vehicles.
Imagine that I’m selling my junker of a car on Craigslist. You meet me at the local diner so you can give my car a test drive. You show me your driver’s license. I say, “Hey! You seem to be this nice person who I just met online. I trust you absolutely. Here’s the key. Give her a spin and bring her back in a few minutes.” That would be similar to direct authentication in the sense that I’m giving the car key directly to you based on your name.
Now imagine that I’m selling you a luxury vehicle from a dealership. You meet me at the dealership and give me your driver’s license. I don’t have one key that will work for all of the cars on the lot. I have to take your driver’s license and use it to register your information to a computer system that will verify that you’re an upstanding gentleperson. This will then unlock a box where I can take out a key that will only work for the vehicle you’re now registered to test drive. This is similar to a ticket-based system in the sense that I’m relying on a centralized system to distribute a key that’s now connected to you through the ticket.
OAuth, Kerberos, single sign on, and webforms are all examples of ticket-based authentication systems. You may even develop your own custom authentication system. While there are many different ways to implement this type of protocol, most ticket-based systems share a similar structure in the sense that you first make a request for a ticket or a token and then use that ticket or token to access secured data or endpoints.
The tickets in ticket-based authentication systems look very similar to the API Keys we discussed above. One main difference is that the tickets are ephemeral. They are only valid a short period of time and can be easily revoked, which provides an extra layer of security.
Monitoring APIs with Ticket-based Authentication
In order to effectively monitor an API that uses ticket-based authentication you must be able to complete multiple steps and save the ticket or token in a variable that can be re-used in future steps.
A simple example of this would be to make a request with a username and password and some type of specification in the header, then retrieve a token from the system, save that token as a variable, and then make another request to an endpoint with that token as a header.
If you’re not already implementing some authentication for your API, it’s critical that you start doing so to protect your data and your systems. And, as you increase security make sure that your external monitoring systems also have the permission and ability to monitor the performance and reliability of your system. If you’re only monitoring your API performance on the application side, you could miss all sorts of connectivity problems preventing your end-users from accessing data or making changes through your API.