Passing custom parameters through Auth0 login using state , is this recommended?

Get Help
,
1

I’m using Auth0 with Google social login and need to carry a custom parameter (like countryCode) from my app into the login flow and back to my redirect URL — even when the user cancels or gets an access_denied error.

webAuth.authorize({
connection: “google-oauth2”,
state: JSON.stringify({ countryCode: “US” })
});

My questions:

  1. Is using state to pass custom JSON data the recommended approach?

  2. Will Auth0 always return the same state value unchanged, including in error flows?

  3. Is there any issue with sending stringified or Base64-encoded JSON in state?

  4. Is there a better/official way to persist custom parameters through the entire OAuth flow?

Just looking for clarity before fully adopting this pattern.

3

Hi @azamp3139,

Welcome back to the Auth0 Community!

Here is a direct response to each of your questions:

1. Is using state to pass custom JSON data the recommended approach?

Yes. For carrying small, non-sensitive, contextual data through the Authorization Code flow and back to your application, the state parameter is the best practice. Auth0 SDKs often provide an appState option that is internally encoded into the state parameter for this exact purpose.

2. Will Auth0 always return the same state value unchanged, including in error flows?

Yes, the exact value is returned in all cases. The OAuth/OIDC specification strictly requires the Authorization Server (Auth0) to return the state parameter in the response, whether it’s a success response (containing a code) or an error response (containing an error and error_description). This allows your application to correlate the response with the original request and maintain context.

3. Is there any issue with sending stringified or Base64-encoded JSON in state?

No, this is common, but be mindful of the URL length limit.

  • Stringified JSON is fine, as long as your application URL-encodes it before sending it in the query string (which your SDK should handle).
  • Base64 encoding is also a robust option.
  • The primary concern is the maximum length of a URL, which is often around 2,048 characters across browsers. Keep your custom data small and essential to avoid the “414 Request-URI Too Large” error.

4. Is there a more official way to persist custom parameters throughout the entire OAuth flow?

No, not for this use case.

  • For small contextual data needed before and after the redirect, state is the official mechanism.
  • Alternative for extensive data: If your data payload is large or sensitive, the recommended pattern is to store the data in your server-side session or a temporary database record and use the state parameter as a unique key (or reference ID) to look up that stored data upon the callback. This keeps the URL short and prevents sensitive data from being logged in browser history or server logs.

If you have any further questions, please don’t hesitate to reach out.

Have a good one,
Vlad

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.