You are probably familiar with the concept of an API - Application Programming Interface. Every API is a handy outlet, an entry point to a software service of which there are billions throughout the web. You could use them raw by sending requests via basic API interfaces to, for example, parse weather info of your favorite cities on the other end of the planet. Or you could integrate them into whole systems to accomplish much more sophisticated tasks like tax calculation or store order management. And no matter how small or big, simple or complicated APIs get, they would similarly benefit from a healthy diet of good security practices. So let’s talk about API authentication methods.
API Authentication’s main purpose is identifying who or what is making a request. It means that an app that has a bad, or no authentication method at all, couldn’t reliably know if it’s safe to answer those requests. If you don’t know the caller, you can not give them permissions, track their inputs, limit their requests and so on.
Even simple applications that seemingly don’t require knowing the caller, can be easily abused if they don’t have a mechanism that limits daily uses per given key. Such abuse could make a big hole in your cloud provider wallet balance. To avoid situations like that, let’s have a look at some of the methods of API authentication.
The most basic of all basic methods, the tried and true - Basic Authentication. In literally millions of interfaces, it is simply represented as some variant of a username and password pair.
Every user and their grandma is well acquainted with that principle and can probably handle memorizing the login data for their favorite services. Those who want a slightly less revealing alternative can change -u flag for -H or –header:
You may also recognize a somewhat similar term as API Key authentication. API keys are issued from within a given system in the form of a hash string that can be used as a substitute for user credentials. Even if you personally never handled API keys, the websites you visit do that all the time with each sensitive action like email register confirmation.
Be aware that API keys can also be accepted in different ways, for example:
All in all, basic authentication is a simple solution that, when paired with a secure connection, will already protect you from the vast majority of unwelcome “eyes” peeking for data to steal. Its main weakness however, lies in the fact that passwords and keys themselves get routinely stolen, especially when using unsafe HTTP connections instead of HTTPS. And you won’t know something’s wrong before it’s too late to take action. While this was once the standard for authentication, today there are much more advanced methods of keeping your data safe.
One of those advanced ways of API protection is called JWT, which stands for JSON Web Token. Despite the complicated terminology, on a user input level, JWT authentication looks very similar to basic authentication. Just punch in your email address, your password - and get an access token in return, which can look something like this:
Let’s extend the example we used before with a JWT authentication header prefixed by “Bearer”:
A keen eye would notice that the token itself is not an encrypted hash, but a pretty easily decodable base64 format string. So what stops the hackers from manipulating its payload to gain additional permissions?
Let’s imagine the scenario:
>>> {“username”:”eugene”, “role”:”user”,”iat”:1740749400},
The thing that prevents this kind of behavior by design is called Token Validation which, luckily for us, works wonders with JWTs. When an Access Token is issued by an API, it gets signed with a secret hash known only within your server. To decide whether or not it is safe to trust the data in JWT payload, each token gets tested against that hash. That way, outside of the original signing server, it is nearly impossible to issue valid hacked tokens with excessive permissions.
But what if by a calculated strike of misfortune, your valid token gets compromised? Indeed, that’s a situation you wouldn’t want to be in! However, even within the JWT authentication method, there are effective ways to prevent harm from losing an access token.
Every token, when created, can be configured to have a certain shelf life. In the most basic JWT systems, it is often set to 30 days. But we could make it valid for 5 minutes instead. “What’s the advantage?” you would say, “It will probably log me out every other time I make a request”. And that would be true, but only until we add the Refresh Token to our equation.
The Refresh Token is given to users alongside the Access Token, and is stored on the server at the same time. When an Access Token inevitably expires, the client makes a request to the server to check if your Refresh Token (with a much longer shelf life) is still alive and is still recognized as valid on the backend.
The validity could be easily revoked to block off a certain user’s access to an API. That simple addition to an already pretty secure JWT authentication method elegantly elevates the API security to the next level but for some, it is just too much hassle. So could we make API protection stronger and easier to use at the same time?
You may be surprised, but there is a way! Yes, whoever is familiar with OAuth knows that the diagrams that “comprehensively” describe this technology are a nightmare on their own.
Source: https://www.ibm.com/docs/en/tfim/6.2.2.6?topic=overview-oauth-20-workflow
And you probably won’t get it right the first time when implementing OAuth authentication for an API. But once configured, this is easily the most reliable way to secure your data from unauthorized access.
This method doesn’t work on its own, but rather it uses well-known identity providers as a source of truth. You probably saw that in action a lot of times already. Say you want to log into a website, and don’t want to mess with all those Firstname this and Email that. Conveniently, at the login page, there’s an option to login with Google.
That’s - you guessed it - a Google OAuth authentication option.
When you trigger Google Authentication, it redirects you to Google and inquires you to confirm that you are fine with it sharing some of your personal information as a unique identifier that will help the requesting website create a profile for you.
Programmatically, the original application makes an Authentication Request while redirecting you to an Identity Provider (In our case - Google). When you confirm, the Identity Provider issues an Authentication Grant which will be used by the original app to get an Access Token that authenticates you as a valid user. Literally two clicks - and you’re done, how about that?
That was the Authorization Code Grant flow, the most common implementation of OAuth 2.0. Other implementations include Implicit Grant, Client Credential, and Resource Owner Password Credentials Grant.
If you’re interested in taking a deeper dive into OAuth 2.0, check out this video from our CTO Shon Urbas: OAuth 2.0: Is it really a ‘standard’?
One important thing that deserves being mentioned here is that all those practices are often applied not only to human-to-machine interactions but also machine-to-machine. In a well-integrated system, an app is queried by another app in many ways similar to how it’s done by users. Most of the time, it is still an HTTP request, with the same url, payload and query parameters, only you don’t have to push any buttons to initiate such interaction.
Removing user input from the equation, though less time-consuming and much more scalable, does come with additional struggles. Without a person occasionally monitoring the server logs or data visualisation dashboards, any computer system can run wild making thousands of unwanted requests, giving out permissions left and right. Also, heavily automated systems are still vulnerable to simple user configuration errors which often result in halting the request flow for hours or days.
This list is far from conclusive, but should serve as a decent introduction into the basics of authentication for those keen to implement secure connections with services they like. After some further research, if you work with one or two services, an evening of coding will probably give you an app that could call different APIs securely enough, limited only by your programming skills.
But if you wish to support a bigger system with multiple integrations, it’s sometimes better to trust authentication into the hands of experienced developers who deal with similar challenges every day. We at Pandium will gladly relieve you of all the authentication struggles and help you make all your API integration experience smooth, fast and plentiful.
