Missing Access-Control-Allow-Origin response header

If an https://auth0.eu.ngrok.io/auth/callback is set as an Allowed Callback URL, then should responses to preflight requests to /authorize not include the Allowed Callback URL as an Access-Control-Allow-Origin header?

It seems that this missing header causes browsers to reject processing the response, because it violates CORS.

Here is an example of a preflight request to /authorize where I was expecting auth0 to populate Access-Control-Allow-Origin response header with the value of the Origin request header:

curl -v -X OPTIONS \
  'https://auth.custom-domain.com?client_id=uashgdi7y283hkhdfkh8iajseYIUAHS&redirect_uri=https://auth0.eu.ngrok.io/auth/callback&scope=openid&prompt=none&response_type=token%20id_token' \
  -H 'Content-Type: application/json' \
  -H 'Origin: https://auth0.eu.ngrok.io'
* Rebuilt URL to: https://auth.custom-domain.com/?client_id=uashgdi7y283hkhdfkh8iajseYIUAHS&redirect_uri=https://auth0.eu.ngrok.io/auth/callback&scope=openid&prompt=none&response_type=token%20id_token
*   Trying
* Connected to auth.custom-domain.com ( port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=auth.custom-domain.com
*  start date: Oct 12 15:40:58 2018 GMT
*  expire date: Jan 10 15:40:58 2019 GMT
*  subjectAltName: host "auth.custom-domain.com" matched cert's "auth.custom-domain.com"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
> OPTIONS /?client_id=uashgdi7y283hkhdfkh8iajseYIUAHS&redirect_uri=https://auth0.eu.ngrok.io/auth/callback&scope=openid&prompt=none&response_type=token%20id_token HTTP/1.1
> Host: auth.custom-domain.com
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/json
> Origin: https://auth0.eu.ngrok.io
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sun, 14 Oct 2018 19:44:24 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 2
< Connection: keep-alive
< X-Auth0-RequestId: 4fa40bb96d9e72395994
< Access-Control-Max-Age: 1000
< Access-Control-Allow-Methods: GET, PUT, POST, DELETE, PATCH, OPTIONS
< Access-Control-Allow-Headers: Origin, Content-Type, Accept, X-Requested-With, Authorization, Auth0-Client, X-Request-Language
< Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< X-Robots-Tag: noindex, nofollow, nosnippet, noarchive
< Strict-Transport-Security: max-age=15768000
* Connection #0 to host auth.custom-domain.com left intact

Did you solve this? I’m calling /authorize with connection set, but browser fails to redirect on 302 found due to missing Access-Control-Allow-Origin header.

1 Like

Any update on this? Experiencing the same problem with users using Edge as a browser. Edge is throwing a CORS error on the callback after loading the authorize endpoint. Chrome seems to be fine.