In today’s IT driven economy, web APIs are becoming increasingly used by world-wide. You’ve probably consumed or created an APIs yourself. APIs handle enormous amounts of data–one of the primary concerns software service organization are specifically looking for to secure this data. The idea is that data should be stable and secured and can be accessed by only intended users. Time, speed, and performance also matter for the APIs. Here in this article, we are going to discuss different API authentication and authorization methods that are widely used by IT organizations around the world.
Authentication vs. Authorization
If you’ve ever worked on an API, you will always see only authorization headers, not authentication headers. Did you ever wonder why? Just use any network sniffing tool like Fiddler/Wireshark, or use an API testing tools and check your application’s API. Whether you see the headers or body of an API, your API request will always find authorization. So, before we explain why APIs have only authorization not authentication, let us first explain the difference between authentication and authorization.
Authentication is nothing but validating a user if they are the right person to use that service. Let’s explain it further with a simple example. Let’s say you are visiting a restaurant in your town with your family. You open the restaurant door and you’re welcomed by the manager. But you don’t want to sit in a public dining place in the restaurant, you want to sit in a private room with family and you have to have a reservation for that. You let the manager know and they confirm you have a reservation, allowing you to sit in the restaurant private section reserved for families. So, this is what we called as authentication. You have been allowed by the restaurant’s manager to sit with your family in a private place with a valid reservation. We can say that reservation is called the authentication key.
Now, you are allowed in the private room and you can use the services reserved for private diners, etc. You are authorized to do all this, but if you go into the restaurant’s kitchen and open their refrigerator they may tell you are not allowed in this area. So this is called authorization. So you are allowed to enter, but after entering restaurant you are not authorized to go into some areas and not authorized to access some other area. So this is what authorization is.
Now when it comes to a website, anybody can enter a public website login page. Same like anybody can enter into a restaurant. Nobody is going to stop you. When you log in with your website username and password, you are authenticated and you can enter the website. Same way you accessed a reserved private table in a restaurant using a reservation. But then after entering, and after authentication, you can access some sections, but you may not be able to access some other sections which are like admin sections of website. So this is a very basic difference between authentication and authorization.
Now, back to our question. We always see authorization in an API, why it so? If you look at the API, it is pointing to an end point where that address to a particular function or resource on application. We can say, for an example, a module on the application’s back-end. When you are actually trying to access a particular resource alone in the application, it is more appropriate to call it as authorization for you, although there will be authentication to verify your identity. The first step is always authentication.
Types of HTTP Authentications
Since we’ve covered the difference between authentication and authorization, we will now discuss different types API authentications. API authentication methods are varied based on the technique they use. Authentications are very important because they directly related to your system security. That is why priority always goes to HTTP authentication in any system.
We’ll highlight five major mechanisms of adding security to an API — Basic, API Key, Bearer, OAuth1.0/OAuth 2.0, and OpenID connect. We’ll identify what they do, how they work, and advantages and disadvantages of each approach. Finally we will demonstrate load testing of an API that requires authentication using LoadView.
HTTP basic authentication are rarely used by the IT industry nowadays, because it’s very easy to be hacked, but this is the easiest method to implement. APIs will send a username and password along the body. The credentials will be encoded with encryption method such as Base64; this will convert the username and password into encrypted format for the transmission.
Since it uses the header for credentials transmission, no other complex security measures are in place. Not even session IDs or cookies.
Example of Basic Authentication in a Request Header:
Authorization: Basic Cg4sOnOlY8KyPQ==
Digest access authentication is more complex and advanced than basic authentication. Digest uses a combination of the user’s password and other attributes to create an MD5 hash. This will be then sent to server for authentication. It’s more advanced than other security mechanism since it sends the credentials as hash. It was originally created as part of RFC 2069, security enhancements were later added in RFC 2617.
In digest authentication, it’s the server who discovers the client who is trying to access the resource. The server will generate a unique value, referred to as “nonce.” Later, this unique value will be used by resource requester to generate a MD5 hash, which will be verified by server.
API keys are widely used compared to basic authentication nowadays. You can see it in mobile applications, as well as web applications. API keys were somewhat created to solve the security vulnerabilities associated with API basic mechanism. In an API key, a unique value is generated in the server-side once you authenticate with your username and password. It will be assigned to the user. Usually, this unique value is generated based on the IP address and different user attributes. Most of the time, developers will send the API key in the authorization header.
Example of an API Key
There are definitely lot of advantages of using an API key, compared to all other security mechanisms. Foremost, API keys are simple with better security. The disadvantage is anyone can pick up this security key using any of the networking sniffing tools. This can be lead to security issues of entire application.
Bearer means “a person or thing that carries or holds something.” As the name suggests, it’s an HTTP authentication scheme that involves security tokens. The bearer of security token will get access to certain functions or URLs. Bearer token will usually generated by the server in response to a client login request. Once the user has the bearer token from the server, they must send the token along with the authorization header when making further requests.
Example of Bearer Authentication
It was originally created as part of OAuth2.0 in RFC-6750. There are definitely lot of advantages of using bearer tokens compared to all other security mechanism. Bearer tokens are better in terms of security.
OAuth 1.0 and OAuth 2.0
OAuth is a more secured protocol for authorization. OAuth provides simplicity while providing authorization flow for applications. OAuth is generally used by users to log in to third-party websites using their Google, Microsoft, Facebook, Slack accounts, for example, without exposing their credentials.
OAuth 1.0 is suspected of security vulnerabilities and is no longer supported. OAuth 2.0 is with advanced security features and is the best for personal user account identification and authentication. OAuth 2.0 allows users to share their specific attributes with an application, while keeping their credentials and other information secret. OAuth 1.0 was much more complicated and less secure than OAuth 2.0. The biggest change in OAuth2.0 is that there’s no need to sign each call with a keyed hash.
Basically, OAuth consist of two tokens to do verification; an authentication token and session token. Authentication tokens work like API key security protocols, the application authenticates to access user data. Session tokens are used to maintain user session and retrieve a new authentication token if the session token is expired. OAuth 2.0 combines authentication and authorization to allow more security to the application.
In OAuth, the user will access the application with credentials. The application will then request an authentication token. The requester will send this request to an authentication server, which will allow this authentication if credentials are correct. This authentication token can be verified at any time, independent of the user. This is will make OAuth a much more secure mechanism than the other HTTP authentications. One of the major disadvantages of OAuth is the complexity to implement. You should have a sound knowledge in the OAuth flow to integrate it with your application.
OpenID Connect is an extension to the OAuth 2.0 protocol. It verifies the client identity based on the authentication performed by an authorization server. Additionally, it can get user profile information about the client. OpenID connect actually resolves lot of disadvantages of OAuth 2.0 and provides a better solution for end users and developers.
What’s the Best Authentication Protocol to Use?
HTTP basic authentication is the easiest one to implement in your application, but also not secure at all. Credentials are encoded, but are sent as plain text. Digest authentication improves on basic authentication by sending data in hashed format. But the MD5 algorithm hash is not complex at all and can be hacked very easily. API keys and bearer are almost similar and provide better security that above.
The OAuth protocol ensures that no hackers can get hold of client information. Even the application can’t get the client profile credentials and private information. OpenID Connect establishes protocols for applications to access the attributes of the client using RESTful API. OpenID Connect extends OAuth 2.0 authorization token flow by introducing new tokens. Basically, OpenID Connect is realized as an extension of OAuth 2.0.
Using LoadView to Test an API that Requires Authentication
In this section, we are going to implement HTTP API authentication using LoadView. LoadView allows you to do these tasks very easily and more efficiently. Load View provides two options for API authentication load testing:
API Authentication: Option One
If you have access to application we can get the API request using any network tool. This is the simplest method. We will show a quick demonstration for configuring each of the above HTTP authentication mechanisms using LoadView
Note: You can get API server request details and body data details from your development team or capture it using any network sniffing tool.
Step 1: Select a Load Testing Type
Log in to LoadView and under Select a Load Testing Type, select HTTP/S.
Step 2: Configure your API
The next screen will ask you to configure your API. Here we will show you how you can configure different HTTP authentication mechanisms in LoadView.
OAuth 2.0 and Open ID Connect are more complex to configure. I will show you demo for OAuth 2.0. There is an easy way to do OAuth 2.0 authentication which I will explain after this section.
Step 1: OAuth Authentication Server
Configure OAuth authentication server details.
Step 2: Credentials
Enter credentials and click login. The authentication server redirects the user to your website with a code as URL parameter.
Step 3: Server Information
The API server asks authentication server for user information.
Step 4: Access Token
The API servers identify the user and respond with an access token. User then sends the access token to the API server on each request. API server validates and give access to application.
API Authentication: Option Two
If the first option is not feasible, you can record it using the EveryStep Web Recorder recording tool. You can access it over the web and using the recorder is easier and effective. Moreover, you don’t need to learn different authentication mechanisms. Here we are going to demonstrate how to do load testing using LoadView and using the EveryStep Web Recorder. The application is using OAuth 2.0 for authentication.
Step 1: Record a New Script
Log in to LoadView and under Select a Load Testing Type, select Web Applications. Or just open the EveryStep Web Recorder, enter your URL, and start recording.
Step 2: Navigate to Login Functionality
That’s it. You have recorded application authentication, having OAuth 2.0. Replay the recorded script and make sure everything is working as expected. Isn’t it simple? Once the recording is done, you can move onto the next steps to execute your load test.
Final Thoughts: Load Testing Web APIs that Require Authentication
Correlating HTTP authentication mechanisms is not an easy task using any performance testing tool. You need to have hands-on experience and deep knowledge on how the authentication flow works. Also, it’s very important to do load testing for your login functionality. If your login module is not able to serve the expected concurrent user load, it will be huge loss for your business. You application login is a critical pieces of the functionality of your application. If you’re looking for a good end-to-end performance testing solution for your Web APIs, you will definitely like LoadView. Go ahead and give it a try today!