We have a React App for our frontend and are using ASP.Net Core Web API. We can successfully sign users in and out of the application. If we implement CORS in our API everything works as expected; the frontend app consumes the API resources successfully. But when we try to protect the API using Okta in our Staging environment it fails and returns a 500 server error. It works successfully in localhost. We are passing the Bearer token in the API call headers. We’ve followed the quick start guides for creating a React App with Okta and the Protect Your API Endpoints with Okta, but we are obviously missing something (something important), but I do not know what it is. Anyone else have this issue and was able to resolve it? Or does someone know what I may be missing in my setup?
We are using the Authorization Code flow and the default Authorization server. We do not have a paid account; only using the free account.
louie,
Thanks for replying. I believe the error is being generated by the application, but only after Okta Auth has been implemented on my API for endpoint protection.
This is the error message I see in Dev Tools:
“Access to XMLHttpRequest at <> from origin <> has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: It does not have HTTP ok status.”
The request shows all the correct information, including the passed in Authorization header and the Bearer token. The Request URL is correct, the Method: OPTIONS and the below:
Response Headers:
access-control-allow-methods: PUT, GET, HEAD, POST, DELETE, OPTIONS
access-control-allow-origin: *
Content-Length: 2375
Content-Type: text/html
Date: Wed, 31 Aug 2022 17:24:36 GMT
Server: Microsoft-IIS/10.0
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
X-Powered-By: ASP.NET
This gets a 500 Internal Server Error response during the preflight and a “CORS Error” from the xhr. However, if I strip out the Okta Auth from the API and the Access Token from the requests, it does not throw any CORS errors and I am able to consume the resources successfully without changing the current CORS configurations.
I am fairly certain (almost 90%) that it is failing in the preflight, but I don’t know why, nor why it fails only with Okta auth implemented.
Louie,
I was able to resolve the CORS preflight issue, and it is returning 204 No Content now (as expected). The 500 Internal Server Error still persists. I was able to get some info from the server logs that points to this being an Okta configuration issue. However, I am not sure what is missing. What can I check in my Okta app setup to narrow down what I may be missing?
Error I am getting:
System.InvalidOperationException: IDX20803: Unable to obtain configuration from: ‘https://{myoktadomain}/oauth2/default/.well-known/openid-configuration’.
—> System.IO.IOException: IDX20804: Unable to retrieve document from: ‘https://{myoktadomain}/oauth2/default/.well-known/openid-configuration’.
—> System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it. ({myoktadomain}:443)
—> System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it.
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
at System.Net.Sockets.Socket.g__WaitForConnectWithCancellation|283_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.DefaultConnectAsync(SocketsHttpConnectionContext context, CancellationToken cancellationToken)
at System.Net.Http.ConnectHelper.ConnectAsync(Func3 callback, DnsEndPoint endPoint, HttpRequestMessage requestMessage, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.Http.ConnectHelper.ConnectAsync(Func3 callback, DnsEndPoint endPoint, HttpRequestMessage requestMessage, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at System.Net.Http.DiagnosticsHandler.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
at Okta.AspNet.Abstractions.OktaHttpMessageHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
at System.Net.Http.HttpClient.SendAsyncCore(HttpRequestMessage request, HttpCompletionOption completionOption, Boolean async, Boolean emitTelemetryStartStop, CancellationToken cancellationToken)
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
— End of inner exception stack trace —
at Microsoft.IdentityModel.Protocols.HttpDocumentRetriever.GetDocumentAsync(String address, CancellationToken cancel)
at Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectConfigurationRetriever.GetAsync(String address, IDocumentRetriever retriever, CancellationToken cancel)
at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel) --- End of inner exception stack trace --- at Microsoft.IdentityModel.Protocols.ConfigurationManager1.GetConfigurationAsync(CancellationToken cancel)
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
at Microsoft.AspNetCore.Authentication.JwtBearer.JwtBearerHandler.HandleAuthenticateAsync()
at Microsoft.AspNetCore.Authentication.AuthenticationHandler1.AuthenticateAsync() at Microsoft.AspNetCore.Authentication.AuthenticationService.AuthenticateAsync(HttpContext context, String scheme) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT1.ProcessRequestAsync()
We finally got this resolved. After working with the Okta Support Team, it was determined that our configuration was correct and that it was likely a network issue. We met with our third-party data center’s network team and they figured out that the validation request from the Okta SDK was not getting out thru the proxy. They made some updates to the proxy and we are now able to consume the resources as expected.