Okta Identity Engine CORS Errors: Understanding “Failed to fetch”

During an authorized authentication-flow assessment, a sign-in page loaded, but submitting the form produced Failed to fetch. DevTools also reported a CORS error associated with a request to Okta’s /idp/idx/identify endpoint.

The available details included Content-Type: application/json, an Okta client header, and a no-referrer policy. They help explain the browser’s behavior, but they do not establish the exact cause.

A CORS error does not, by itself, prove that the main request never reached the server. The distinction between a failed preflight and a blocked response changes what we can conclude.

The domains below are fictional. No tenant identifiers or authentication payloads are included.

Start with the initiating origin

Consider a page at https://portal.example making an authentication request to https://identity.example.

These are different origins. An origin consists of the scheme, hostname, and effective port; the URL path is not part of that comparison. Two services can belong to the same organization while remaining separate origins in the browser.

The relevant origin belongs to the document that initiates the request. If an iframe is involved, the main address bar may not tell the whole story.

CORS determines whether a browser can expose a cross-origin response to the requesting JavaScript. See MDN’s CORS overview.

“Failed to fetch” is a symptom

Failed to fetch tells the application that the operation failed. It does not identify the underlying cause.

The full console message is more useful than a generic Network label. It may identify an origin mismatch, a request header that was not permitted, or a failed preflight. JavaScript does not receive all the details that the browser can show in its console. MDN’s CORS error reference explains that distinction.

Network and TLS failures can also prevent a CORS exchange from completing. In those cases, the error does not establish an explicit policy rejection by the server. MDN documents this separately under “CORS request did not succeed”.

Preflight failure and response blocking are different

Some cross-origin requests require a preliminary permission check called a preflight. The browser sends an OPTIONS request describing the intended method and relevant headers.

A cross-origin Fetch or XMLHttpRequest operation using Content-Type: application/json normally requires this check. A custom request header can independently trigger the same requirement. These conditions are described in MDN’s CORS error guide.

An illustrative excerpt from the intended main request looks like this:

Origin: https://portal.example
Content-Type: application/json
X-Example-Client: documentation

These lines describe request metadata. They are not a complete request or an authentication payload.

Failure stage	Browser behavior	What the error establishes
Preflight fails	The corresponding main request is not sent.	That main request did not proceed through this attempt.
CORS validation of the main response fails	The main request may have reached the server, but JavaScript cannot read its response.	The browser error does not prove that the server performed no action.

This distinction follows the CORS request and response model. A Network entry alone is not proof that the main request was transmitted.

Successful preflight permissions can also be cached. An attempt may therefore show no new OPTIONS request even when preflight requirements apply. See MDN’s preflight reference.

“no-referrer” does not explain the failure by itself

A policy of no-referrer tells the browser to omit information normally carried by the Referer header.

For the CORS request discussed here, that does not automatically suppress the separate Origin header. The two headers serve different purposes: Referer conveys referrer information, while Origin identifies the origin relevant to browser security checks.

Finding no-referrer in DevTools is therefore insufficient to attribute a CORS failure to that policy. Likewise, a header missing from a copied excerpt is not evidence that it was missing from the actual request.

The MDN Referrer-Policy reference describes these behaviors.

What Okta documentation adds

Okta documents Trusted Origins for certain legitimate cross-origin requests to its APIs. It also distinguishes CORS permissions from redirect permissions.

That provides context, but it does not make every CORS error proof of a missing Trusted Origin entry. CORS support is API-specific, and the applicable requirements depend on the endpoint and authentication mechanism. The observed exchange still matters.

See Okta’s official CORS guide for the supported integration model.

A widget or SDK version string is useful context for a report. On its own, it does not demonstrate that the component caused the failure.

Preserve the evidence, remove the secrets

A useful technical note should include:

• The complete console error.
• The initiating origin and destination origin.
• The preflight method and observed status, when present.
• The main request’s method and observed status.
• The response headers relevant to CORS.

Separate observations from interpretations. “The console reports a failed preflight” describes evidence. “The server explicitly rejected this origin” may require additional support.

Share the smallest relevant extract. HAR files, authentication URLs, and request bodies can contain cookies, tokens, credentials, session identifiers, or personal information.

When replacing domains with placeholders, preserve their relationships. Requests that originally shared an origin should retain the same replacement origin. Otherwise, anonymization can change the technical meaning of the evidence.

The conclusion supported by this case

The reported details support a limited diagnosis:

If the request is initiated by the test page, the page and authentication endpoint have different origins, and the browser reports a CORS failure. The available excerpt does not establish whether it occurred during preflight or while validating the main response.

Identifying that stage is the next evidentiary gap. Until it is resolved, the error cannot establish that the server received nothing, processed nothing, or requires a particular configuration change.