[Cleanup] CORS Settings

[someone1]

I've been trying to tackle getting Hydra (v1.0.0-beta.9) up and running properly and have a couple thoughts:

1. CORS_ENABLED enables CORS on both the backend handler as well as the Client ID OAuth2 endpoints - should these be tied together? In other words, if I want CORS to work for my Clients but don't need it for the backend, why am I tied to both from a single setting?
2. No way to set CORS settings for the /.well-known/ paths currently - what if my SPA needs to read this before trying to initiate a PKCE Auth Code flow as is the case with the AppAuth-JS library?

[someone1]

Another potential bug here, even with CORS enabled, am I able to exchange an authorization_code for a token? If I whitelisted URI's on my client for CORS, the way the CORS middleware is currently written, unless I use Basic AUTH on my request, it will expect an Access Token on the request which is what I'm trying to get with the request.

Am I reading this right? The other alternative is to whitelist CORS with the CORS_ALLOWED_ORIGINS option but that is more of a global setting than a per-client setting, the latter being desired.

[aeneasr]

CORS_ENABLED enables CORS on both the backend handler as well as the Client ID OAuth2 endpoints - should these be tied together? In other words, if I want CORS to work for my Clients but don't need it for the backend, why am I tied to both from a single setting?

Yeah you're right, this is kind of akward. The idea is that hydra serve all is like a catch-call serve process wrt config. If you need more granular control you can use hydra serve admin and hydra serve public where you can set up the configs individually. But you're generally right that admin and public ports usually have different CORS settings. I'm not sure if splitting env vars is worth it though, as you can set up the processes individually.

No way to set CORS settings for the /.well-known/ paths currently - what if my SPA needs to read this before trying to initiate a PKCE Auth Code flow as is the case with the AppAuth-JS library?

Oh really? That's definitively a bug!

Another potential bug here, even with CORS enabled, am I able to exchange an authorization_code for a token? If I whitelisted URI's on my client for CORS, the way the CORS middleware is currently written, unless I use Basic AUTH on my request, it will expect an Access Token on the request which is what I'm trying to get with the request.

Indeed, there a two ways the token endpoint can be used (or rather three ways the token endpoint allows authorization):

• Using HTTP Basic Authorization.
• Transmitting client_id in POST body (when using public clients). This will not work at the moment!

Bearer tokens can be used when revoking access tokens, which is why this is enabled here.

[someone1]

#1116 and #1118 may have addressed some concerns here - I'll review and close this if necessary.

[aeneasr]

Yes, this can be closed now!