Creating Authentication


Before following the instructions below, ensure that your application and authenticated resources are accessible to the Bright engine, either directly from the Internet or via a Repeater.

Configuring Authentication

  1. From the menu in the left pane of the Bright app, select Authentications.
  2. In the Authentications pane, click + Create Authentication.
  1. In the Create authentication dialog, fill in the fields as described below.
  2. After filling in all the necessary fields, in the right-bottom corner of the Create Authentication dialog, click Create.


  • The Create authentication window contains three tabs: Details, Setup, and Logout Indicators. Use the menu in the right pane of the dialog to switch between the tabs.
  • All mandatory fields are marked with an asterisk (*).
  • Bright allows testing a scan before saving it. For details, see the Testing Authentication section below.

The Details Tab



Specify the details of the authentication object you want to create.

Field Guidelines
Authentication name Enter the authentication object name.
Description Enter the authentication object description. For example, you can specify the application type or other information that helps you distinguish your created object.

Protected Resource Details


Provide the details of the authentication-protected resource.

Field Guidelines
Protocol From the drop-down list, select the HTTPS or WebSockets (currently under development) protocol to be used for authentication.
Method Select the HTTP method of an active tester end-point (authenticated resource).
Validation URL Enter the URL of the authenticated (protected) resource to test if the authentication scenario is configured correctly. The validation URL should be different from the authentication URL.
Merge Strategy Select whether the specified header must be replaced or appended with the provided value before sending each request.
Name Select an additional header to be replaced or appended before sending each request, for example, Authorization.
Value Enter the header value.
Body Enter the HTTP request body to be sent in the request sent, for example: {“user”: “foo”, “pass”: “bar”}
Maximum number of redirects to follow Enter the maximum number of redirections that Bright should follow during the authentication process.

Pro Tips: Select the checkbox Change redirected method to get for the redirects with code 302, where the server expects the following methods to always be GET during redirects and not the original method that triggered the redirect.
WebSocket frame payload extractor regex The functionality is currently under development, please skip this field.
XPath to the request identifier field The functionality is currently under development, please skip this field.
Repeater If you use a local Repeater to reach the scan target, select it from the drop-down list to connect it to the scan.

The Setup Tab

This tab allows setting authentication details.

From the Authentication type drop-down list, select the necessary authentication type, and then proceed to the authentication details. For information on how to fill in the fields for the selected authentication type, follow the relevant link below.

Current Authentication Types

Deprecated Authentication Types

For more information on each authentication type, see Authentication Types.

The Logout Indicators Tab

This section contains the options to be used during the application scanning to determine if the authentication flow is no longer valid and the authenticated resources cannot be reached. The options define how the application responds in case the authentication flow fails.

Field Guidelines
Detect using Response patterns Select if your application explicitly indicates the authentication session expiration in the body or headers, or using status codes.
  • Detect using Response STATUS
Enter the HTTP response status that will tell you about the authentication failure.
  • Detect using Response HEADER pattern
Enter the header name and Regex pattern that will help you identify the authentication failure. For example, you can use a simple Regex pattern, such as index.
  • Detect using Response BODY pattern
Enter the body pattern that will help you identify the authentication failure. For example, this Regex pattern detects a body looking for a UUID in a sessionId parameter: sessionId: \"\b(uuid:){0,1}\s*([a-f0-9\\-]*){1}\s*\".
Detect using Request patterns Select if your application does not provide any explicit indication in the body or headers when the session expires, but the client-side code redirects you to the login page, for example, based on absence of cookies or cookies expiration. In this case the only way to detect the re-login requirement is by detecting the redirect to the login URL.
  • Detect using Request URL pattern
Enter the URL pattern that will help you identify the authentication failure.

Testing Authentication

Preliminary authentication testing helps you verify if the authentication object has been configured correctly. This allows you to reveal the configuration issues timely, before running a scan.

To test your authentication object, at the bottom of the Create authentication dialog, click Test authentication.


The application displays the test results in a separate Test results tab.

  • A valid authentication object returns three success messages indicated in the relevant Test results sections:
    • Test Authentication Triggers provides the test request and response data.
    • Authentication call (fillForm #) provides a screenshot of the form filled by the engine per stage.
    • Authentication call (submitForm #) provides a screenshot of the authenticated page as evidence of the successful login.
    • Authentication call (Check Post-Login URL) provides a screenshot of the post-login URL as evidence of the successful login.
    • Access Protected Resource provides the test request and response data.

In this case, you can save the configured object and add it to your scans.

  • If the test results include a failure message, go back to the object configurations and verify their correctness. Use the test request/response data to find a certain failure and fix it.


The Bright engine only supports the set-cookie headers that are less than 4097 bytes. If the received header exceeds this limit, the engine will ignore the header and will not include it in the request/response data. Breaking the limit may also cause authentication object failure.

Did this page help you?