Load testing with OAUTH authentication
There has always been a race between hackers and web security experts. Performance testing professionals are caught in the crossfire, since the same techniques used by hackers are the ones we use to configure test scripts.
OAUTH 2 is the de-facto authentication standard these days, and while thanks to Load Tester’s advanced editing it’s not too hard to configure a Load Tester script, there are a few extra steps you’ll need to take. Unfortunately there’s no automatic way of configuring a script since each implementation can be different. This article will show how to configure a couple of common issues we’ve encountered load testing for clients.
Header Tokens
OAUTH works by issuing session/authentication tokens which are changed dynamically for each client. Technically these can be passed to server any way data can be passed, but its common to include them in header fields.
One easy way to quickly look at your test case is use the Fields View in Header mode. Select Header from the pulldown on the right and you’ll see all of the header fields for every transaction in your recording. This creates a LOT of rows, so you’ll want to search for likely header field names, usually one with “token” or “session” in the name. Type those in the search bar, as shown below:
You can then use the standard techniques for configuring dynamic variables in Load Tester, which we’ll quickly demonstrate below. First, search for the token in the HTTP response content to see where they values are being issued. Be sure to select the entire test case for your search.
This is showing that the access token is being set on Page 3, Transaction 4, so the next step would be to configure a parser.Expand Page 3 to Transaction 4, go to the Actors Tab (at the top), the Extractors Tab (at the bottom), and create a new extractor by clicking on the green plus sign:
You then can configure the dynamic value to be parsed separate by each virtual user and placed into a user variable. This example is a simple regular expression, but you can also use simple text delimited or javascript extractors.
The variable name chosen was “access_token”, which you’ll want to write down for later. Note that you know the parser is working because the parsed text is underlined in blue on the top right, and shows up in the parsed data field at the bottom of the dialog.
The next step is to configure the value to be replaced dynamically. Go back to the Fields View configured to examine the headers, and select all of the rows that contain the token. There are a lot of them, but luckily you can edit all of them at once! Multi-select every row you want to edit, and then right-click:
Configure the field value to use the user variable you just configured in the previous step “access_token”.
You can now see in the Fields View that all of those fields have been configured for dynamic behavior:
But Wait, There’s More
Authentication is getting more complicated, and often apps will send the same token multiple ways. In this example, the app is also using a single bearer token being sent in the Authentication header, as you can see below:
This blog post on Bearer Tokens has more details, but it’s easy to configure she its using the same token as the other fields, although we’ll need to do something special because the value has the text “Bearer ” prepended to the value. To solve this we’ve edited the Datasource to use a “concatenation”:
Now the text “Bearer ” (with a space after the text) will be prepended to the authentication header value.