CORS error when initiating silent auth requests

Knowledge Articles
, , , ,
1

Overview

This article describes why a Cross-Origin Resource Sharing (CORS) error may occur during silent authentication attempts. Specifically, it addresses scenarios where the authentication call is successful when initiated from the application’s root URL but fails when initiated from an API route within the same application.

Applies To

  • CORS (Cross-origin resource sharing)

Cause

The /authorize request should be a regular interactive navigation, not performed from JavaScript.
It is possible that an API is redirecting to /authorize and the JavaScript performing the request is following that redirection.

Solution

The Cross-Origin Resource Sharing (CORS) error occurs because the /authorize endpoint is designed for browser-driven, full-page navigations (like user logins) and does not implement the necessary CORS headers to allow requests directly from JavaScript originating from a different domain. JavaScript requests are subject to the Same-Origin Policy, which prevents calls to different origins unless the target server explicitly allows it via CORS.

This error typically manifests in two incorrect implementation scenarios:

  • JavaScript code directly attempts to call the /authorize endpoint.
  • JavaScript code calls an API endpoint (e.g., https://myapi.com). Upon detecting a missing or invalid authorization, this API endpoint incorrectly responds with a redirection (HTTP 301/302) to the /authorize endpoint instead of an error status. The browser attempts to follow this redirect from the JavaScript context, leading to the CORS error because /authorize does not permit the cross-origin request.

To resolve this issue:

  1. Ensure the API endpoint returns a 401 Unauthorized status code when authorization is missing or invalid for requests originating from JavaScript. Do not configure API endpoints to redirect to the /authorize endpoint in response to failed authorization checks on API calls. This allows the client-side JavaScript application to catch the 401 error and initiate a proper, browser-driven authentication flow if necessary.
  2. Could you verify that the client-side JavaScript code does NOT make direct Workspace or XMLHttpRequest calls to the /authorize endpoint? Authentication requiring /authorize should be triggered through full-page browser navigation.

Example Scenario Causing the Error:

// Incorrect implementation: JavaScript calls an API
const response = await fetch("https://myapiserver.com/api/users");

// If myapiserver.com detects no valid session/token and incorrectly
// responds with a 302 redirect to https://yourtenant.auth0.com/authorize,
// the browser's attempt by the fetch API to follow this redirect
// will be blocked by CORS rules, resulting in an error.

Correct API Behavior: An API endpoint (e.g., https://<your-tenant>/api/v2/users) is called without a valid token should return a 401 Unauthorized status directly.

Correct /authorize Usage : Navigating to a protected web page (e.g., https://manage.auth0.com) in the browser without an active session correctly triggers a full-page redirect to /authorize, handled entirely by the browser, which does not involve CORS restrictions.

1 Like