We are building an SaaS app, let’s call it http://mysaasapp.com. When users sign up, they access their instance using a subdomain name http://myinstance.mysaasapp.com or a custom domain name http://instance.mycompany.com and so on.
We are looking at integrating with other services (Facebook, twitter, etc) so that our users can link to accounts on those services within their instance. Twitter is very lenient when it comes to OAuth redirect callbacks (the callback/redirect URL can be set by us when we make the OAuth request). Facebook, however, is not so leninent, the callback/redirect domain is set within the App’s configuration on facebook.com
When users use a custom domain name on their instance, they can opt to make the subdomain (http://myinstance.mysaasapp.com) on our site inactive. This means we can’t set the callback domain for OAuth to be mysaasapp.com and expect it to work.
The solution would be to use an OAuth proxy (http://proxy.mysaasapp.com). We have used HybridAuth previously, and we believe we should be able to easily turn it into a OAuth proxy.
Having said that:
-
Should we use the OAuth proxy to only proxy Auth requests? Once we get the access tokens, should we continue proxying the request through the proxy or should we just connect to the provider directly from our instance? In other words, are there any OAuth secured APIs that restrict API calls (after authentication) to certain defined domains?
-
How should I secure the OAuth proxy so that requests can only originate from instances of our app and responses can only go to instances of our app?
So here’s what I ended up doing.
I created a very simple web app which is built around HybridAuth. This webapp would be hosted at oauth.mydomain.com.
What happens is that when the user at his own instance wants to connect to a provider such as Facebook, the app instance does a server to server connection to oauth.mydomain.com by posting the provider type and a few other information. The proxy returns a token.
We then redirect the user to oauth.mydomain.com while passing the token as a get parameter. oauth.mydomain.com invalidates the token and stores the information in the user’s session.
The user then proceeds to authenticate with the provider. When this is successful, oauth.mydomain.com POSTs the consumer tokens and keys back to the instance at a special endpoint.
When posting is complete, we redirect them back to the page they were on at theirdomain.com
I have decided not to proxy all requests (only auth requests are proxied) because this is a simple method and providers (at least the ones I have looked at) only implemented domain restrictions during the auth process.