Auth0-spa-ja: validation of "Allowed web origins" does not support wildcards for silent authentication

Help
1

I am upgrading from auth0.js to auth0-spa-js v1.2.3.

My app was working fine on localhost, but then after deployment; the first authentication would succeed, but any subsequent refresh or opening of a new tab it would exhibit the “pause for 1 minute, then fail to login” behavior similar to this thread:
http://community.auth0.com/t/authentication-breaks-when-client-refreshes-browser

I was able to workaround the problem by clearing the “auth0.is.authenticated” cookie.
I’m assuming this is related to “silent authentication”, because of this: Question: what is the use of 'auth0.is.authenticated' cookie · Issue #95 · auth0/auth0-spa-js · GitHub

One thing I noted was the the Auth0 side logs showed “Failed Silent Auth: The specified redirect_uri ‘https://app.example.com’ does not have a registered origin”.
Yet I had “https://*.example.com” in the “Allowed web origins” field, not to mention the first login (with no cookie present) works fine.

So I added “https://app.example.com” to the “Allowed web origins” field and the app started working properly.

I think Auth0 needs to unify the validation logic between initial login and silent auth. This problem was made much harder to diagnose because the initial login worked and only silent-auth fails. Either wildcards should be allowed for both calls, or neither.

Personally, I’d prefer you allowed wildcards. If the reasoning for not allowing wildcards is “because security”, then doesn’t that imply the initial login logic has a security hole in it, since it allows the login via a wildcard?

If you decide that wildcard origins are not supported, please add that to the FAQ - since it seems to work fine with the auth0.js library that my app currently uses (including silent authentication). Some folks will need to know about this when porting - it might save them a lot of wasted effort if they need wildcards.

You probably should think about better error handling and feedback with auth0-spa-js client too. The observed behavior (pause for one minute when creating the auth0 client object, then silent return) is not terribly helpful, though I can see how it might be hard to provide good feedback without security repercussions.

5 Likes
2

In re-reading this post - it sounds kind of negative.
So I thought I should add I think you’ve done a great job with the new library - it makes my app more light-weight and I get to remove a bunch of code that is now being taken card of by Auth0.

1 Like
3

This needs to be upvoted. I had the problem of Failed Silent Auth in the logs but the browser console showed a 400 error of unregistered web origin uri. Even though the callbacks and origin urls were correctly registered.

The only thing that pointed to this was the fact that auth0.is.authenticated cookie was set (even though I wasn’t logged in).

4

@jmangelo @konrad.sopala Guys, could you please take a look on this. This post is quite old now and I’m keep watching it and waiting for response as I had same issue. Could you please advice how to handle silent auth with wildcards subdomains with auth0-spa-js

5

Hey there!

I think you may also want to read this:

6

+1 to the suggestion to figure out a way to improve the developer experience here… even if it’s just a document listing all the scenarios you need to test to ensure that you’re properly configured.

I’ve replied to the wildcard thread, but I also made it almost all the way to production without realizing this was a fundamental limitation, and now we’re pretty much screwed trying to figure out if we need to replace our entire auth infrastructure because of the no-wildcard limitation :frowning:

1 Like
7

Just hit this same issue and wasted a bunch of time on figuring it out :frowning: