Just to double check that I understood this correctly (I’m so surprised that I want to double check).
Reading this Cross-Origin Authentication I understood that the only way to allow any user to authenticate with Auth0 (with username and password) is to use hosted pages (so redirecting to a different domain) because using embedded login or custom login means that for some browsers if the user disable third-party cookies it will not be able to authenticate?
Is this correct?
Technically is not the only way because although client applications don’t have the resource owner password credentials grant types enabled by default, if you enable them then you can authenticate username/password credentials associated with database connections and some enterprise connection with a single call to /oauth/token endpoint and this does not require any cookies. However, it also implies that the authentication is performed in a stateless way in the sense that it does not lead to the creation of an authentication session at the identity provider which for web applications would be a really bad user experience.
In conclusion, the recommendation in general is to go with the centralized login experience (hosted page). In some specific situations if the constraints in cross-origin authentication are acceptable you have an additional alternative, but you’re correct that you have to take in consideration the constraints. As an additional note, in the future the centralized login (hosted page) may be allowed to reside in a domain of your choosing instead of the default one based on tenant name, however, there is still no concrete information about when this feature will be available and in what conditions.