This tutorial shows you how to create an automation token retrieval using the example of Google OAuth.
To create automation, you must configure the OAuth 2.0 authorization since these settings are used in the automation process.
Open any client application in a browser
To start creating automation, you need to analyze the login and consent screens in any browser that provides development tools (for example Chrome, Safari, Firefox, and so on).
To do it, you can go through the process of getting an access token by using any client application that runs in a suitable browser. Providers may also offer a playground to test an authorization process, so you can use it to explore the login and consent screens without using a client application.
In this tutorial, we will use Google OAuth 2.0 Playground to analyze the login and consent screens:
Open the automation script dialog
You can open the automation editor either in the Auth Manager or in the Auth panel:
Open Auth Manager.
Select the OAuth 2.0 authorization profile for which you want to enable automation.
Open the Automation script.
1. Login input
At this step, we will explore the login page and create a script that simulates a login input.
Right-click the login text box and select Inspect (or a similar menu item in your browser):
The browser shows the HTML element related to the input field. To interact with the element from the script, we need to obtain it. In our case, we can use the
getElementByIdmethod, so we need the
idattribute of the element:
You can test this command by using the Console panel of the browser:
Tip: Inserting text via script causes visual artifacts. It does not affect the script.
Now, we need to emulate clicking the Next button.
Right-click the button and select Inspect. As you can see, the button element does not have an attribute that we can use as an identifier. But we can use the parent div element that has an
idattribute - identifierNext:
To click the button, you can use the following code:
Enter the needed code in the Page 1 section of the ReadyAPI Automation script panel:
2. Enter password
On the next page, we need to input a password. Use the same approach to get the needed elements and simulate the required actions:
Right-click the password field and select Inspect. The
inputelement does not have the id attribute. Let’s use the
findElementsbyNamemethod and find the needed element by its
To method returns an array of the found elements. In our case there is only one element with the same name, so we need the first element of the array. To input the password, we can use the same approach as before:
Right-click the Next button and select Inspect. Similarly to the login page, the
buttonelement does not have the
idelement, but we can use the
idattribute of the parent
Use the following code to click the button:
Enter the needed code in the Page 2 section of the ReadyAPI Automation script panel:
3. Submit access
On the next page, Google provides you with detailed information about the client application and asks whether you want to grant permissions to it.
Right-click the Submit button and select Inspect. Again, to find the button element, we will use the
idelement of the parent
To click the button, use the following code:
On the ReadyAPI Automation script panel, click and enter the code to the added Page 3 section:
4. Test automation
If you run the script now, it cannot get an access token. It happens because ReadyAPI runs the script of Page 2 before the needed elements are actually built. You can use the
setTimeout method to run the needed function after a delay:
document.getElementsByName('password').value = 'p@ssw0rd';
// Runs the enterPassword function after 2000 milliseconds (2 sec)
Let’s add the
setTimeout function to the Page 3 section as well:
// Runs the setTimeout function after 2000 milliseconds (2 sec)
Click to test the automation:
ReadyAPI performs authorization in the internal browser and does not store cookies. So, each time ReadyAPI runs automation, the authorization process is not changed. However, if the authorization server changes the process on its own end, your script may stop working.
Background redirects may trigger a run of the next script in the list, while the page is not in fact changed. We recommend that you add logic to your script that waits for the needed elements.