Testing Complete (B2C)

Prior to launch, you should have completed all the testing that applies to your environment.

Quality Assurance is important in identifying issues before they impact your customers and, depending on the nature of your project, there are several different types of quality assurance testing that you’re going to want to consider as part of your integration with Auth0:

• Is your application easy to understand and use, even by those with a disability?

• Does your application need to work across various different browsers and devices?

• Does your application need to work in multinational and/or international environments?

• How will your application perform when subjected to unexpected production loads?

• How can you ensure your application is safe from security-related vulnerabilities?

Auth0 Universal Login and associated UI widgets (such as Lock) have already been designed and built following usability and accessibility best practices, and provide tested out-of-box support for a whole host of browsers and devices. Support for internationalization (I18N) is also provided out-of-box, with built-in extensibility designed for custom multi-language and localization (L10N) situations.

To ensure functional requirements are met and unexpected events are handled correctly, guidance is provided for testing the integration between your application(s) and Auth0, and for unit testing individual extensibility modules (such as Rules, Hooks, and Custom Database scripts). Guidance is also provided regarding Auth0's penetration testing policy to help when testing for security vulnerability, and also how Mock testing can be leveraged in conjunction with our load testing policy to help ensure your application(s) perform under unexpected load.

The objective of unit testing is to test individual units of code. If you create custom code within Auth0 in the form of Rules, Hooks, and/or Custom DB scripts, you should consider use a testing framework (such as Mocha) to test your code. Companies who have been most successful with Auth0 have found it useful to execute these unit tests prior to automatically deploying Auth0 tenant configuration and collateral.

It is a recommended best practice that you set up different tenants for development, testing, and production as discussed in Architecture guidance for SDLC support. Auth0 allows you to configure variables that are available from within custom extensibility; these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants as the code can reference variables which will be populated with tenant-specific values at execution time:

• For use of variables in Rules, see how to configure values

• For use of variables in Hooks, see how to configure secrets in the editor

• For use of variables in Custom DB Scripts, see the configuration parameters

You can automate your overall build process by incorporating deployment automation as well as test automation. This can be used to deploy new versions of configuration and/or custom code to Auth0 and execute automated tests. If the tests uncover any failures, the deployment automation capabilities can be used to revert to the last working version. For further information, see the deployment automation guidance provided.

In a balance between Auth0’s load testing policy and the desire to load test, it is common practice among Auth0’s customers to mock out Auth0’s endpoints. This is a valuable practice in order to ensure that your application works with your expected interfaces without having to restrict your testing, and tools such as MockServer, JSON Server or even Postman can be used to assist.

If you will be conducting penetration tests, you should be aware of Auth0’s penetration testing policy and abide by it. Penetration tests require advance notice to Auth0 so that your tests are not mistaken for malicious activity and shut down.

If you will be conducting load tests, you should be aware of Auth0’s load testing policy and abide by it. Load tests require advance notice to Auth0. In planning your load testing, you will also need to be aware of Auth0’s API rate limits.

Load tests require prior approval from Auth0, as explained in the Auth0 load test policy. Be sure to note the lead time for a request to be reviewed and allow enough time for review as well as conducting the tests. If your load test request has been approved, the following guidance can help avoid errors and faulty test results.

• Run an HTTP trace on a test execution of your application to identify all the calls your application or intended test needs to make, and make sure your test includes them so it is representative of what will happen in production.

• Design your test to be mindful of Auth0 API rate limits.

• Use of any custom code in Auth0 (Actions, Rules, Hooks, custom database scripts, custom OAuth connections) will invoke the Auth0 custom code sandbox and this may cost more in terms of performance. Turn off Rules unless they are essential to the test. If they are off you will have higher throughput than if they are on.

• Estimate the expected overall load for your production environment and percent of calls to each endpoint and structure your performance test accordingly so it gives you a realistic test result. Different endpoints have different performance costs. Failure to design a representative test will result in misleading results.

• Don’t make calls that depend on the results of earlier calls without checking that pre-requisite calls or responses have completed. Simply building in a delay may not be adequate.

• Be sure to implement adequate error handling. A frequent cause of issues during tests is errors in custom code (Actions, Rules, Hooks, custom database scripts, custom OAuth connection scripts) caused by unhandled exceptions in the custom code.

• Load tests should be written to start at a low level and increase the load gradually, capturing data at each level, to get the most useful results. Starting at a high level and immediately failing gives less information about what the system can sustain.

• It is normal to need to run a performance test multiple times, possibly adjusting the code under test or the test harness/configuration. Be sure to start your testing early to allow enough time for more than one iteration.

• Use your own mail provider account and make sure to arrange ahead of time for enough mail-sending quota or you may be rate-limited by the mail provider. Turn off mail sending if you do not use it.

• Be sure to use your own account credentials for all social connections rather than Auth0 dev keys. In the Auth0 dashboard, go to Connections -> Social -> {name of connection}—to see instructions for how to add your own social provider account credentials into the connection. Note: some social providers do not allow load testing. Check your provider(s) for their policy

• In order to avoid rate limiting, and more accurately simulate real load, your tests will need to send requests for different users, not all requests for the same user. If you use only one or a few users, caching may reduce the effective load and not provide realistic results.

• Be sure to stay within the agreed-upon parameters for the test and the Auth0 load test policy. Auth0 reserves the right to terminate any performance/load testing which does not stay within the bounds of agreed-upon parameters or which extends beyond the scheduled test window.

We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies.

B2C IAM Project Planning Guide