How to configure advanced authentication methods

Understanding the capabilities and constraints of our web-application scanner

Joe Haigh avatar
Written by Joe Haigh
Updated over a week ago

Minimising Risk

  • We'd advise against adding admin credentials, as explained in this article.

  • Whilst the scanner can run safely on many production websites, it's usually best to stick to staging to reduce the chance of damage.

My application requires multiple forms of authentication (e.g. reCAPTCHA)

At this time (v1.2) we cannot scan an application that requires multiple forms of authentication or prove-your-humanity checks; you must choose one of the methods listed in our Quick Guide to Authenticated Web Application Scanning.

If your app uses two forms of authentication, you could set up one of the methods outlined in the link above and add our scanner IP range to the relevant allowlist to bypass the other.

Authentication is handled by a different domain

For example:



Login Request URL

Currently (v1.0) the scanner will only authenticate to URLs within the scope to be scanned. For example, if the entry point is, the logout URL would need to be something like

One workaround for this constraint is to set a long-lived session token (~24 hours) on your target application and use the session cookie authentication method.

Another option for apps using this authentication flow is to add a Recorded Login authentication method to provide the scanner with the steps needed to log in

After authenticating, there is a login redirect

For example:



Login Request URL ➡️ redirects to ➡️

There are two options for this:


  1. Add your preferred authentication method to, making the entrypoint.

  2. Add as a separate, additional external target; and using session cookie authentication, add as the entrypoint.

My application uses Multi-Factor Authentication (MFA/2FA)

Currently (v1.2) it is not possible for our scanner to bypass multi-factor authentication checks.

There are a few options for this:


Use a long-lived session token (~24 hours) the session cookie authentication method.


Allow the Intruder scanner IP range to bypass one (or both) forms of MFA / allow the user account specified in your Authentication to bypass MFA

My application uses Single-Sign-On (SSO)

Currently (v1.2) our scanner isn't able to follow specific SSO authentication workflows (including AWS Cognito/SSO, Google Identity, Microsoft AzureAD, Okta, OneLogin, Auth0, JumpCloud etc.).

The workaround for this would be to either:

  1. (if supported) Use one of the following alternative authentication methods:


  2. Add an API to your target and provide an Authorization header as an authentication method.
    Within this authentication, you would use a JSON Web Token (JWT) with a 24-hour validity period

Authentication uses a JSON-based form

Unfortunately, we don’t support applications that have a JSON-formatted login request.

The workaround for this would be to use one of the following alternative authentication methods:

Authentication uses JWT's (JSON Web Tokens)

We do handle JWT's, however we don't currently support (in v1.2) the configuration of Local Storage within our headless browser which means we may not be able to crawl SPAs that use Local Storage to present an authenticated page.

The workaround for this constraint would be to add the JWT within a Header Authentication method. To do this:

  1. Log in to your application

  2. Record the JWT

  3. Add this to your target using the Header-Based Authentication method using the Authorisation: Bearer <token> header (this will mean that we'll receive authenticated responses from the backend API)

The token needs to last for longer than the scan takes to complete - we typically recommend around 24 hours.

I have a short authentication token validity period

If you have set up an authentication on one of your targets but the authentication values (e.g. the session cookie token or the header value) validity period is quite short, then this means you will need to update this value on the Target Detail page every time before you kick off a scan on the target.

To make this as quick and easy as possible, we would recommend leveraging the capabilities to add, view, update and delete authentications from your targets using our API.

This means that you can automatically update the values in the Intruder portal without having to manually go and update them against each target.

My application uses passwordless One Time Passcode (OTP) authentication

At this time (v1.2) we are not able to retrieve the OTP sent to your email/phone number. For this reason, we would need you to use a workaround so that we can authenticate to the application without requiring the OTP code.

The workaround for this would be to use one of the following alternative authentication methods:

Did this answer your question?