QuotaGuard gives your Auth0 integration two fixed outbound IPs, so you can lock Management API access to a source-IP allowlist that refuses every other caller.
Auth0 has no built-in setting to restrict the Management API by IP. The supported pattern is a Credentials Exchange Action that checks the caller's IP, and that check only works when your app leaves from a stable address. Rotating cloud IPs make it unusable.
Set one environment variable, route your Auth0 calls through QuotaGuard, and register the two IPs once. They stay fixed through deploys, restarts, and plan changes.
You can enforce which IPs are allowed to mint and use Management API tokens, and QuotaGuard supplies the fixed addresses that make it enforceable. Auth0 exposes no native "restrict the Management API by source IP" toggle, so the enforcement lives in an Action you own.
The moment a machine-to-machine token is scoped to /api/v2/, a leaked client secret can manage your entire tenant. Pinning the caller to a known IP closes that gap.
Auth0's recommended pattern is an Action on the onExecuteCredentialsExchange trigger that inspects event.request.ip and denies the token when the caller is not on your allowlist. Scope it to the Management API resource server so it gates only M2M exchanges, not every login.
Your subscription includes two static IPs behind a load balancer. Add both to the Action's allowlist array so a request served by either one passes. No token exchange leaves from an address Auth0 has not seen before.
With the IP check in place, a stolen M2M client ID and secret are useless from anywhere but your two QuotaGuard IPs. The credential and the network origin both have to match before Auth0 issues the token.
If you run Auth0's Tenant Access Control List, you get a second enforcement point that accepts your two QuotaGuard IPs as an allow rule. It applies at the tenant edge, in front of both the Authentication path and the Management API.
Tenant ACL rules match on IPv4 and IPv6 CIDR, with allow, block, and log actions. Enforcement covers the Authentication endpoints and the Management API paths under /api/v2/ and /scim/, so one allow rule can cover both surfaces.
Auth0 is hosted, so you do not put a reverse proxy in front of it. You give your own callers a fixed egress IP with QuotaGuard, then add that IP to the Tenant ACL allow rule. Everything from an unknown address is blocked or logged.
Tenant ACL is an Enterprise-plan feature with the Attack Protection add-on, and has shipped as Early Access. The Section 1 Action pattern needs none of that, so most teams start there and layer Tenant ACL on when they qualify.
QuotaGuard Static satisfies the allowlist for most Auth0 integrations. When the identity data crossing the connection is regulated, Shield keeps it encrypted end to end. The reliability underneath is the same on both.
Each subscription runs a load-balanced pair with health checks and automatic failover. Register both on the Auth0 side once, and traffic routes through whichever IP responds, so a single-node issue never breaks token issuance.
When your Auth0 traffic carries PII or falls under SOC 2, PCI-DSS, or HIPAA review, QuotaGuard Shield uses SSL passthrough and does not decrypt the payload in ordinary operation. Static remains the right choice for standard configuration and user-management calls.
Proxies run in eleven AWS regions, selected at sign-up so your calls reach Auth0's region with low latency. Your two IPs stay the same when you upgrade or downgrade, so an Auth0 allowlist you set once keeps working.
Common questions about Auth0 static IPs and QuotaGuard.
Does my Auth0 integration need a static IP?
Only if you want to restrict who can reach your tenant by network origin, which most security teams do for the Management API. Auth0 has no built-in Management API IP restriction, so you enforce it yourself with a Credentials Exchange Action or with Tenant ACL, and both need your caller to leave from a fixed IP. If you never restrict by IP, you do not need one. The moment you do, a rotating cloud IP makes the rule impossible to maintain.
How fast can I set up QuotaGuard for Auth0?
About 2 minutes on the QuotaGuard side: add one environment variable and point your HTTP client at QuotaGuard as the proxy for outbound calls to your Auth0 domain. Then paste your two static IPs into the Action's allowlist array or your Tenant ACL allow rule. The Auth0 side is a small code or config change, not a migration.
How do I restrict the Auth0 Management API by IP if there is no native setting?
Add an Action on the onExecuteCredentialsExchange trigger that reads event.request.ip and denies the exchange when the IP is not on your list. Scope it to the Management API resource server so you gate M2M token exchanges without affecting interactive logins. The check is only reliable when the caller's egress IP is fixed, which is what the two QuotaGuard IPs provide.
Should I use QuotaGuard Static or Shield for Auth0?
Static is sufficient for standard Management API and Authentication API calls, and it satisfies the IP allowlist requirement. Use Shield when the identity data in transit is regulated PII or your architecture is under SOC 2, PCI-DSS, or HIPAA review, because Shield uses SSL passthrough and does not decrypt the payload in ordinary operation. Some teams run Static for configuration traffic and Shield for flows that touch regulated user data.
What is Tenant Access Control List and do I need it?
Tenant ACL is an Auth0 feature that filters inbound traffic to your tenant by IPv4 and IPv6 CIDR with allow, block, and log actions, across both the Authentication path and the Management API under /api/v2/ and /scim/. It is an Enterprise-plan feature with the Attack Protection add-on and has shipped as Early Access, so not every tenant can turn it on. If you cannot, the Credentials Exchange Action gives you IP enforcement without it.
Does Auth0 support CIDR ranges in the allowlist?
Yes. Tenant ACL rules accept IPv4 and IPv6 CIDR, and the Action pattern lets you compare against whatever list you define. The problem is never Auth0's format. It is that PaaS hosts like Render, Railway, Heroku, and Fly.io do not publish narrow CIDR blocks, so allowlisting your platform's range would trust every other tenant on it. Two specific QuotaGuard IPs keep the rule tight.
Can I get a dedicated IP for Auth0?
Yes. Dedicated IPs are included on QuotaGuard Enterprise plans, at $219/month for Static and $269/month for Shield on direct billing. A dedicated pair is appropriate when your Auth0 allowlist must not share an origin with any other organization's traffic. Contact QuotaGuard support after signup with your username and preferred region.
What about inbound traffic from Auth0, like Actions and Log Streams?
Those flow in the opposite direction, from Auth0 out to your endpoint, and Auth0 publishes its own egress ranges at cdn.auth0.com/ip-ranges.json for you to allowlist on your side. QuotaGuard handles the outbound path from your app to Auth0. If you also need a fixed inbound endpoint for a callback receiver, QuotaGuard Static includes inbound proxy capability on direct plans starting at $19/month.
For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.
Get the fixed identity and security your application needs today.