Integration / Auth0

Connect Auth0 to CYBRET.

CYBRET reads your Auth0 tenants, treats Actions code as application code, and joins customer-identity flows into the same attack graph as your cloud and your APIs. The custom Action that mints a scope is the same node as the API that trusts it.

What CYBRET sees on Auth0

Tenants, applications, and the code that runs in between.

Auth0 is unusual in that the tenant configuration is half data and half code. Rules, Hooks, and Actions are JavaScript that runs in the authorization pipeline. CYBRET reads them as code, traces what they mutate (scopes, claims, app metadata), and joins that to the applications that trust the resulting tokens.

  • Tenants and applications: all applications, their grant types, allowed callbacks, allowed origins, refresh token settings, custom domains.
  • APIs and scopes: resource servers, defined scopes, RBAC settings, default audience.
  • Actions, Rules, and Hooks: source code, deployed versions, trigger bindings (Login, Pre-User-Registration, Post-User-Registration, Machine-to-Machine).
  • Users: profile shape (we read shapes, not bulk PII), connection associations, app metadata, user metadata schema.
  • Connections: database, social, enterprise (SAML, OIDC, ADFS) connection configurations and the apps they're enabled for.
  • Roles and permissions: Auth0 RBAC roles, permissions, and assignments to users / groups.
  • Telemetry: Management API audit logs, log streams (HTTP, Datadog, Splunk) for runtime correlation.
Three real attack-path examples

What we find in the first week.

Auth0 paths usually involve a custom piece of pipeline code interacting with an application that trusts its output. These are the patterns we see most often.

1. Custom Action mints elevated scopes for any user with a flag

Login Action reads user.app_metadata.is_internal → if true, adds admin:write to access token → user-controlled metadata field via password reset path.

The Action grants admin scope based on a metadata flag. The flag is writable through a password-reset Action that copies a self-supplied attribute. CYBRET reads both Action sources, models the metadata mutation, and traces the path from a self-served signup to an admin-scoped access token. The fix is moving the decision off user-writable metadata.

2. Connection profile leaks raw social claims to a trusting app

Social connection with useGenericProfile: false → raw provider claims passed through → backend trusts email_verified from a provider that does not verify email.

The connection is configured to keep the original provider profile rather than the normalised generic profile. The downstream API trusts email_verified as a security claim, but the provider in question doesn't verify email. CYBRET reads the connection configuration, joins it to the resource-server claim requirements, and surfaces the trust-boundary mismatch.

3. Leaked M2M client_secret with broad Management API scopes

Machine-to-machine app with read:users + read:logs on the Management API → client_secret in a deprecated CI script → full PII dump of every user.

CYBRET enumerates M2M apps and their granted Management API scopes, then joins them to credential-leak signals from your code and CI. The path is closed by rotating the secret, scoping the M2M app down, and routing through the IP-allowlist option on the Management API.

How the integration works

One M2M app with read-only Management API scopes.

The integration uses a Machine-to-Machine application registered in your Auth0 tenant against the Management API, with read-only scopes. For Auth0 Private Cloud and Enterprise tenants, the same model applies; the Management API is reachable from the CYBRET tenant.

  1. Open the CYBRET console and go to Integrations → Auth0.
  2. Click Connect Auth0. Enter your Auth0 tenant domain.
  3. In Auth0, create a new M2M application. Authorize it for the Management API with the read scopes shown in the CYBRET console (read:client_grants, read:clients, read:resource_servers, read:rules, read:hooks, read:actions, read:roles, read:connections, read:logs).
  4. Paste the M2M client ID and client secret back into the CYBRET console; the secret is stored in your per-tenant CYBRET vault.
  5. Configure a Log Stream pointing at the CYBRET ingestion endpoint for runtime correlation. CYBRET provides the URL and the verification token.
  6. The first inventory pass typically completes inside ten minutes. Auth0 nodes appear in Exposure Intelligence as they index.

Disconnect by deleting the M2M application or revoking its grant. CYBRET stops ingesting at the next poll.

Permissions and data scope

Read-only Management API scopes. No agents.

The integration requests read scopes only against the Auth0 Management API. Nothing in the default scope grants a write to clients, connections, roles, or rules. Action and rule source is read; user metadata schema is read; bulk user PII is not exported. There is no agent to install. We support the Management API IP allowlist; CYBRET egress IPs are stable and published per region.

For runtime detection, an Auth0 Log Stream forwards tenant logs over TLS to the customer-tenancy CYBRET deployment. Customers who already stream logs to Splunk or Datadog can fan out to CYBRET as a second destination.

How Auth0 maps to the three CYBRET products

Where Auth0 data shows up in the platform.

Exposure Intelligence uses Auth0 as the customer-identity layer of the graph. Many of the sharpest findings on Auth0 connect involve a custom Action mutating a claim that the application code then trusts. Exposure resolves both sides into the same path.

Validation uses Auth0 context to construct identities at the right grant level for proof-of-exploit. When CYBRET claims a BOLA path requires a specific scope set, Validation requests the matching token from a sandbox tenant rather than tampering with production grants.

Runtime Detection consumes Auth0 Log Streams to alert on identity events tied to surfaced paths. A new M2M grant on a Management API scope, a Rule deployed without review, or a sudden burst of failed-login bypasses become runtime events linked to the affected paths.

FAQ

Questions security engineers actually ask.

How does authentication work?

A Machine-to-Machine application registered in your tenant with read-only Management API scopes. Client secrets live in a per-tenant CYBRET vault. We support the Management API IP allowlist; our egress IPs are stable per region.

Where does the Auth0 data live?

Inside the CYBRET deployment in your VPC. EU customers run an EU-resident control plane; US customers run a US one. We do not move Auth0 data to a multi-tenant SaaS backend.

Is this read-only?

Yes. The default M2M scope is read-only. We do not deploy Actions, modify connections, or create users on your behalf. Customers can opt in to a write-scoped configuration for the optional Validation auto-rotation feature; that is off by default.

Multi-tenant Auth0?

Supported. Each Auth0 tenant connects as a separate integration; CYBRET treats them as separate identity zones in the graph and resolves cross-tenant trust where applicable.

Auth0 Private Cloud and Enterprise?

Supported. The Management API is reachable from the CYBRET tenant; the same M2M model applies. PrivateLink-style isolation is supported for customers with custom domains and in-VPC Auth0 deployments.

How do you handle Management API rate limits?

We use the bulk endpoints (clients, users metadata, connections) where available, paginate carefully, and respect rate-limit headers. Tenants with thousands of clients and Actions complete first build inside a few hours.

Next step

Connect Auth0 →

Treat your Actions and Rules as the application code they are. Custom Action paths usually surface inside the first day.

Connect Auth0See Exposure Intelligence