Last Updated: Dec 16, 2024
Overview
At first glance, it might seem that “Allowed Origins (CORS)” and “Allowed Web Origins” are doing the same thing. To avoid any confusion about when it is needed to use one or the other (or both), this article presents the differences between those two.
Applies To
- Allowed Origins (CORS)
- Allowed Web Origins
Solution
From a high level, this apparent overlap has to do with maintaining support for certain legacy flows that use specific Authentication API endpoints (Allowed Origins CORS), as well as newer flows with some newer endpoints (Allowed Web Origins). The Allowed Web Origins field is used for a handful of very specific flows such as Device Code flow or when response_mode=web_message.
On the other hand, the Allowed Origins (CORS) field is specifically for logins that originate from Javascript code, which is sometimes used in embedded login flows. For more details on these fields, see the Application settings - Application URIs documentation.
Also, note that Auth0 does not recommend using an embedded login flow for security reasons and all of our up-to-date SDKs and Quickstart guides utilize redirect flows to the Universal Login by default. For more details, check out our Centralized Universal Login vs. Embedded Login documentation.
In regards to knowing which fields are required for various application types, we recommend referring to the Quickstart guides for the application’s specific tech stack, which will cover these requirements. For example, using the auth0-spa-js SDK in a Javascript application does not require values to be added to the Allowed Origins (CORS) field by default since this SDK’s main login method, loginWithRedirect, uses a redirect flow that does not require CORS. It does require the application’s domain to be added to the Allowed Web Origins field to allow for silent authentication flows since that uses response_mode=web_message.