I am using the Passport.js library (specifically the passport-saml Strategy) to enable Single Sign-On for my company’s app through Okta.
The desired use case is that a user navigates to the apps landing page (locally hosted), then authenticate is checked through Passport calls to Okta. If the user is not logged into Okta, the browser will redirect them to Okta to login in. After logging in, they’ll be redirected back to my app.
CORS is enabled for all of these requests, and I believe I’ve uncovered a possible bug with CORS headers not being sent back from Okta. For reference, I have followed the steps in this tutorial to ensure that my app’s origin is registered with Okta to grant cross-origin access: Enable CORS | Okta Developer
During the preflight CORS check, the browser sends the OPTIONS request to Okta. Missing from the response is the Access-Control-Allow-Origin header. For this reason, my browser rejects the cross-origin request with the message “Access to fetch ‘’ (redirected from ‘’) has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.”
The URI found at above originates from the same domain that I registered in my Trusted Origins section in Okta.
It seems that the Okta response to the OPTIONS route needs to include a Access-Control-Allow-Origin header with the origins that were registered in Trusted Origins, but it does not.
Please let me know how I can further describe my issue, if need be. Thank you!
The request that the browser is sending as part of the CORS preflight checks looks like this, with sensitive data omitted (recall it is a SAML request):
I get a 200 response back from this call, with Response Headers that do not include any CORS response headers. I expect the endpoint to send back at least Access-Control-Allow-Origin , since I have configured the client as a Trusted Origin in my Okta instance.
Have a quick update on this (though it is not a happy one).
I have made my HTTP request to that Okta SAML resource simpler, so that it qualifies as a ‘simple CORS request’ and does not do any pre-flight checks. The problem I am having persists even with the GET method instead of the OPTIONS method. So it is not verb specific, it appears to be an issue with the SAML URL resource.
The /app/ endpoints are not CORS enabled in Okta as they return custom HTML code which sends the authentication credentials (SAMLResponse in this case). The best solution in this case would be to redirect the users to Okta and then Okta will redirect the users back to your ACS endpoint.
Thanks for your response, that was exactly the information I needed. We ended up doing exactly what you suggested, redirecting the page to the SAML endpoint rather than making an HTTP request to it, and that is now all working properly. Thanks again!!