Authorizing requests

To make requests to a private API, the test runner needs to authenticate itself.

The test runner authorizes requests using the credentials in the suite's configuration.

Credentials are initially determined using the security schemes in your specification, although the settings themselves can be overridden.

There is an assumption that the test runner has access to all examples. This assumption can be used to test against invalid credentials, given that the baseline pass-rate should not change.

Supported authentication flows

Apilicious supports all authentication flows that can be defined in the API specification, but for clarification...

oAuth: Client Credentials	Supported
oAuth: Password	Supported
Bearer tokens	Supported
Basic	Supported
API Key	Supported
oAuth: Auth Code	Supported, requires one-time user login
oAuth: Implicit	Supported, requires one-time user login

oAuth flows

All standard oAuth flows defined in your specification are supported.

If an oAuth-based authorization flow fails and there are no alternative credentials, test will not continue.

Refreshable versus Static tokens

Some oAuth flows support the ability to be refreshed. This introduces an optional point of failure in the test runner.

Refreshable tokens

If configured, tokens will be refreshed regularly. Only oAuth security schemes support refreshing tokens, by omitting the refresh url, even refreshable tokens will not be re-attempted.

If a token cannot be refreshed, the tests (that require credentials) will not be added to the plan, but tests that do not require the credentials will continue.

Static tokens

API Keys, Basic Authorization and Bearer Tokens can only be updated in the configuration (or an API request), and will be used as-is.

Using static tokens can be used to reduce a point of failure in the tests themselves. It provides more control over the tokens, which can be configured however you prefer.

Alternative environments

It is possible to change the oAuth URLs to point to an alternative authentication provider.

This means that you can test against multiple environments without defining them all in your specification.

Providing multiple credentials

When providing multiple credentials, the plan will attempt to authorize all of them and put them into a pool. The suite can be configured to consistently or randomly select from this pool.

If multiple credentials are provided, only one credential needs to be valid for the test runner to continue.

Monitoring production environments

When monitoring a production environment, it is important to understand that the test runner will try everything.

Sometimes the simplest approach is to provide credentials that are isolated from everything else.

Skip operations in the suite wizard to disable actions that can perform any harm before tests are conducted. All tests have DELETE operations disabled by default, but you may want to additionally disable POST UPDATE PATCH, etc.