SDK: Lock (hosted pages)
SDK Version: 11 (I think - depends on if the hosted login page is always using the last SDK)
Hi,
for a mobile app we would like to use auth0’s passwordless login in combination with universal login since we don’t want to deal with authentication our self. We need to add a few custom fields when the user is signing up. Our requirements are pretty much captured in this article here provided by auth0 (I tried to implement it, but without success). However, we are not using the database connection (we will end up using sms). How can I achieve what is described in the article I linked with the Passwordless login? An interesting fact is also that there isn’t the concept of sign up and sign in when using Passwordless mode (at least not by default). Is there a way to introduce the concept of sign up / sign in to the Passwordless universal login in combination with custom fields for the sign up?
Thanks,
Florian
P.s. I like your product(s) and SDKs, keep up the good work.
If you haven’t already, take a look here for our custom sign up docs. A common solution for adding custom fields is requiring redirect to a second sign up page after login. More on that concept here.
Thanks for the feedback,
the option you linked with the second sign up page is probably gonna work, I need to catch up with our UX designer if he is happy with the solution tho. Another question: What would be the best way to update the users metadata on that second sign up page? Is attaching them to the /continue request the best (sounds like an anti pattern to attach state changing parameters to the get request).
Another solution we considered it so build our own UI so that the user can enter name, phone number and accept the terms and conditions on the first page, press the sign up button, and then enter the verification code. I kind of got things working with the javascript SDK (WebAuth) by using the startPasswordless to request the code and passwordlessVerify to verify. The only problem right now is that I don’t know how to send custom parameters in the request (like acceptedTermsAndConditions = true. It seems to be impossible via the JS sdk. Is there a way to do it over a plain http request?
To answer the first part of your response: updating user metadata can be done with the Management APIv2. It is a really powerful resource for managing your users.
I’ll have to do some further digging about that SDK specifically.
@flle After some research it seems likes a rule or redirect would be your best bet for updating user data. Specifically, take a look here for best practices. You will want to be updating user.app_data since that is read-only to the user.
thanks for you feedback. I checked the management api and it seems like the right place to update the users metadata. I am following this guide here to update the users metadata. However, I am getting an “External interaction required” error when trying to get an access token.
I am using this on my redirect page to get an access token in order to access the management api:
let auth = new auth0.WebAuth({
domain: AUTH_CONFIG.domain,
clientID: AUTH_CONFIG.clientId,
redirectUri: AUTH_CONFIG.callbackUrl,
responseType: "token"
});
auth.checkSession({
audience: `https://$MY_DOMAIN/api/v2/`,
scope: 'update:current_user_metadata'
}
The External interaction required error is usually thrown when there’s a redirect inside one of your rules.
All your rules are executed during token renewal (silent auth), and since it happens without any user interaction, a redirect rule cannot run. In this case, you’ll need to skip the redirect rule if it’s being called for token renewal. This can be done by adding logic similar to this to the top of the relevant rule:
The context.request.query.prompt value is set to none during token renewal, so you can skip the rule if that’s the case. However, have in mind that the ‘prompt=none’ can be spoofed by anyone who adds that query string parameter to the authentication calls. In such cases, I would encourage you not to rely on this check for important or sensitive tasks that you perform in Rules.
Regarding the throttling- Yes, it something you would have to potentially manage if you had a high volume of users signing up in a very limited period of time, if I understand everything you are doing correctly. The documentation you linked touches on strategies to handle exceeding the limits if necessary. This is something we can discuss further if it ends up being an issue. Feel free to make a new topic regarding this if it becomes and issue, this helps us keeps topics compartmentalized for future reference.
Thanks for your help (again - I have the feeling I am getting closer to the solution),
I am getting another error now that I don’t know how to fix. It’s the consent_required error. I enabled the “Allow Skipping User Consent” option and I am running on 127.0.0.1 instead of localhost (which seems to cause some problems in the context of this specific error).
In such cases, I would encourage you not to rely on this check for important or sensitive tasks that you perform in Rules. I don’t know what the definition of important is in this context, we need to check for the users consent to use our application (which we have to do in order to comply with GDPR). My understanding of this is, that every rule will be bypassed when adding the code snipped you sent me. As long as there is no XSS vulnerably we should be fine since the call is created on our website, which is controlled by us. Is that about right?
Another question, this: All your rules are executed during token renewal doesn’t make sense to me. Why should a token at this point in time be renewed? It is my understanding that the user doesn’t exist in the database until I call the /continue endpoint. So what exactly is getting renewed?
Thank you for your support
Have a nice day
Edit:
I just saw that when using redirect rules, users are already persisted. Does this work with GDPR? I thought that the user needs to give consent before we persist them.
In regards to the consent_required error- since localhost resolves to 127.0.0.1, I’m not positive that using that IP will actually solve the problem. This topic seems to have a solution.
For the definition of importance and regarding the code snippet from above. That snippet will only bypass the individual rule you added it to. If you have 10 rules and the 5th has that code, only the 5th will be passed over when the condition is met. If bypassing the rule lead to a security vulnerability then it would be important not to be able to skip if you are a malicious actor.
Typically a renewal is only happening after a client has already been granted an access or id token and it sounds like your user would have already granted consent at that point if I am not mistaken. Refresh tokens prevent the client from needing to authorize or authenticate again once an existing id/access token expires.
Rules run after successful login. Take a look at the documentation regarding GDPR compliance.
- I have the feeling I am getting closer to the solution),