Add Auth0 JWT authentication to any API in minutes

The fastest path to JWT-authenticated APIs

Adding Auth0 authentication to an existing API usually means integrating an Auth0 SDK, writing middleware, handling JWKS fetching and caching, managing token expiry, and writing tests for all of it. For a greenfield service, this is a one-time cost. For a legacy API or a third-party API you don’t own, it’s often not an option.

RequestRocket can validate Auth0 JWTs at the gateway layer in front of any HTTP API — adding authentication without touching the backend at all. This guide walks through the full setup from Auth0 API registration to a production-ready proxy.

Prerequisites

You’ll need:

• An Auth0 tenant (free tier is fine for testing).
• An API registered in Auth0 (Auth0 Dashboard → Applications → APIs → Create API).
• Your Auth0 tenant domain and the API identifier (audience) you configured.

Step 1: Create the target pointing at your API

POST /clients/{clientId}/targets
{
  "targetName": "my-backend-api",
  "targetBaseURL": "https://api.myapp.com",
  "targetTestPath": "/health",
  "targetRegion": "us-east-1"
}

If your backend requires its own service token, create a target credential:

POST /clients/{clientId}/credentials
{
  "credentialType": "target",
  "credentialAuthType": "bearer",
  "credentialName": "backend-service-token",
  "credentialRegion": "us-east-1",
  "credentialSecret": {
    "token": "internal_service_token_xxxxxxxx"
  }
}

Step 2: Create the Auth0 jwtVerify proxy credential

The jwksUri is your Auth0 tenant JWKS endpoint. The audience must exactly match the API Identifier you set when registering your API in Auth0. The issuer must match your Auth0 domain (with trailing slash):

POST /clients/{clientId}/credentials
{
  "credentialType": "proxy",
  "credentialAuthType": "jwtVerify",
  "credentialName": "auth0-jwt-verify",
  "credentialRegion": "us-east-1",
  "credentialSecret": {
    "jwksUri": "https://YOUR_TENANT.us.auth0.com/.well-known/jwks.json",
    "audience": "https://api.myapp.com",
    "issuer": "https://YOUR_TENANT.us.auth0.com/"
  }
}

Replace YOUR_TENANT with your Auth0 tenant name.

Step 3: Create the proxy

Wire the target, target credential, and Auth0 verify credential together into a proxy:

POST /clients/{clientId}/proxies
{
  "proxyName": "my-api-auth0-protected",
  "proxyRegion": "us-east-1",
  "proxyProxyCredentialId": "<auth0-jwt-verify-id>",
  "proxyTargetId": "<my-backend-api-target-id>",
  "proxyTargetCredentialId": "<backend-service-token-id>",
  "proxyDefaultRuleEffect": "deny",
  "proxyAlias": "my-api"
}

Step 4: Allow authenticated access with rules

With proxyDefaultRuleEffect: "deny", you need at least one allow rule to let authenticated traffic through. A simple rule allowing all paths for authenticated callers:

POST /clients/{clientId}/proxies/{proxyId}/rules
{
  "effect": "allow",
  "methods": ["GET", "POST", "PUT", "PATCH", "DELETE"],
  "path": {
    "path": { "pattern": ".*" },
    "presence": "must_exist"
  },
  "priority": 1,
  "notes": "Allow all authenticated requests (JWT verified by proxy credential)"
}

Or, restrict to specific paths from the start — this is better practice for production:

POST /clients/{clientId}/proxies/{proxyId}/rules
{
  "effect": "allow",
  "methods": ["GET"],
  "path": {
    "path": { "pattern": "^/api/v1/(users|products|orders)(/.*)?$" },
    "presence": "must_exist"
  },
  "priority": 10,
  "notes": "Read access to users, products, and orders"
}

Step 5: Test with an Auth0 access token

Obtain a test token from Auth0’s Management API or by running an M2M client credentials flow, then call your proxy endpoint:

curl -X GET https://your-alias.requestrocket.io/api/v1/products \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."

RequestRocket validates the token against the Auth0 JWKS, confirms the audience and issuer match, checks that the token hasn’t expired, and forwards the request to your backend.

A request with a missing, invalid, or expired token receives:

HTTP/1.1 401 Unauthorized

No code was added to your backend.

Optional: enforce specific Auth0 scopes

Auth0 access tokens can include a scope claim with a space-separated list of granted permissions. Use a deny rule to require specific scopes on sensitive operations:

POST /clients/{clientId}/proxies/{proxyId}/rules
{
  "effect": "deny",
  "methods": ["DELETE"],
  "path": {
    "path": { "pattern": ".*" },
    "presence": "must_exist"
  },
  "token": [
    {
      "claim": { "pattern": "^scope$" },
      "value": { "pattern": "delete:resources" },
      "presence": "must_absent"
    }
  ],
  "notes": "Scope gate: DELETE operations require delete:resources scope"
}

What happens to the Auth0 token downstream?

By default, RequestRocket forwards the original Authorization header to the backend. Your backend can optionally read it to extract the sub or other claims for application logic — but it doesn’t need to re-verify the signature (RequestRocket already did that).

If you don’t want the original token forwarded downstream, you can strip it using a filter or use proxyAdditionalHeaders to replace it with a processed header.

Common configuration mistakes

• Wrong audience — the audience in the credentialSecret must exactly match the API Identifier in Auth0, not the application client ID.
• Trailing slash on issuer — Auth0 tokens include a trailing slash in the iss claim. Your issuer value must match: https://your-tenant.us.auth0.com/.
• Region mismatch — ensure credentialRegion and proxyRegion match if you’re using regional compliance constraints.

Next steps

The same jwtVerify credential type works with any JWKS-compatible provider — Okta, Cognito, Google, Entra ID, and custom issuers. Read the full credential documentation or start for free.