Wildcards in callback URLs

Help
,
1

Hi, I would like to embed the Universal Login into a WordPress plugin. Login and redirect is working on my machine, but I have a problem with callback URL configuration.

Given that the plugin is going to be installed on machine WordPress instances running on different domains, I would like to configure the callback URL with a wildcard n order to make it work with any domain the plugin will be installed on.

Is it possible?

Thank you in advance.

2

You can use wildcards with some restrictions, albeit it is not recommended:

You can use the star symbol (*) as a wildcard for subdomains, but it must be used in accordance with the following rules in order to properly function:

  • The protocol of the URL must be http: or https:. com.example.app://*.example.com will not work.
  • The wildcard must be located in a subdomain within the hostname component. https://*.com will not work.
  • The wildcard must be located in the subdomain furthest from the root domain. https://sub.*.example.com will not work.
  • The URL must not contain more than one wildcard. https://*.*.example.com will not work.
  • A wildcard may be prefixed and/or suffixed with additional valid hostname characters. https://prefix-*-suffix.example.com will work.
  • A URL with a valid wildcard will not match a URL more than one subdomain level in place of the wildcard. https://*.example.com will not work with https://sub1.sub2.example.com.
1 Like
3

Thanks for your answer.

So, it seems to me that using a wildcard to match any domain (i.e. http://*/wp-admin.php to redirect to a WordPress admin page installed on whatever domain) is not possible.

At this point, how can I solve my problem?
An idea could be to redirect to a service deployed in my network, whose only duty is to redirect in turn to the WordPress instance. Could it be acceptable, from a security perspective?

4

Do you know the list of domains that will be using your auth0 as the identity service? If you do, i would recommend building that list into your callbacks. If not, how do you know where to route requests to?

5

No, I don’t, because anyone could download and install the plugin on its own WordPress instance.
I was thinking to put the desired WordPress callback URL in the “state” query param of the login call in order to allow an additional service to bridge redirection from the callback configured in the Auth0 application to the actual WordPress URL.
I was wondering if there could be a security implication, tough.

6

What grant type are you using? If this is authorization code grant, the wordpress instance would have to know the client secret, so you would probably have to know about them anyway. If PKCE or implicit, you could end up in a situation that anyone could have it redirect to their own malicious site and get tokens for the user.

I think if I were designing something like this, I would want to know who I am building the identity solution for. So they would have to register their domain with me so I can add them to the callback list.

7

I’m using Authorization Code Flow with PKCE: since I want to develop a plugin inside whom the customers can authenticate with my API, I though this was the best approach.
Client ID and secret are hardcoded inside the plugin, thus making them public, and every user must login to my API inside the plugin in order to generate a token.
Is this the correct approach?