How to pass an ID into a signup flow securely?

[leandro.iriarte]

We have a rule that currently sets a custom claim as an id, and the value is generated within the rule.

We would like to actually pass this value into the signup flow securely. We understand that we can send the value via POST for /oauth/token (for email/password flows) and via GET to /authorize endpoint (for social/Authorization Code flow).

Is there any way to do this securely?

We were thinking about some verifier or key as used by the Authorization Code Flow with Proof Key for Code Exchange (PKCE).

Any recommendations/advice are welcome.

[dan.woda]

Can you tell us more about the nature of the ID and the use-case? Why is passing to a rule not sufficient?

[leandro.iriarte]

So anonymous users get an ID. When those users signup, we would like to use the same ID, instead of creating a new one in a rule as we are doing now.

The issue is that /authorize is a public endpoint and we don’t want attackers signing up with other IDs.

We thought about creating a short-lived single-use token with the ID as a claim and send it to /authorize.

[dan.woda]

I have a couple of follow up questions.

Is the /authorize request coming from a public client like a SPA?

When the ID is originally assigned to the anonymous user, are you storing it in your DB as well?

[leandro.iriarte]

Yes, it comes from mobile apps.

No, it is not stored so we cannot check the same store for validity.

[dan.woda]

Hm, I don’t know of an Auth0 feature that solves for this.

Are you just generating an UUID? Is collision the only thing you are concerned about?

[leandro.iriarte]

Yes, we are generating a UUID.

Collisions are not the issue. The goal is to keep the same id when an anonymous user signs up. But we don’t want malicious users trying to sign up with random or other people anonymous ID. That’s why the idea of the single-use short-lived jwt just to pass the utid to the sign-up flow.

[dan.woda]

I think the issue here lies in the fact that you are trying to validate something that was created in an untrusted public client. Without issuing the UTID(or JWT) from a trusted client like a backend API, I don’t think you will find a simple way to be sure it is genuine.

[leandro.iriarte]

Ok thanks.

Just one more queston:
For social (Authorization Code) flows the rules run on the authorize endpoint, and for Resource Owner Password Grant flows (and OTP) on the oauth/token endpoint. Is this correct?

[dan.woda]

Do you mean these Rules?

They run after successful authentication, which would be after a user submits credentials and they are authenticated, not specifically on a call to any endpoint.

Does that make sense? I find this graphic really helpful in visualizing where each piece of the puzzle sits.