Facebook login without Valid OAuth redirect URIs

Question

This is not about wildcard domains. It's about the need to add completely different domains to Valid OAuth redirect URIs on Facebook Login.

We have a web app where our clientes can setup their own custom domain (example.com, xyz.net, etc). We don't know what domains will be used.

On Facebook we have a single app that takes care of the Facebook login. It seems that we need to whitelist specifically every domain that uses the FB Login.

Adding the domains manually is not an option. What options do we have?

Thanks.

Answer 1

The simplest solution that I can think of is to use an intermediate identity service with a very lax redirect uri validation. There is a good discussion of this approach and some of the security concerns with it in relation to IdentityServer4.

I have used custom redirect uri validation for an identity service before but only for very restrictive cases as this is one of most exploited vulnerabilities in an OAuth flow. The flexibility that you would need would weaken security considerably.

To implement it in IdentityServer4 you would set up Facebook authentication on the identity server and register the identity server's address with Facebook. You would then create clients to represent your new domains. This could be a single client for everything (making things more insecure still) or you could add a way for your clients to register themselves with the identity server (for instance dynamic client registration).

When a client wants to connect to Facebook they will use Open Id Connect to connect to the identity server which will then communicate with Facebook. In IdentityServer4 the client would add middleware for this with UseOpenIdConnectAuthentication (see here for an example).

Long story should you can resolve your issue by using an intermediate identity service. The identity service will be the only url that needs to be registered to Facebook and your clients will register with your identity service which you will have control over.

With great power comes great responsibility though. Taking the path of least effort will lead to a solution that lowers security considerably. Enforcing a secure dynamic registration with the identity service such as dynamic client registration protocol will allow you to use a single strict redirect uri per client and make your system about as secure as you can reasonably get it.