Add support for CORS

[joshuarubin]

Mirroring some of the comments I made at ory/fosite#179

It would be very helpful if hydra had configurable support for responding with CORS headers and handling CORS preflight (OPTIONS) requests.

[aeneasr]

In general I recommend running Hydra behind an API Gateway such as Kong - while Hydra is capable of dealing with public internet traffic, it's always better to have a battle tested entry point to your infrastructure.

Having said that, it is quite common to have a CORS plugin in your API Gateway and configure CORS for your whole domain rather than per service.

Configuring CORS is a bit painful, because there are various configuration options (methods, hosts, ...) and limitations (e.g. only one host or wildcard) that make this even harder.

Therefore, if having a reverse proxy, or an API Gateway that is capable of dealing with CORS is the best route to resolve here IMO. Let me know if that works for you.

[joshuarubin]

We could certainly put a reverse proxy like nginx in front of hydra (or use a full blown API gateway like Kong, as you suggest, or aws api gateway) but that is still a much more complicated setup. We are deliberately running hydra outside of our main (in our case kubernetes) clusters so that such a critical component to each of our clusters (we have many clusters, but share the auth system) isn't dependent on any one of our clusters.

Right now, we are simply using aws ec2 container service to host hydra. While it is absolutely possible to put something in front of it, it would be a whole lot easier to just reconfigure hydra.

I definitely understand your perspective though and understand if that's not something you feel belongs in hydra directly.

That said, as I've mentioned, here and in #507, we would also love to see more ways that hydra could natively support a decentralized architecture (while understanding that the DB is the biggest factor in this). CORS support would help with that to some degree.

[aeneasr]

Unfortunately CORS will not be added to hydra, there are much more elegant ways to solve that with a decent API Gateway, varnish, ngnix, or any other type of reverse proxy. You could even write one yourself within an hour in Go. It is extremely common to have this in place in a distributed or cloud environment.

I also want to direct you to running hydra in production where it is specifically recommended to not let hydra face public internet traffic.

[aeneasr]

Not sure why I reopened this - closing as this is usually covered by the reverse proxy

[aeneasr]

I changed my mind, CORS support will make it into the 0.10.x release as there is the possibility to configure rs/cors in a sane way through env vars

[grega]

@arekkas We discussed this briefly a while back, glad to see it has made it in! Our particular case was AWS API Gateway requiring the Access-Control-Allow-Origin to be set by the application (since it cannot be configured by the Gateway for proxy set-ups):

With Lambda, AWS or HTTP integrations, you can leverage API Gateway to set up the required headers using the method response and integration response. For Lambda or HTTP proxy integrations, you can still set up the required OPTIONS response headers in API Gateway. However, you must rely on the back end to return the Access-Control-Allow-Origin headers because the integration response is disabled for the proxy integration.

(http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html)