I am getting the following error in console when trying to login in my application - "Access to XMLHttpRequest at ‘https://<>.okta.com/oauth2/default/.well-known/openid-configuration’ from origin ‘<>’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource."
I have added application endpoint to the trusted origin and also checked the CORS and Redirect options.
Please help me out on this…
Background of the Issue -
The application works perfectly when configured okta application in my own developer account. But when i configure the application with my organisation Okta account it performs multi-factor authentication.
Firstly it shows cors issue with /authn endpoint while logging in login page but after configuration of application in trusted origin, app now proceed to google authenticator and after entering the code it gives the above cors issue reported.
Hi @ratul
Does this consistently occur for you or is it intermittent? If it occurs consistently could you open a support ticket with details on how to reproduce this, along with a network trace of an example failure?
Thanks for the reply dzeller.
It is consistent and is observed in different multi-factor authenticator(in my case google authenticator). I will be opening a support ticket for this.
Is there any place else where we need to configure the application endpoint in my org okta account.
In case this helps anyone with the same issue, I hit this exact issue using the widget for login and MFA. turned out I needed to explicitly set the issuer in the authParams
For anyone who finds this thread later, it sounds like, based on the responses from @ratul and @bbaniewicz about how they resolved it, that the Okta tenant being used did not have the required SKU to use the “Default” custom authorization server. If you do not have this SKU, you will see a CORS error when the application attempts to make a request to the well-known endpoint, as this endpoint does not exist for Orgs that do not have access to the Default Authorization Server.
If you find you are unable to use a custom authorization server (such as the one called ‘Default’) you can try using the “Org” Authorization Server that does not require an additional SKU by setting the issuer to your baseUrl, https://org.okta.com, instead of the default server, https://org.okta.com/oauth2/default.
Details about when you need a Custom Authorization Server can be found here.
If you do need to use a custom authorization server for your use case, you will want to reach out to your Account Manager for pricing information/estimate, as there is an additional license for this feature.
I don’t think we are using custom auth. The issue had to do with enabling MFA. Without MFA we did not need to add the authParam issuer, whatever was default was OK. Once we enabled MFA, we got the CORS error unless we specifically set the issuer to our oktaBaseUrl
hmmm… those two shouldn’t be related to one another. Can you create a new post we can discuss this in or open a support case for further investigation?
I can, but I think it’s what the original poster described. He said everything was fine in development, but when they moved to production, which uses MFA, they hit the same issue I did.
Do you know if your Production Org has access to the default auth server? You can usually check by navigating to the metadata endpoint: https://subdomain.okta.com/oauth2/default/.well-known/openid-configuration. If you have the feature, you will see a JSON response from this endpoint, otherwise you will see an error saying "You do not have permission to access the feature you are requesting"
The reason I ask is because you mentioned it worked in development, which I’m guessing refers to you testing in two different Orgs, is that right? Was the org you tested in during development a Developer Org?
Developer Orgs have this API Access Management SKU enabled for them, granting them the ability to use/create custom authorization servers, but the same cannot be said for all paid Orgs and will be dependent on your license. If you see different behaviour between two Okta tenants, it is a good idea to check if they both have similar features enabled, and for OIDC, the API Access Management SKU is one to check for.