How To Better Handle Authentication In API Test Automation
We need a better way to properly handle APIs authentication in our automated tests.
APIs are the cornerstone of distributed systems. They enable the composition of services to deliver more valuable experiences. While APIs can be powerful, they must ensure secured access.
Testing APIs can be a frustrating experience. We can spend more time trying to connect to the API rather than testing it. Delays in automated tests implementation are costly as slowing down the lead-time for changes.
In this article, we share a concrete way to design your tests for handling APIs authentication limiting code and duplication. At the end of the article, you will have a reusable structure for your automated tests:
- Understand the authentication flow and data
- Implement a reliable authentication layer
- Create a reusable authentication block with property
- Expand your API test automation with ease
Our first step is to understand the authentication steps.
Understand the authentication flow and data
APIs normally rely on authentication standards. It can be a simple token, OAuth, OpenID, among others. The key point is to understand the sequence of calls and the data involved.
In our case, the API uses a Bearer token. It requires an initial call, usually with credentials, to retrieve the token. Then each call requires a specific token within the header to accept the calls.
In the case of a REST API, the steps involved are as follows:
- Creates a JWT assertion with the shared secret and the oauthClientId, and then POSTs it to the authorization server.
- Authorization server returns an OAuth 2.0 access token.
- App uses the access token to perform actions as a user.
Let’s see how to implement these steps.
Implement a reliable authentication layer
Testing APIs is more technical than for a web or mobile application. The authentication implementation can be clarified by looking at the API documentation or talking with the developer if needed.
The first difficulty in test automation is to perform the initial call and keep the token for the following calls. The right way to achieve that in Cerberus Testing is to perform the initial call and store the token inside a Property.
The API being in REST/JSON, we can use the simple locator of “$.access_token” available in the answer to retrieve it. That way, each time this test runs, an instance of the token will be stored.
The next step is to implement a reusable block for all our tests.
Create a reusable authentication block with property
The API call requires the bearer token within the header. Hence, we have to configure the token within the service library of Cerberus. For other protocols, we would need to configure parameters at the test actions level.
Cerberus Testing enable to dynamically set and retrieve properties. Hence we just have to use the % delimiter to identify a property within other elements. In our case, the property to set in the header is “%access_token%”.
The Bearer standard requires the word “Bearer”, explaining its presence before the property. We can use this configuration in any test we want. In this example, we perform a POST to a specific endpoint to initiate a transaction using the token.
This structure is replicable for all our tests using the library.
Expand your API test automation with ease
Steps contain the actions and controls of the automated test inside Cerberus Testing. Each step can be part of a library and becomes available in other tests while being locked for edition.
In our case, we added the “Get Authentication” step inside our library. That enables us to create as many tests as we want using the same structure.
That way, we can implement our functional tests. The tests just require a template structure, and we have only one place to change in the case of authentication changes.
You can rely on the same technique for different authentication protocols and even SOAP or GraphQL APIs. There is no time to lose, hence the value of a framework.
Stop Coding, Start Testing here.