Anomaly Detected on hosted login page

General
, ,
#1

I’m trying to log in my users with the hosted login page. Eventually I want to use a custom one, but I’m having problems and have fallen back to the default.

When I enter a username and password, I get a “Sorry, something went wrong” message, and the HTTP response is this:

{“statusCode”:403,“description”:“Invalid state”,“name”:“AnomalyDetected”,“code”:“access_denied”}

The user I’m logging in as is not blocked, and I’ve even tried turning off anomaly detection completely to no avail. I think there must be a configuration problem somewhere, but I’m not sure what it could be. Any ideas?

#2

Social login with Twitter or Linkedin works fine…

#3

I’ve created a new client under a new tenant, and I don’t get the error, so I’ve obviously got something misconfigured somewhere. I’ll compare to see what’s gone wrong and report back for future searches :slight_smile:

#4

We are experiencing the exact same problem. We created a new tenant and a new client in order to separate our Dev/Test/Production environments.
Configuration steps:
Client Type : Regular Web Application
Token Endpoint : Post
Allowed Callback URLs: http://localhost:8080/mycallback

We used the default hosted page template. When you sign-up a new user , the user appears under users on the Auth0 portal , there are no errors under logs but Lock displays a “WE’RE SORRY, SOMETHING WENT WRONG WHEN ATTEMPTING TO LOG IN.”
We also noticed that in the webrequest https://mydomain.auth0.com/usernamepassword/login the response comes back as :
{“statusCode”:403,“description”:“Invalid state”,“name”:“AnomalyDetected”,“code”:“access_denied”}

I must add that hosted pages works in our old dev tenant which was created sometime in 2017 when Lock was still in version 10.2.2 .,We are experiencing the exact same problem. We created a new tenant and a new client in order to separate our Dev/Test/Production environments.
Configuration steps:
Client Type : Regular Web Application
Token Endpoint : Post
Allowed Callback URLs: http://localhost:8080/mycallback

We used the default hosted page template. When you sign-up a new user , the user appears under users on the Auth0 portal , there are no errors under logs but Lock displays a “WE’RE SORRY, SOMETHING WENT WRONG WHEN ATTEMPTING TO LOG IN.”
We also noticed that in the webrequest https://mydomain.auth0.com/usernamepassword/login the response comes back as :
{“statusCode”:403,“description”:“Invalid state”,“name”:“AnomalyDetected”,“code”:“access_denied”}

I must add that hosted pages works in our old dev tenant which was created before sometime in 2017 when Lock was still in version 10.2.2 .

#5

Bumping this up. A response from Auth0 would be appreciated as this is obviously not an isolated case.

#6

Same problem here!!!

#7

To call the Hosted Login Page with Auth0.js your code should look something like:

var webAuth = new auth0.WebAuth({
  domain: {YOUR_AUTH0_DOMAIN}, 
  clientID: {CLIENT_ID},
  audience: {API_AUDIENCE},
  redirectUri: {CALLBACK_URL}, 
  scope: 'openid profile',
  responseType: 'token id_token'
});
webAuth.authorize();

If this does not solve it, do you have anomaly detection enabled? Could you share the code from your authentication request and from the hosted login page?

#8

So my problem was that I was sending people straight to the hosted login page at {tenant}.auth0.com/login?client=xxx rather than using a proper authorise flow which goes somewhere else first to set a few state flags. The documentation had fooled me into thinking that was valid, but it’s not. Make sure you’re calling authorize somewhere, not just doing a GET to /login.

#9

Added what was going wrong in my case as an answer below.

#10

How are your users getting to the hosted login page? I was trying to do a GET straight to the /login page, which wasn’t correct.

#11

So my problem was that I was sending people straight to the hosted login page at {tenant}.auth0.com/login?client=xxx rather than using a proper authorise flow which goes somewhere else first to set a few state flags. The documentation had fooled me into thinking that was valid, but it’s not. Make sure you’re calling authorize somewhere, not just doing a GET to /login.

#12

Same here!

#13

So we have the same problem , we have tried to work around /authorize sending the wrong state to /login when user press the back button , so we directed users to /login directly and we started to get this Anomaly issue.
we are not using any JS library ourselves - only redirect to auth0 hosted pages.
has anyone else have the same problem with the state being passed between /authorize and /login when user hit the back button. ?
is there a solution to satisfy the other problem we have but not get the Anomaly issue ?

thanks
Shlomi

#14

Hey there!

Sorry for such huge delay in response! We’re doing our best in providing you with best developer support experience out there, but sometimes our bandwidth is not enough comparing to the number of incoming questions.

Wanted to reach out to know if you still require further assistance?

#15