Theclient_id and connection parameters, crucial to the system's environment, can be obtained through various methods. One approach involves intentionally attempting to authenticate with invalid credentials.
After acquiring the client_id and connection parameters, the next step involves verifying if the system supports registration through the Auth0 API. To do this, we initiate a POST request to "/dbconnections/signup"
2 more extra parameters to the authorize? request:
code_challengecode_challenge_method
code_verifier parameter added to the token request
Check for open redirect + Authorization code reuse vulnerability + Code verifier reuse:
The code verifier is supposed to be used only once for one login attempt. Test if an attacker can reuse it to the same or different code and steal a victim session
OAuth token stealing by changing redirect_uri and Use IDN Homograph
Normal parameter
IDN Homograph
If you notice, im not using the normal e
Open Redirection on redirect_uri parameter
Normal parameter
Open Redirect
Normal Functionality versus OAuth
Create an account with victim@gmail.com with normal functionality. Create account with victim@gmail.com using OAuth functionality. Now try to login using previous credentials.
OAuth Token Re-use
Code Verifier Reuse
Improper handling of state parameter
The state parameter is used to prevent CSRF and replay attacks.
If:
It's missing, or
It's predictable or static
… then attackers can hijack login flows.
Attack Flow:
Victim logs into victim.com
Attacker reuses the same OAuth flow with captured code/state
Boom — session fixation or unauthorized login
To exploit this, go through the authorization process under your account and pause immediately after authorization. Then send this URL to the logged-in victim
CSRF Attack
Lack of origin check.
Email change
If there is an email parameter after signin then try to change the email parameter to victim's one.
Try to remove email from the scope and add victim's email manually.
Silent Login Flows Without Consent or Context
Some providers allow silent authentication using prompt=none. If not implemented carefully, this enables login without user interaction — especially dangerous in embedded browsers.
Attack Vector:
Attacker embeds an iframe with prompt=none
Victim is logged in silently
Attacker extracts tokens or forces login context into another account
Can be chained with open redirect or session confusion for stealthy account takeover.
Check if its leaking client_secret
Mixing Up client_id and Trust Levels
Some OAuth providers allow wildcard redirect URIs (https://example.com/*) for trusted apps. If attacker registers a malicious subdomain (e.g., evil.example.com), they can abuse it as a redirect_uri.
land parameter
After successful authentication, the authorization server redirects the user to a specified URI with an authorization code
Craft a URL that redirects this code to a malicious domain
