Testing Authenticated APIs: OAuth, API Keys, JWT, and More

Most real APIs reject an unauthenticated request outright, so testing one honestly means testing it with the same auth a real client would send. AlleForge natively supports 12 authentication methods — including OAuth 1.0/2.0, AWS Signature, JWT, and standard API keys — directly on a request. More importantly, it lets a whole collection inherit one auth setup instead of repeating it everywhere.

Supported auth methods

AlleForge supports a wide variety of authentication strategies out of the box, meaning you don't need to write manual pre-request scripts to generate complex signatures or tokens:

• Bearer tokens — A token sent in the Authorization header. This is the most common case for modern REST and GraphQL APIs.
• API keys — A key attached as a header or query parameter, whichever the API expects.
• OAuth 2.0 & OAuth 1.0 — For APIs that authenticate through a token exchange or complex signature generation rather than a static credential.
• JWT (JSON Web Tokens) — Dynamically generate and sign JWTs on the fly for secure server-to-server communication.
• AWS Signature — Automatically signs requests to Amazon Web Services (AWS) endpoints using your access key and secret.
• Basic & Digest Auth — Standard HTTP authentication using a username and password.
• Additional standards — We also support NTLM, Hawk Authentication, EdgeGrid, and ASAP for specialized enterprise or legacy systems.

Inherited auth

Configuring authentication on every single request in a collection gets tedious fast, and it's easy for one request to fall out of sync when a token rotates. Inherited auth solves this by letting a folder or collection define auth once — every request inside it uses that same configuration unless it explicitly overrides it.

In practice, that means:

1. Set the bearer token (or API key, OAuth config, etc.) on the collection itself.
2. Every request inside inherits it automatically.
3. Rotate the token in one place — an environment variable is the natural place to store it — and every request picks up the new value on the next send.

Keeping tokens out of plain view

Auth values are exactly the kind of data you don't want sitting in a shared workspace as plain text. Sensitive values can be marked as secret, which masks them in the UI and excludes them from shared exports — so a teammate can use a request that requires your token without ever seeing the token itself. Requests, environments, and secrets are encrypted both at rest and in transit.

Where this shows up elsewhere

If you're testing an API that's protected behind both authentication and something that only exists on a private network — an internal auth server, for instance — you'll likely also need AlleForge Agent to reach it from the browser at all.

If the API you're authenticating against is an AI/LLM provider specifically, the auth header itself often differs from the plain bearer-token case above — see AI API authentication for the concrete differences.