Origin header required (Lock 11)

Help
1

  • What are you trying to achieve? What is the use case or idea behind it?
    Some of our users cannot log anymore since we deployed Lock11. We used the auth0 migration documentation (from Lock 10) and we a pretty confident it’s ok.
    Allowed Web Origins are set up correctly since most of our users are ok.

  • If this is caused by an SDK please mention the SDK along with the specific version number.
    angular 5.2.0
    auth0-lock 11.3.1

  • Is this easily reproducible? If not, please explain.
    Some users have the error but most don’t.
    Type: Failed cross origin authentication
    Description: Origin header required

  • Environment-specific information (Which OS, Language Runtime + Version, Browser etc).
    IE11 Win7

2

I’ve seen some specific IE 11 configurations not sending the Origin header due to the fact that both sites (the one being called and the caller) being part of the same highly-trusted security zone. This is mentioned at (xmlhttprequest - Internet Explorer 11 does not add the Origin header on a CORS request? - Stack Overflow) so depending on how the users configured IE11 it could explain the situation. The bad news is that this can be controllable by end-users and in most situations you can’t influence this configuration which ultimately leads to the behavior you’re seeing where the feature in question (cross-origin authentication) is not supported because it has no way to assert the two origins in play for the authentication request (only knows the origin being called, not the origin from which the call is being made).

3

Thank you,

As you said this is not controlled by ourselves so it’s still a problem.
Do you think it will help if we activate custom domain ? I saw this post ("Unable to configure verification page" error on hosted login - #19 by jaliperti1) and if activating custom domain get rid of the cross domain call it could work with IE11.

4

To be honest I’m not sure, but the custom domain would at most give you the same top-level domain (TLD) in both origins, but it would still be cross-origin authentication (from app.example.com to identity.example.com) and identity.example.com would still not know that the call is being made from app.example.com as IE would not send the Origin header.

In conclusion, custom domains would resolve issues with third-party cookies as browsers would not consider the same TLD as a third-party, however, you would still need to perform a call across origins and the server would still reject it if it does not receive a suitable header.

5

We are running into the same problem as mbraunap. I managed to reproduce the issue locally by setting the ‘Access data sources across domains’ to enable (see attachment). This will, if both domains are in the same security level, force IE to not send a ‘Origin’ header.

Is there any way we can resolve this problem without the client adjusting anything? Our users work at big institutions so they generally can’t alter their own Internet Explorer settings. I looked into the option to allow no-origin header to be present but it doesn’t look like Auth0 supports this (for good reasons I think).

The only solution I can see so far is to stop using lock and move the integration with Auth0 to our backend.

1 Like
6

Now with attachment.

09
092202×1070 235 KB

7

At this time, I’m not aware of any resolution for this that does not require changing IE settings. In order to verify that a call comes from a white-listed origin the server requires that header so like you mentioned the only alternatives I’m aware of in cases where IE settings can’t be controlled would be to use a different approach for authentication (for example, the universal login: Auth0 Universal Login).

8

We were having this same issue and spent time earlier this week trapping the error condition in IE 11 so we could explain the issue to our users. As of this morning we can no longer reproduce the error.

Yesterday, a POST to /co/authenticate from IE 11 without the Origin header would return the 400 Bad Request mentioned above. Today, that same request, still without the Origin header, is returning a 200 OK just fine.

I assume that Auth0 has made a change on your end. I couldn’t find the change documented anywhere. Can I assume that this change will remain in place?

We run a self-hosted login screen for a variety of reasons, and were hoping to avoid transitioning to the Auth0-hosted login screen because of this issue. If Auth0 is fine with accepting this request from IE 11 without the Origin header, that would be great. It will take a bunch of work off of our plate.

Any update or confirmation you could provide would be great. Thanks!

9

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?