Page History

...

To set this up in SOAtest, you will first need to create a test scenario that gets an authorization code to use as a login suite. This login suite, in turn, is called by test scenarios that need a token. The procedure is the same whether you are using an authorization code with Proof Key for Code Exchange (PKCE) or not, though if it is with PKCE there are a couple extra variables that will need to be configured. You can create this login test suite with a convenient wizard or set it up manually. Once you have your login test suite, you can configure your test scenarios to use it to get a token without having to create it each time for every scenario.

Create a Login Test Suite with the Wizard

1. Right-click on your project folder a test suite and choose Add New > Test (.tst) File.
2. Specify a name for the test and choose Web > Record web scenario.
3. Global Property... 
4. Expand the Authentication list, then choose OAuth 2.0 and click Next.
5. Set the Grant Type to Authorization Code or Authorization Code with PKCE, as appropriate and click Next.
6. Choose Record a new login suite and click NextClick Next and choose Record new web scenario.
7. Enter the URL for the authorization endpoint URL in the Start Recording From field and click Next.
   

   Note
   Do not use the URL of the application under test (AUT), even though it automatically redirects to the authorization endpoint (that is, the login page). You want to use the URL for the authorization endpoint itself, otherwise the AUT will consume the token before you have a chance to use it in your test.

   Enable Add URL variable to your existing environment and click Finish. The login page for your application to start recording from, as appropriate for your login process, and the path to your Chrome executable. Click Finish. The login page for your application opens.
8. Log into your application. Once authorized, the Service Provider will redirect you to the callback URL with a code as part of a URL parameter.
9. Close the browser to complete the recording.
10. Run the test once to populate the tests with traffic.
11. Right-click on the test node that contains the login action (this will vary depending on your login procedure, but is usually the last test in the recorded scenario) and choose Add Output..., then enable HTTP traffic.
    Image Removed
    
12. Click Next and select the redirected URL containing the access code.
    Image Removed
    

    • The request URL will look different depending on the application used. For Azure AD, for instance, the request URL start with something like https://login.microsoftonline.com/kmsi, while for Keycloak the request URL will look something like https://localhost:8443/auth/realms/my-realm/login-actions/authenticate. In any case, the URL will contain the ?code= parameter followed by the access code.

13. Click Next and choose Response: Header > Text Data Bank to extract the code.
14. Click Finish and run the test again to populate the text data bank.
15. Open the text data bank and, in Text Content, find the redirect location containing the code (usually in a "Location" header). In that URL you should find the authorization code (preceded by the "code=" parameter). Select that code and click Create Extraction from Selection. Name it OAUTH2_AUTHORIZATION_CODE and click OK.
Recommended: Parameterize the authorization endpoint. Setting the parameters of the authentication endpoint in the login suite makes it more adaptable as a general-purpose login suite that is referenced by many tests with the OAuth 2.0 shared authentication feature. To do so:
16. Open the test in the recorded scenario that navigates to the authorization endpoint (this is usually the first test) and click the User Action tab.

In the URL field, change the following parameters from their static values to the specified test suite variables, as applicable:

ParameterVariableclient_id${OAUTH2_CLIENT_ID}redirect_id${OAUTH2_REDIRECT_URI}scope${OAUTH2_SCOPE}audience${OAUTH2_AUDIENCE}
• If you chose Authorization Code with PKCE as the Grant Type, see the next step for additional parameterizing requirements.
17. Save your changes.
If you are using an authorization code with PKCE, the authorization endpoint must be configured to accept variables for the code_challenge and code_challenge_method parameters. To do so:
18. Open the test in the recorded scenario that navigates to the authorization endpoint (this is usually the first test) and select the User Action tab.

In the URL field, change the following parameters from their static values to the specified test suite variables:

ParameterVariablecode_challenge${OAUTH2_CODE_CHALLENGE}code_challenge_method${OAUTH2_CODE_CHALLENGE_METHOD}
19. Save your changes.

...

• Login Suite: Click Workspace and select the login suite created above.
• Redirect URI: Enter a redirect URI that will not consume the OAuth 2.0 token. This URI should be on the authorization server's whitelist of redirect URIs.
• Token URI: Enter the access token endpoint on the OAuth 2.0 authorization server.
• Client ID: Enter the client ID needed for authenticating with the authorization server.
• Client Secret: Enter the client secret needed for authenticating with the authorization server.
• Scope: This parameter is used by the client to request limited access to the application. A comma-separated list of values specific to the authorization server may be entered. See https://oauth.net/2/scope/ for additional information. If no scope is specified, the default scope may be returned.
• Audience: Enter the URI of the resource server.
• Code Verifier (Authorization Code with PKCE only): Select a method for generating the code verifier. By default, this is done automatically, which is recommended. The automatically generated code verifier will comply with OAuth 2.0 standards, being a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters - . _ ~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long. If you choose a different method, ensure that the result meets the same standards, or the token request might be rejected.
• Challenge Method (Authorization Code with PKCE only): Select whether the code challenge is the plain text version of the code verifier or the SHA-256 version of the code verifier.

...

