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 secrets in the OS keychain.
Supported schemes
| Scheme | Use it for |
|---|---|
| Bearer token | A static Authorization: Bearer <token> header. |
| Basic | Username/password, sent base64-encoded as Authorization: Basic. |
| API key | A key/value pair placed in a header or a query parameter. |
| OAuth 2.0 | Client Credentials and Authorization Code (with PKCE) flows. |
| Digest | RFC 7616 challenge-response, retried automatically with the computed digest. |
| AWS SigV4 | Signs 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.