Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Handling Authentication Tokens

Options
Ramiro Martinez
Ramiro Martinez Posts: 53 admin
edited January 2020 in SOAtest

Handling Authentication Tokens
In this forum post I will go over the steps and tools needed to quickly and easily handle Authentication Tokens.
We will look at what tools to use when handling authentication tokens returned as a header value and authentication tokens returned in the payload of a response.
So first, a look at what is Token based authentication.
Token based authentication works as follows:
1. A user enters their Username and Password and get back a token which allows them to access specific resources
2. Extract the token from either the header or the payload of the response
3. Place the token into the request for the previously mentioned resources

Now we will go into how exactly we can do the above steps using SOAtest
Step 1: Creating the Token Request. This step can vary greatly depending on the specific service you are working on.
Create a REST client for the Authorization service to request the token.
Today I am using an internal mock to showcase this use case. In this case our request looks like the following:

For services that use HTTP authentication, Open the “HTTP Options” tab in the REST client and navigate to “HTTP Authentication” in the list on the left.

Step 2 is split into two sections. If your service returns the authentication token as a header value see ‘A’, but if the token is instead returned in the payload see ‘B’.
Step 2(a): Extracting the token from the header
For this step, we need to first identify which header has the token. To get a list of all the headers returned, chain (Right click --> Add Output) a header data bank tool to the REST client’s Response-->Transport Headers

Now run the REST client, which will populate any data banks we have chained to the REST client and then open the Header Data Bank

The Header Data Bank tool will display all the headers returned in the response.
Now to extract the Header, double click the header name associated with the authentication token. The token will then be extracted the next time this client is extracted. I suggest modifying the extraction and modifying the custom data source column to a name that is easily identifiable, but that is not 100% necessary.
And now we have an extracted authentication token.

Step 2(b): Extracting the token from the payload
For this step, we need to first identify which element in the body has the token. To get a list of all the returned elements, chain (Right click --> Add Output) a Json data bank tool (XML data bank if the response payload is XML) to the REST client’s Response-->Traffic

Now run the REST client, which will populate any data banks chained to the REST client and then open the JSON/XML Data Bank

Next either double click the element containing the token or select the element and click Extract Element. I suggest modifying the extraction, and modifying the custom data source column to a name that is easily identifiable, but that is not 100% necessary.

Step 3 Utilizing Extracted Tokens in Subsequent Clients
We now have the necessary and can call it from all types of inputs. From payload, header, or URL parameter parameterization.
I will go over three common scenarios when using authentication tokens, two simple scenarios and a more complex scenario

Scenario 1: Token in the Payload
The call is primarily described in the URL. In this case a GetAccount for John

And in the payload we have the authentication token parameterized to value returned by the authorization service:

This is simply done by setting the element to parameterized and using the text box dropdown to select the extracted token

Scenario 2 Token Set in the URL Parameters
First add a new URL parameter

Set the expected parameter name for the token, switch the drop down to “Parameterized” and use the text box drop down to select the token

Scenario 3(slightly more complex) Setting a Bearer Token Header (Similar to OAuth)
In this example the header is sent with the following format:
Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia
This cannot be done using the normal parameterization drop down
First we need to create a new header:
Open the REST client and switch to the HTTP Options tab
On the table to the left, scroll down to the HTTP Headers, and finally click add

Next, enter the header expected by the service.
Since switching to parameterized would give us the format:
Authorization: RsT5OjbzRn430zqMLgV3Ia
Instead of the expected:
Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia
We need to do something a little different, leave the dropdown on fixed then type into the text box, “Bearer ”(don’t forget the space); next we use the literal method for calling a variable ${variableName}.
So it will look like so:
Bearer ${AuthorizationToken}

And just like that, SOAtest will send the authentication token with the following format:
Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia

This concludes the guide for manipulating authentication tokens

Comments

  • benken_parasoft
    benken_parasoft Posts: 1,230 ✭✭✭
    Options

    Very nice! Also see Using OAuth 2.0.

  • goofy78270
    goofy78270 Posts: 133
    Options

    Just a NOTE: There are also extractions that may be needed, such as that of token from cookie variables within the header or complex payload which would require the use of a script or Text Databank.

  • a_nagel
    a_nagel Posts: 5
    Options

    How do I integrate the token into a header for use during a Web-driven Selenium test?

  • Matt Love
    Matt Love Posts: 92 admin
    Options

    Typically Web-driven Selenium tests do not need to do anything special with tokens. The OAuth 2.0 web application under test will forward to a login page on the authorization server, and after the Web-driven Selenium test enters credentials the authorization server will redirect back to the web application with an authorization code that can be exchanged for an access token. The token will be associated with a session in the web application, and the Web-driven Selenium test will track that session automatically using browser cookies.