Auth0 Home Blog Docs

Passwordless SMS: trying to log back in with an active session, "no phone_number or verification code"

session
passwordless
authorize
passwordless-sms
#5

Here’s our case:

I am using Passwordless login with Auth0 which is working fine from past few weeks. Recently I have received complaints from team members that they are having trouble logging in to the system. Following are the insights:

react-native-auth0 is the client being used.
Invocation method: Auth0.webAuth.authorize({…config})
API endpoint: https:///userinfo
scope: “openid offline_access”,
Error Message:
“error”: {
“message”: “no phone_number or no verification_code provided”,
“oauthError”: “access_denied”,
“type”: “oauth-authorization”
},

This issue is being raised on android/ios platforms.
Please help me out on this issue and let me know if further details are required.

Regards,
Ashutosh Mishra

1 Like
"Wrong email or verification code" on Magic Link click
Passwordless "no email or no verification_code provided"
#6

Hey everyone I reached out to our developer support team. Once I have any info to share I’ll update you with that!

1 Like
#7

Hi,

I’m trying to setup Passwordless authentication with SMS and I’m facing the same error.

Here is my authorize url :

https://goferworkondemand.eu.auth0.com/authorize?audience=https%3A%2F%2Fweb.gofer.fr%2Fgraphql&client_id=rL0Dg3IcWoRUTYC8uQ8083QcpmGC2eND&code_challenge=n9bLRBpfxTwJmadL-CIriA-RPtI2J3aTB4I5Vq0DsWQ&code_challenge_method=S256&connection=sms&redirect_uri=exp%3A%2F%2F127.0.0.1%3A19000%2F--%2Fauthorize%2Fcallback&response_type=code&scope=offline_access%20openid%20profile%20email%20update%3Acurrent_user_identities

1 Like
#8

+1, also seeing this for “magic link”:

{"error":"access_denied","errorDescription":"no email or no verification_code provided","state":"3Jlsq6F994xGUU2eLrO~ZOiC6fPP2k93"}

Example log_id: 90020190213103454082543582805344692234699492240633364482

1 Like
#9

Hey folks!

I escalated all those cases to our developer support team. Let me get back to you once I have something from them to share!

1 Like
#10

We had similar issue in Production today and wondering if any further updates on this.

Thank you,

Sachin

2 Likes
#11

Hey everyone!

Our team is trying to reproduce it and establish a reasoning behind such behaviour. Once we have news to share you’ll be first to hear them!

1 Like
#12

Thank you for your response. We’ve been encountering this for the past few days & it is a blocker for users that have signed out locally in our Ionic app as they cannot successfully prompt for a new login.

2 Likes
#13

Thanks for reporting that @LordParsley!

I just pinged back our developer support team to see if they found out something already.

1 Like
#14

Much appreciated @konrad.sopala.

May I ask – has anyone in this thread found a successful workaround? We can only seem to prevent it by deleting the user which is mostly not feasible.

1 Like
#15

Hi, @konrad.sopala,

Thanks for escalating this issue. This has become a blocker for us. Here is some additional information on how I’m experiencing this problem. No code/tenant configuration has changed.

I’m constructing an AuthorizationUrl via the BuildAuthorizationUrl() method provided by the AuthnticationApiClient as shown below

        string url = _authenticationApiClient.BuildAuthorizationUrl()
            .WithResponseType(AuthorizationResponseType.Code)
            .WithClient("Client identifier")
            .WithRedirectUrl("the endpoint that I should be redirected to.")
            .WithScope("openid")
            .WithValue("prompt","login") 
            .WithValue("login_hint", "email address passed as login hint") 
            .Build().ToString();

        return Redirect(url);

The behavior before I experienced the issue was that the redirect would take me to the Auth0 login page as expected by passing through the prompt=login parameter. Once I completed that stage I would then be redirected back to the redirect Url specified.

But now, I not presented with the login page instead an error is being returned back indicating a failure at the authorization endpoint.

The Auth0 logs for the tenant show the following. (See main error in bold)

{
“date”: “2019-02-14T17:16:37.061Z”,
“type”: “f”,
“description”: “no email or no verification_code provided”,
“connection_id”: “”,
“client_id”: “SENSITIVE INFORMATION”,
“client_name”: “SENSITIVE INFORMATION”,
“ip”: “SENSITIVE INFORMATION”,
“user_agent”: “Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36”,
“details”: {
“body”: {},
“qs”: {
“response_type”: “code”,
“client_id”: “SENSITIVE INFORMATION”,
“redirect_uri”: “SENSITIVE INFORMATION”,
“scope”: “openid”,
“prompt”: “login”,
“login_hint”: “SENSITIVE INFORMATION
},
"error": {
"message": “no email or no verification_code provided”,
"oauthError": “access_denied”,
"type": "oauth-authorization"
},
“session_id”: “mFL-1ZS4AlqRJHWVLwtxs4kF8JVAZ-cM”
},
“hostname”: “SENSITIVE INFORMATION”,
“user_id”: “SENSITIVE INFORMATION”,
“user_name”: “SENSITIVE INFORMATION”,
“audience”: “https://SENSITIVE INFORMATION/userinfo”,
“scope”: [
“openid”
],
“log_id”: “90020190214171637061851047972789516372534476022451535874”
}

2 Likes
#16

This issue happens across different tenants (including production ones) and Auth0 customers in the last several days. There are no feasible workarounds and there is no solution either. I think this issue must be escalated and become top priority for Auth0 engineering team. So far it looks like a clear regression on Auth0 side and the more we wait, the more chances for us would be to use and recommend rival Authentication-as-a-Service products for our new projects.

1 Like
#17

In development environment, removing the cookies from browser works.
For production grade we moved to API based login and dumped the hosted pages. We implemented the native pages in mobile app and leveraged over the APIs to do the authentication.

Auth0 Engineering team is taking quite some time to revert on this.

2 Likes
#18

Many thanks, @akmishra ! Will try your cookie workaround on my end & assess a custom plugin to the native libs.

#19

Are there any updates to this? We are now several days on from this being reported with no updates of note…

2 Likes
#20

Hi @konrad.sopala,

Do you have any updates please. The cookie fix mentioned by @LordParsley does not work for us and implementing a custom login screen via the use of the login APIs is not a recommended best practice if we want to leverage all the security benefits that have been provided by hosting the login page with the Auth0 tenant. Please can you provide an update.

Many Thanks for your help.

2 Likes
#21

@anjam.tahir I agree with you.

  • On iOS, one cannot clear the cookie data of the SafariViewController because it is outside the app sandbox.
  • Implementing a native wrapper isn’t ideal & I’m fairly sure Auth0 advises against it because the JS interface is vulnerable (?) whereas a hosted page is sandboxed. (In any case, I don’t think we have the time.)
  • I’ve tried revoking application access & device access on a user. The only thing that seems to work is deleting the user in the Auth0 dashboard.
  • Unless I’m missing something, I can’t do a logout call using http?

Thanks again.

#22

Hi everyone. The engineering team has found the issue that is causing this behavior, and they are currently working on a fix. Thanks to everyone who took the time to report this and provide all this valuable information.

1 Like
#23

Thank you very much @nicolas_sabena ! Have just tested & confirmed behaviour is back to normal: hosted login page respects the prompt: login parameter again :slight_smile:

1 Like
#24

Hi @nicolas_sabena,

Thanks for the update - Unfortunately the prompt=login parameter issue with the hosted page is still not working for us. Please confirm once the fix has been rolled out to all.

Many Thanks

1 Like