Every mock API created has its own admin API (think of it as a standalone WireMock server per API), which is used for stubbing, verification, reset and a few other things.
This has the same base URL as your mock API, with a base path of /__admin e.g. https://example.wiremockapi.cloud/__admin.By default this is secured using the API token that can be found in https://app.wiremock.cloud/account/security.The token can either be sent in an Authorization header e.g.Authorization:Token 1kj3h98f7sihjfsfor as a query parameter e.g.https://example.wiremockapi.cloud/__admin/mappings?apiToken=1kj3h98f7sihjfsf.It is recommended that you use the header approach where possible as this reduces the risk of the key appearing in log files an browser histories.
Mock APIs can optionally be configured to authenticate callers. At present this can
be via HTTP Basic authentication (username + password) or an arbitrary header match,
as well as OpenID Connect authentication for Enterprise plan users.
HTTP Basic is a widely supported part of the HTTP standard supporting username/password authentication.
An HTTP resource secured with HTTP Basic will result in a browser prompting the user
with a username/password dialogue box on their initial visit.Alternatively, an API client can pre-emptively authenticate by sending a header of the form
Authorization:Basic <base64 encoded username:password>.
WireMock Cloud can also authenticate requests based on a match expression against any header.
The match expression works in the same way as header matches in the stub creation form,
whereby you specify the header name, predicate and expected value.
For Enterprise plan users, WireMock Cloud can authenticate requests via an
OpenID Connect authorization server.
Requests must contain an HTTP header whose value is a JWT generated by the configured authorization
server.
The value of the Authorization header field must be the name of the HTTP header that will contain the JWT (usually
Authorization, but any valid HTTP header name is allowed).
The value of the Issuer URL field must be the base URL of the authorization server.The authorization server is expected to be configured as per
the OpenID Connect specification.
Specifically /.well-known/openid-configuration contains the required configuration information, including the URL to
the JSON Web Key Set (JWKS) that contains the key(s) to verify the JWTs’ signatures.The value of the Audiences field can optionally be a set of required audiences.
If this field’s value is non-empty, every JWT’s
aud claim must contain all of these audiences for the
JWT to be considered valid.