These are the popular authentication methods in TestArchitect
Authentication in API testing is usually a complicated subject for both developers and testers since it requires extensive knowledge on various types of security protocols and encryption algorithms.
With that said, almost all API consumers must authenticate themselves before being granted certain privileges, such as provisioning a mobile device on the cloud or creating a new database record. This article will explain some of the most popular authentication methods and how you can work through them using TestArchitect.
What is authentication in web service testing?
Normally, a web service needs to know to whom it’s providing the service. Thus the API consumers must authenticate themselves—proving that “they are who they say they are” via various authentication methods.
A good authentication method protects the sensitive information exchanged between the client and the server. That means any malicious attackers sniffing the messages must not be able to decrypt them and get the credential of the client.
Authentication also helps the service provider classify the client and set the right permission for them (authorization). Furthermore, in the world of cloud, it helps the service provider keep track of the client’s usage to properly bill them.
Popular Authentication Methods
There are many ways to authenticate in API testing including both standard and non-standard methods. Some services creatively invent their own peculiar method or implement a variation of a popular one. Thus, when we test an API, we must be well aware of the authentication methods the API under test is using. However, technically speaking, the data used for authentication can only reside in these 3 places:
- HTTP request’s headers
e.g. basic authentication method with username/password, Digest, OAuth… - HTTP request’s body
e.g. form authentication - HTTP request’s URL
e.g. API key
We’ll focus on the most common methods which are OAuth 2.0 and API key.
API key
API key was used from the first days of web API. It’s simple and easy to use but not very secured. Developers usually choose API key when the API is not business-critical and convenience trumps security concerns, such as an API to only read weather data. Since API key exists plainly in the http messages exchanged between the client and the web service (e.g. http headers, URL), anyone sniffing the messages can obtain the API key and take advantage of it.
Systems such as YouTube or AWS require their API consumers to authenticate using an API key. They usually keep track of the user’s usage history and the number of API calls. You cannot abuse the service by calling its API indefinitely. Usually they put a limit on the number of API calls per minute.
In this example, we’ll create a script to get a list of videos associated with a specified video (caption tracks) from YouTube then verify the returned number of associated videos. For more information of this REST resource, check out this page.
- The first step is obtaining an API key from Google (available here)
NOTE: If you’re testing your in-house web service, you should contact the developer team to retrieve an API key for testing purpose. - Next, we open TestArchitect and author a test case as below
#Initial: This part sets the precondition of the test case. In this case, “I” creates a variable to store the API key.
#Test case: Verify the number of associated video.
- First, we create an http request then build the URL representing the REST resource of interest. The “build query string” action returns an URL, for instance: https://www.googleapis.com/youtube/v3/captions?part=snippet&videoId=kdcvyfjuKCw&key=AIzaSyBnyLgXvVmjxM3k4hiVVPIWG8t8CeFJSmQ
- As you might already notice, the API key is now part of the URL.
Then we send the request and handle for response result. The body of the response is a JSON string so we’re using JsonPath to query out the “item.size()” chunk. The number of associated videos of this particular video is expected to be “11”.
OAuth 2.0
OAuth 2.0 is another mature authentication method widely adopted by giant web service providers, such as Google, and Facebook.
OAuth 2.0 is the best choice for identifying personal user accounts and granting proper permissions. It requires physical confirmation from the user such as 2-step authentication to get an access token. OAuth is very secured for accessing sensitive data and services. However, disadvantages include difficulties in implementation, and that it is harder to use.
In the below example, we’ll upload an image to http://api.imgur.com with OAuth 2.0.
- To work with OAuth 2.0, we must first get the access token string. This step is different for each web service. You can manually perform this step or automate it via the web UI. Good news is it only needs to be done once.
Imgur.com has detailed instruction on how to obtain an access token here. - The next step is calling the web API with the correct authentication information. Since we want to upload an image, the http method of choice is POST. The REST end point of interest is https://api.imgur.com/3/image. For more information about this end point, check out this documentation.
#Initial: This part is used to set the precondition of the test case. In this case, we create a high level action “get token” to get the token string via UI with steps:
- Request a token by opening the correct URL on a web browser
- Confirm with the correct username and password via GUI automation
- Parse the redirect URL to get the desirable token
#Test case: Upload an image and verify the returned code
At first, we create an http request and then add authentication information to that http request by line #23.
Note: The schema should be correct. We use “OAuth 2.0” in this example.
- The rest of the test case is to configure the necessary information required by the API and send the http request. For more information, see the REST end point’s description above.
- Note: We can add an expected code to the “send http request” action or we can parse the returned value in “result” variable by the “parse http response” action. Ultimately, this test case only passes if the returned code is 200.
Conclusion
These are only two common examples representing countless ways to authenticate an API consumer in the web service testing world. We can safely conclude that authentication comes in all shapes and sizes. But the key takeaway point is: you need to understand your API under test. For each API, we’ll have to deal with one or even many authentication methods. However, don’t feel overwhelmed just yet. Like we have discussed, it all comes down to attaching the authentication information to an http request. Codeless testing is easy but only after we grasp the ropes of it.
Get TestArchitect Team Free