1. When you have completed your process, click Stop Recording to complete the recording.
2. Enter or select the parent folder to store the login test suite and enter a name for it. Click Finish. A dialog opens to remind you of three important things:
   • Your authorization server needs to be configured for a redirect URI that matches the call back URL (by default, http://localhost:9080/servlet/oauth2/code).
   • The SOAtest server needs to be running whenever this test is used in order to function correctly. The status of the SOAtest server can be seen on the SOAtest Server view (Parasoft > Show View > SOAtest Server). 
   • If your authorization server requires a client secret, you will need to enter it manually in the configuration (detailed below). It cannot be extracted by the wizard.
3. Click OK to dismiss the dialog. The OAuth 2.0 authentication configuration screen opens with the login suite and the settings extracted by the wizard set automatically.
   Image Added
   
4. Enter an easily identifiable name in the Name field.
5. Configure the remaining settings as described below. Some of these settings will have been extracted for you automatically and others cannot be extracted and will need to be entered manually. If you change or enter any settings, be sure that they match those in the authorization endpoint URL exactly (when applicable).
   
   • Redirect URI: By default, this is set to use the Call Back Tool and is set to its URL: http://localhost:9080/servlet/oauth2/code. This is the recommended configuration, but you can change it if necessary.
   • Token URI: Specifies the access token endpoint on the OAuth 2.0 authorization server.
   • Client ID: Specifies the client ID needed for authenticating with the authorization server.
   • Client Secret: Enter the client secret needed for authenticating with the authorization server. This cannot be extracted by the wizard and, if it's needed, must be entered manually.
   • Scope: This is used by the client to request limited access to the application. A comma-separated list of values specific to the authorization server may be entered or a parameterized value, if appropriate. See https://oauth.net/2/scope/ for additional information. If no scope is specified, the default scope may be returned.
   • Audience: Enter the URI of the resource server or a parameterized value, if appropriate. This cannot be extracted by the wizard and, if applicable, must be entered manually.
   • Code Verifier (Authorization Code with PKCE only): Select a method for generating the code verifier. By default, this is done automatically, which is recommended. The automatically generated code verifier will comply with OAuth 2.0 standards, being a cryptographically random string using the characters A-Z, a-z, 0-9, and the punctuation characters - . _ ~ (hyphen, period, underscore, and tilde), between 43 and 128 characters long. If you choose a different method, ensure that the result meets the same standards, or the token request might be rejected.
   • Challenge Method (Authorization Code with PKCE only): Select whether the code challenge is the plain text version of the code verifier or the SHA-256 version of the code verifier.
6. Select whether to send the access token using Header or Query Parameter.
7. Save your configuration.

Create a Login Test Suite Manually

1. Right-click on your project folder and choose Add New > Test (.tst) File.
2. Specify a name for the test and choose Web > Record web scenario.
3. Click Next and choose Record new web scenario.
4. Enter the URL for the authorization endpoint URL in the Start Recording From field and click Next.
   

   Note
   Do not use the URL of the application under test (AUT), even though it automatically redirects to the authorization endpoint (that is, the login page). You want to use the URL for the authorization endpoint itself, otherwise the AUT will consume the token before you have a chance to use it in your test.

5. Enable Add URL variable to your existing environment and click Finish. The login page for your application opens.
6. Log into your application. Once authorized, the Service Provider will redirect you to the callback URL with a code as part of a URL parameter.
7. Close the browser to complete the recording.
8. Run the test once to populate the tests with traffic.
9. Right-click the test suite and choose Add New > Test. The Add Test dialog opens.
10. Choose Set-Up Test > Data Generator Tool and click Finish. The Data Generator Tool opens in the workspace.
11. In the Data Generator tool, click Add, choose String, then click Finish.
12. Enter a pattern of "########" and enter "OAUTH2_STATE" as the data column name.
    Image AddedImage Added
13. Save your changes.
14. Parameterize the authorization endpoint. Setting the parameters of the authentication endpoint in the login suite makes it more adaptable as a general-purpose login suite that is referenced by many tests with the OAuth 2.0 shared authentication feature. To do so:
    1. Open the test in the recorded scenario that navigates to the authorization endpoint (this is usually the first test) and click the User Action tab.

    2. In the URL field, change the following parameters from their static values to the specified test suite variables, as applicable:

       Parameter	Variable
       client_id	${OAUTH2_CLIENT_ID}
       redirect_uri	${OAUTH2_REDIRECT_URI}
       scope	${OAUTH2_SCOPE}
       audience	${OAUTH2_AUDIENCE}
       state	${OAUTH2_STATE}

       • If you chose Authorization Code with PKCE as the Grant Type, see the next step for additional parameterizing requirements.
    3. Save your changes.
15. If you are using an authorization code with PKCE, the authorization endpoint must be configured to accept variables for the code_challenge and code_challenge_method parameters. To do so:
    1. Open the test in the recorded scenario that navigates to the authorization endpoint (this is usually the first test) and select the User Action tab.

    2. In the URL field, change the following parameters from their static values to the specified test suite variables:

       Parameter	Variable
       code_challenge	${OAUTH2_CODE_CHALLENGE}
       code_challenge_method	${OAUTH2_CODE_CHALLENGE_METHOD}

    3. Save your changes.
16. Right-click the test suite and choose Add New > Test. The Add Test dialog opens.
17. Choose Standard Test > Call Back Tool and click Finish. The Call Back Tool opens in the workspace.
18. Choose OAuth 2.0 as the protocol and Parameterized as the state. Choose OAUTH2_STATE as the column name.
    Image Added
19. Save your changes.
20. Right-click the Call Back Tool node and choose Add Output. The Add Output dialog opens.
21. Choose Incoming Request > Transport Header > REST URL Data Bank and click Finish. The REST URL Data Bank output opens in the workspace.
22. Select Parameter and click Add. Double-click the default parameter that is added and enter "code" for the parameter name and "OAUTH2_AUTHORIZATION_CODE" for the custom column name.
    Image Added
23. Save your changes.

...

Create a Test Scenario

...