Hi, currently trying to implement Passwordless for Flutter app and having issues with verify.
When using the API call as stated in the documentation the response I receive is “the following properties are not allowed: scope,password,username,grant_type”.
I tested and removed all those 4 fields and then the responses I got “Missing required property: phone_number” and “Missing required property: verification_code”. I added those 2 fields which are not in the documentation and it looks like the API processes verify correctly, the only problem is that it returns me a simple “OK” and that’s it. So how to get the token ID Token?
Tried searching for this implementation in Android, iOS SDK’s but with no luck.
So what’s the problem guys?
Hey there @martins.andersons, let me see what I can find on this front and get back to you. Thanks!
To follow up with the above question we have the following documentation on ID Tokens and this section here in the Authentication API documentation that you referenced.
openid to get an ID Token, or
openid profile email to include also user profile information in the ID Token.
Please let me know if you are still not getting having any success after taking a look at these as I continue to dive in. Thanks!
Hey just tried out but still having issues. I’m currently sending this to passwordless/verify
But the response I get is:
“error_description”: “the following properties are not allowed: scope”
If I remove the scope, then I just still receive simple “OK” and that’s it, not even JSON response.
Hey @martins.andersons, I wanted to reach out and let you know I sent you a couple direct messages. When you get a chance, take a look and let me know. Thanks!
I am having this issue as well. I managed to work my way through the “properties not allowed” errors OK, but like the OP, when I
POST /passwordless/verify with the correct properties I get a
plain/text response with simply “OK”.
From reading this documentation my understanding is that a User should be created, and assumingly I’d get a JWT back instead of just “OK”. But, that doesn’t happen
@James.Morrison I’d love if we could connect as well
Had the same issue. The documentation seems outdated.
The fields to send to /passwordless/verify are
However, like @lukerollans , I get a OK as a response instead of a JWT.
Hey there @lukerollans and @mko, welcome to the Community! After checking with our support team, I have been able to confirm that the messaging found on the Authenticate User section leveraging the
POST /passwordless/verify is still correct, which is below:
This feature is disabled by default for new tenants as of 8 June 2017. Please see Application Grant Types for more information.
This means that the
/passwordless/verify feature is no longer an available option and has been disabled. However we are investigating other alternatives for a suitable replacement but we don’t have an ETA on that solution as of yet. I apologize for any confusion on this subject.
So theres no way to authenticate a passwordless user using a custom UI on my own SPA?
I saw that message, but I assumed there was an alternative that wasn’t clearly documented. We are implementing a custom signup flow, we won’t be using a hosted page or Lock or anything like that. Our client specifically wants passwordless via SMS which is one reason we chose Auth0.
Can we have the feature turned on for our account, please? If not, we’ll have to find another provider. We will be migrating 10,000 users from a soon to be legacy system
It seems to me that Lock doesn’t work, either
When verifying the OTP, it tries to hit
/oauth/ro which 404’s, which is the same setup in the Auth0 Postman collection.
What confuses me is that, if Passwordless SMS is just no longer available, why do they happily allow the SMS with the OTP to be sent out and have leagues of documentation still published without big giant red warning messages?
I apologize but we are unable to turn on that flag for newer tenants. It’s important to note that Lock can be used in a hosted login page situation but this does not help you in your SPA usecase because it would require a redirect. I would recommend you share your usecase at Auth0.com/feedback so we can better track these types of scenarios.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.