Read state parameter in rules


I am implementing a social provider with Auth0. I can login and it creates an account. So all that works as intended.

Now I have a use case where a user can sign-up using this new social provider but we first ask for their username (email format), after that we will redirect to the social provider where they login (as verification).

The problem, as soon as I redirect I lose all context, I can not send custom fields in the authorization request to somehow remember what they have filled in. I was thinking of maybe using something like the state.

  1. Show signup, ask for email
  2. Create Auth0 profile with provided email (save it in metadata) and save the state (can this be accessed in rules?)
  3. Redirect user to Social provider (authorization request with connection=social provider)
  4. Merge social account with previously created auth0 account by looking for the same State. (reason I need an auth0 account is I need to set thing like first name, which does not seem possible with social accounts)

Would this even work? Can we use the used state in rules?

Hi @Cryptohide and welcome to the community!

I am not sure I understand your use case. Are you simply trying to link an existing username/password user, with a social provider user? If that is the case, it can be very tricky and you should stick to our guides on this topic: User Account Linking

However, I notice you mentioned you only need an Auth0 username/password user in order to set the first name. If that is all you need, then you should instead just set the first name as an attribute in the app or user metadata for the user: Understand How Metadata Works in User Profiles

I hope that helps. Please let me know if you have any questions about that.

1 Like

Hi Thomas,

Thank you for your reply.

This use case is for registering. Users do not have an account yet. We offer them to sign up with a social provider. In the first step we ask for their email, this will be the username for their new account. Afterwards we redirect them to the social provider where they authenticate. This social provider will be merely an identity they can authenticate with but the actual username is something they choose themself and we want to do it beforehand (UX designed it that way).

When I ask for the email and redirect them to the social provider I lose all context, I have no way of telling what the user filled in in the first step.

I tried using regular sign-up from auth0 and create an account in the first step with the email they provided and afterwards try merge it with the social identity that gets created but I have no way of knowing which identity to link, I have nothing to match on. I would like to match on the email they have first provided but that seems tricky.

It is a bit like the solution here Signup with username & social connections but I need a way where I can ask for the email first and then match it with the social provider afterwards

Hi @Cryptohide

If I understand you correctly, the flow is:

  1. User inputs email address as username
  2. User authenticates with social provider (could be any email address)
  3. The email from step 1 is added to the user profile

If that is correct, then I think your UX team has made an odd decision. It is going to be very confusing for your customers (and any employees dealing with customer accounts), if the username is an email which is not necessarily the user’s email address. e.g., if I inputted my work email, but then authenticated through Google with my personal email, I might try to authenticate using my work email in the future. This is not to mention the other potential pitfalls, like developers and CS team members getting confused by this as well.

Also, I think your current architecture of using an Auth0 username/password user seems like an unnecessary level of added complexity. I would just add any additional values to the app or user metadata of the social login, and skip creating an Auth0 username/password user altogether.

All that being said, you are correct you can use the state to do this. However, the way I would do it is like so:

  1. User inputs emails
  2. App remembers state and user inputted email
  3. User signs into social provider and is then redirected back to app
  4. App looks at returned state, fetches email from localStorage, and then sends that email to your backend along with the ID token
  5. Backend adds the email to the app or user metadata for the user in Auth0

We have an article explaining this further here: Prevent Attacks and Redirect Users with OAuth 2.0 State Parameters

Will that work for you? Please let me know if you did not understand your architecture.

1 Like

Thanks for helping on this one Thomas!

Hi @thomas.osborn
I agree that it is an odd decision but business is really keen on having it.
Storing everything on metadata seems less complex indeed so I might continue with that.

You have been a great help and I think I can get it to work.

1 Like

Perfect! Glad to hear that!

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