Backdooring the IdP: Auth0 Management API persistence that outlives the token

An Auth0 Management API token is a machine credential that can rewrite the identity provider itself: create clients, deploy Actions, change the login flow. That makes it the most dangerous token in the tenant, because the persistence it leaves behind outlives the token that created it.

How the attack works

The tenant-admin-scoped token is used from a host outside the normal admin infrastructure. It creates a rogue application or client with a known secret, capable of silently obtaining tokens for downstream apps, then deploys a malicious post-login Action, or legacy Rule, that backdoors the login flow for everyone who signs in. The rogue client then issues access tokens with no user present, exercising the persistence. In ATT&CK terms this is T1098, Account Manipulation, with T1556, Modify Authentication Process, and T1136 for the created client.

Why it works

The Management API legitimately creates clients and deploys Actions during normal administration, so the calls look ordinary. The deviation is an unmanaged change from a new source, followed by a client issuing tokens with no user in the flow. Because the change lives in the IdP config, it survives password resets and outlives the original token.

How to fix it

Containment is two-part. Revoke or rotate the Management API token to stop new changes, and delete the rogue client and the malicious Action to tear out the backdoor, then check for any added admin grants. Rotating the token alone is the classic mistake that leaves the backdoor live. Scope the tenant logs for every config change and every rogue-client token issuance. For the class, scope M2M apps to least-privilege Management API scopes, restrict source IPs, and alert on client and Action changes. An IdP compromise puts every relying application in scope.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse removing both the token and the persistence it planted in the IdP.