Monitoring APIs with Authentication

With the rise of microservices and distributed systems, more and more data migrates through APIs. So, let’s look at the best ways to monitoring APIs using authentication.

---

---

What is API authentication?

Authentication for an API defines who has permission to access secure data or endpoints. This is especially important for APIs that:

• Share sensitive information
• Allow end-users to make changes
• Charge some cost for accessing data via the 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 both:

• The functionality and performance of authentication systems
• The speed, performance, and reliability of API transactions on the other side of that authentication

For the purposes of this article, we’ll consider two main types of authentication protocols:

• Direct authentication. Users submit credentials or a key directly to an API to access secured data or endpoints.
• Ticket-based authentication. 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.

(Understand the differences between API testing & monitoring.)

How direct authentication works

Let’s look at two examples of direct authentication: HTTP basic authentication and authentication via API keys.

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 API tokens. API keys are just a long string of hexadecimal digits (e.g., 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. 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.

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 encode that username:password value in base64 and send that value over in an authorization header:

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 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 properly transmit the API key.

How ticket-based authentication works

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
• Charging some cost for use of your API

Understanding ticket-based systems

We might think of ticket-based authentication like how we 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 person. 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 ways to implement this type of protocol, most ticket-based systems share a similar structure:

1. You make a request for a ticket or a token.
2. You use that ticket/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

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:

1. Make a request with a username and password and some type of specification in the header.
2. Retrieve a token from the system.
3. Save that token as a variable.
4. Make another request to an endpoint with that token as a header.

API authentication is business-critical

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.

What is Splunk?

The original version of this blog was published by Billy Hoffman. This posting does not necessarily represent Splunk's position, strategies or opinion.