Authentication

Bearer, Basic, API key, OAuth 2.0, Digest, and AWS SigV4 auth schemes.

The Auth tab configures how a request authenticates. Auth can be set on a request directly, or inherited — a request with Inherit auth resolves to the nearest ancestor folder’s auth, so you configure credentials once per folder.

Auth fields support {{variables}}, and credentials can be backed by encrypted secret variables.

Supported schemes

SchemeUse it for
Bearer tokenA static Authorization: Bearer <token> header.
BasicUsername/password, sent base64-encoded as Authorization: Basic.
API keyA key/value pair placed in a header or a query parameter.
OAuth 2.0Client Credentials and Authorization Code (with PKCE) flows.
DigestRFC 7616 challenge-response, retried automatically with the computed digest.
AWS SigV4Signs the request with AWS Signature Version 4.

OAuth 2.0

Impostor supports the Client Credentials and Authorization Code grants, the latter with PKCE (S256). For the Authorization Code flow it spins up a temporary loopback redirect listener to capture the callback, and can refresh tokens. Access tokens obtained this way are kept in memory for the session rather than written to disk.

Digest and AWS SigV4

  • Digest auth performs the full challenge-response handshake: the first request receives the server’s challenge, and Impostor retries with the computed digest header automatically.
  • AWS SigV4 builds the canonical request, derives the signing key from your region/service/credentials, and signs the method, host, path, query, headers, and payload.

Because Digest and SigV4 are computed against a live request, they can’t be emitted by code generation.

Inheritance

Set auth on a folder via its settings, and leave child requests on Inherit to pick it up. This keeps credentials in one place and makes it easy to point a whole folder at a different environment.

When a request inherits auth, the editor shows a read-only Inherited auth panel telling you exactly what will be applied and which ancestor folder it comes from — no need to walk the tree to find out.

Securing credentials

Credential fields save into the workspace file exactly as typed, and support {{var}} references with the same highlighting as everywhere else. You have two ways to keep a credential out of the workspace file:

  • Reference a secret variable — put the value in an environment variable marked Secret and reference it as {{secret-variable}}.
  • Mark the field itself secret — click the lock button on the credential field. The value is stored encrypted on your device (never in workspace files) and the field is masked, with reveal/copy controls. Click the lock again to bring the plaintext back into the file.

Impostor surfaces a warning in the Auth editor whenever a credential field holds a literal value in cleartext rather than either of the above, so credentials can’t be accidentally leaked if the workspace is committed to version control.