Hi @takaya.otsu
Welcome to the Auth0 Community!
You are asking whether custom parameters (ulp-xxx) can be used with Auth0's Adaptive Consent User Login (ACUL) SDK's federatedSignup() method for social sign-up flows. You have verified that custom parameters work with federatedLogin() but do not arrive in Post-Login Actions when using federatedSignup(), even though the documentation does not explicitly state this limitation. You want to know whether this is intentional, whether there is a workaround, or whether Auth0 plans to support this in the future.
This appears to be an undocumented limitation or potential bug in the ACUL SDK. Your verification is correct and thorough. Auth0 Support needs to clarify whether this is intentional design or a bug, and provide guidance on workarounds or timelines for resolution.
Root Cause:
The discrepancy between federatedLogin() and federatedSignup() regarding custom parameter support suggests one of these causes:
- Intentional design limitation —
federatedSignup() may be designed to exclude custom parameters for security or UX reasons
- Bug in the ACUL SDK — Custom parameters may be intended to work but are not being passed through correctly in the signup flow
- Documentation gap — The behavior may be intentional but not documented, leaving developers unaware of the limitation
- Incomplete implementation — The feature may have been added to
federatedLogin() but not yet implemented for federatedSignup()
Your Verification Is Correct:
Your testing approach is sound:
- Testing method: Using
federatedSignup() and federatedLogin() with identical custom parameters and checking Post-Login Actions is the correct way to verify parameter passing
- Verification points: Checking
event.request.query, event.request.body, and event.transaction covers all the places where parameters should arrive
- Result: The parameter arrived in the login case but not in the signup case, confirming a real discrepancy
Recommended Next Steps:
1. Contact Auth0 Support directly
Create a support ticket with:
- Your tenant domain (e.g.,
dev-xxxxx.us.auth0.com)
- Your ACUL SDK version (e.g.,
@auth0/auth0-acul-react@x.x.x)
- Exact code used for both flows:
// Signup flow
federatedSignup({ connection: 'google-oauth2', 'ulp-consented_at': '<ISO timestamp>' })
// Login flow
federatedLogin({ connection: ‘google-oauth2’, ‘ulp-consented_at’: ‘<ISO timestamp>’ })
- Post-Login Action code that checks for the parameter:
exports.onExecutePostLogin = async (event, api) => {
console.log('Query:', event.request.query);
console.log('Body:', event.request.body);
console.log('Transaction:', event.transaction);
};
- Screenshots or logs showing:
- Parameter arriving in login case
- Parameter NOT arriving in signup case
- Question: Is this an intentional limitation, a bug, or a documentation gap?
2. Check the ACUL SDK documentation and changelog
Review:
- The official ACUL SDK documentation for
federatedSignup() to see if custom parameters are mentioned as unsupported
- The Auth0 changelog to see if there are any recent updates or known issues related to
federatedSignup() and custom parameters
- GitHub issues in the auth0-acul-react repository for similar reports
3. Explore potential workarounds
If Auth0 confirms this is intentional, consider:
- Using
federatedLogin() instead — If your use case allows, use federatedLogin() for both first-time and returning users (social connections treat first login as signup)
- Passing parameters via state — Use the
state parameter to pass custom data, though this is less secure and intended for CSRF prevention
- Post-login parameter injection — Use a Post-Login Action to set user metadata based on other signals (e.g.,
event.stats.logins_count === 1 to detect first login)
- Custom prompts — Use Auth0's custom prompts feature to collect additional data after signup completes
4. Request a feature enhancement
If Auth0 confirms this is a limitation, submit a feature request:
- Visit the Auth0 feedback page
- Request: Support for custom parameters in
federatedSignup()
- Justification: Parity with
federatedLogin() and the ability to pass context-specific data during social signup flows
- Use case: Tracking consent timestamps, signup source, or other metadata during federated signup
Why This Requires Auth0 Support:
- ACUL is a managed SDK — Only Auth0 engineers can confirm whether this is by design or a bug
- SDK-level behavior — This is not a configuration issue; it's a question about how the SDK processes parameters
- Potential bug — If this is unintentional, it should be reported to the Auth0 engineering team for a fix
- Documentation gap — If intentional, the documentation should be updated to clarify this limitation
Additionally, you can attempt to pass the custom parameter inside a Pre-User Registration Trigger:
Prerequisites
Custom Domain: This solution relies on Page Templates/Partials, which require a Custom Domain to be configured.
Database Connections Only: This solution works exclusively with Auth0 Database connections during the signup flow.
The tenant must be using Universal Login, and the “Customise Login Page” toggle (Classic Login) must be disabled.
Pass the parameter from the application
- Locate the login method call within the application code.
- Append the custom parameter to the
authorizationParams object.
- Prefix the parameter name with
ext-.
// Example using the Auth0 Angular SDK
this.auth.loginWithPopup({
authorizationParams: {
'ext-my_custom_param': 'your_custom_value' // The param to save
}
});
Update the Signup Prompt via Partials
Inject the parameter into the HyperText Markup Language (HTML) payload of the signup form.
NOTE: Auth0 strips out standard <input type="hidden"> elements. To bypass this, use a standard text input but hide it using inline CSS (type="text" style="display: none;").
<input
type="text"
style="display: none;"
name="ulp-my_custom_param"
value="{{ transaction.params['ext-my_custom_param'] | escape }}"
/>
Option A: Identifier First Login
If the tenant requests the email first and the password on a separate screen, update the signup-id prompt:
curl --request PUT \
--url 'https://[TENANT-NAME].[REGION].auth0.com/api/v2/prompts/signup-id/partials' \
--header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' \
--header 'Content-Type: application/json' \
--data '{
"signup-id": {
"form-content-end": "<input type=\"text\" style=\"display: none;\" name=\"ulp-my_custom_param\" value=\"{{ transaction.params['\''ext-my_custom_param'\''] | escape }}\" />"
}
}'
Option B: Identifier + Password Login (Standard)
If the tenant asks for both the Email and Password on the exact same screen, update the standard signup prompt:
curl --request PUT \
--url 'https://[TENANT-NAME].[REGION].auth0.com/api/v2/prompts/signup/partials' \
--header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' \
--header 'Content-Type: application/json' \
--data '{
"signup": {
"form-content-end": "<input type=\"text\" style=\"display: none;\" name=\"ulp-my_custom_param\" value=\"{{ transaction.params['\''ext-my_custom_param'\''] | escape }}\" />"
}
}'
Access the parameter in the Action
- In the Pre-User Registration Action, retrieve the custom parameter from the
event.request.body object.
- Save the value to the user metadata.
exports.onExecutePreUserRegistration = async (event, api) => {
// 1. Grab the value from the form submission payload
const myCustomParam = event.request.body['ulp-my_custom_param'];
// 2. Validate and write to app_metadata (or user_metadata)
if (myCustomParam) {
//api.user.setAppMetadata("my_custom_param", myCustomParam);
api.user.setUserMetadata("my_custom_param", myCustomParam);
}
};
Warning
- Query parameters can be easily manipulated by an end-user in their browser’s address bar.
- Perform backend validation inside the Action if the parameter is sensitive (for example, a “beta invite code” or “role ID”), the Action must validate it against an external API or signature before trusting it and saving it to
metadata.
Kind Regards,
Nik