Credentials

RequestRocket has two types of credentials that work together to secure your API traffic.

Understanding Credential Types

Proxy Credentials

Proxy credentials are used by your application to authenticate with RequestRocket's proxy service. These credentials ensure that only authorized applications can access your proxy endpoints.

When you create a proxy, you'll need to associate it with a proxy credential. This determines how your application authenticates with RequestRocket.

Target Credentials

Target credentials are used by RequestRocket to authenticate with your target APIs or services. These credentials are securely stored and used when RequestRocket forwards requests to your target endpoints.

When RequestRocket makes requests to your target API, it uses the target credential to authenticate, so your target API sees properly authenticated requests.

Supported Authentication Types

We support the creation of credentials for the following authentication types.

API Key

Used for services that require an API key in headers.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
X-API-Key: your-api-key-here

Bearer Token

OAuth 2.0 bearer token authentication.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
Authorization: Bearer your-token-here

Optional prefix: You can configure an optional prefix (e.g., Bearer , Token , or custom prefix)

JWT (JSON Web Token)

Custom JWT authentication where you provide the token.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
Authorization: your-jwt-token-here

JWT Verify

Cryptographic JWT verification for inbound requests. RequestRocket verifies the JWT signature against public keys from a JWKS endpoint (or a shared secret for HS256), rather than comparing a static token string. Designed for AI agents and service identities issued short-lived credentials by SPIFFE/SPIRE, Auth0, Okta, Cognito, Azure AD, or any standard JWT issuer.

Available for: Proxy credentials only

Example usage:

GET /api/resource HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5...

How it works: On first use, RequestRocket fetches public keys from your JWKS endpoint and caches them on the credential record. Subsequent requests with the same token are approved from cache without cryptographic re-verification. When a new token is presented (e.g. after SPIRE rotation), full verification runs again.

Required fields:

• algorithms — Signing algorithms to accept (e.g. ["RS256"], ["ES256"], ["HS256"])

Signing source (exactly one required):

• jwksUri — JWKS or SPIFFE trust bundle URL (for RS256/ES256)
• sharedSecret — Shared secret string (for HS256)

Optional claim matching (only validated when provided):

• issuer — Expected iss claim (e.g. spiffe://acmecorp.com). If omitted, any issuer is accepted.
• audience — One or more expected aud values (e.g. https://global.requestrocket.net). The token is accepted if at least one value matches. If omitted, audience is not checked.
• subject — Expected sub claim; supports wildcard suffix (e.g. spiffe://acmecorp.com/agents/*). If omitted, any subject is accepted.

Other optional fields:

• clockSkewSeconds — Tolerance for clock drift (default: 30)
• jwksRefreshHint — Override JWKS cache TTL in seconds (default: derived from bundle or 3600)
• failPolicy — Behaviour when JWKS endpoint is unreachable: fail-closed (default, safest) or fail-open (serve from stale cache)
• requiredClaims — Additional claims to validate beyond sub/iss/aud

JWT Verify uses a two-tier cache: first a fast string comparison against the last verified token, then full cryptographic verification when the token changes. This minimises latency on the hot path while remaining secure.

Azure App / Graph API Guidance

Azure Active Directory (Microsoft Entra ID) issues different token types depending on which resource you request. This distinction is critical when configuring a JWT Verify credential.

Getting the right token

To issue tokens that are validatable by JWT Verify, you must request a token scoped to your own application, not to Microsoft Graph.

Change the scope parameter in your token request from .default to api://<your-client-id>/.default:

curl --location 'https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'client_id=<your-client-id>' \
  --data-urlencode 'client_secret=<your-client-secret>' \
  --data-urlencode 'scope=api://<your-client-id>/.default'

Token version and JWKS URI

Azure AD issues either v1.0 or v2.0 tokens. You can determine which version you have by inspecting the iss claim:

To ensure v2.0 tokens are issued for your application, set accessTokenAcceptedVersion to 2 in the app manifest:

1. Go to Azure Portal → App Registrations → your app → Manifest
2. Find the "accessTokenAcceptedVersion" field
3. Change null to 2 and save

JWT Verify credential configuration for Azure AD (v2.0)

With accessTokenAcceptedVersion: 2 set and using your own app scope, configure the credential as follows:

The resulting token will have aud set to your client ID and an iss matching the v2.0 format — both verifiable by JWT Verify using standard JWKS.

Basic Auth

Username and password authentication using HTTP Basic Auth.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
Authorization: Basic base64(username:password)

OAuth2

Full OAuth2 authentication flow support.

Available for: Target credentials only

Supported flows:

• Authorization Code
• Client Credentials
• (More flows in development)

Custom

Custom authentication with configurable headers.

Available for: Target credentials only

Use case: For APIs that require custom authentication headers or non-standard authentication patterns.

Configuration:

• Additional headers
• Additional query parameters
• Additional body data

Custom Token

Dynamic token fetching from an authentication endpoint, with automatic token refresh and expiration management.

Available for: Target credentials only

Use case: For APIs that require you to fetch a token from a separate authentication endpoint before making requests. RequestRocket will automatically fetch, cache, and refresh the token as needed.

Configuration:

Testing Target Credentials

Before saving a target credential, you can send a live test request to verify it works correctly. The credential is applied to the request exactly as it would be when RequestRocket proxies real traffic — letting you catch configuration mistakes before they affect production.

How to Test

When creating a new target credential, expand the Test Credential card that appears below the Secret section. Configure your test request and click Test Credential.

What Gets Applied

The credential is converted to request headers and/or query parameters before the test request is sent:

Any additionalHeaders and additionalQueryParams configured on the credential secret are also merged into the test request.

Important Notes

Regional Constraints

Credentials are constrained to the region in which they are created. If you need to deploy proxies in multiple regions, you'll need to create credentials in each region.

Credential Management

• Viewing Secrets: Credentials secrets cannot be viewed after creation for security reasons
• Editing: You can edit credential metadata (name, notes) but not the secret values
• Deletion: Deleting a credential will also delete any associated proxy definitions since they are linked to the credential
• Multiple Credentials: You can create multiple credentials of each type

Security Features

All credential secrets are:

• Encrypted using AES-256-GCM before storage
• Never transmitted or logged in plaintext
• Securely deleted when credentials are removed

Troubleshooting

Authentication Failures

Issue: Receiving proxy-access-denied in response headers

Solution: Verify that:

1. You're using the correct proxy credential
2. The credential format matches the expected auth type
3. The credential hasn't been deleted or disabled

Target Authentication Failures

Issue: Receiving proxy-access-granted but still getting 401/403 errors

Solution: The issue is with the target credential:

1. Use the Test Credential feature when creating a new credential to verify it works before saving
2. Verify the target credential is configured correctly
3. Check that the target API credentials haven't expired
4. Ensure the target credential has necessary permissions

Next Steps