Use this file to discover all available pages before exploring further.
Native mobile applications can use native login flows, browser-based login flows, or both within the same application.In a browser-based login flow, the user is shown a web browser and redirected to the Auth0 login page for sign up or log in. For example: an iOS application opens a SafariViewController or an Android application opens a Custom Chrome Tab.With a native login flow, the user signs up, signs in, enrolls factors, or registers passkeys directly inside the application.Native applications can use a combination of both native and browser-based login flows. For example, you can use a browser-based redirect for primary sign-in and embedded Passkey APIs or Native Social Login for re-authentication, factor enrollment, or step-up authentication inside the application.
When you implement native embedded login with a custom credential form, keep the following considerations in mind.
Phishing/security: An unauthorized party could decompile or intercept traffic to or from your application to get the and authentication URL. With this information, the unauthorized party could create a rogue application, upload it to an application store, and use it to phish for usernames, passwords, and . Mitigations include using DPoP and Passkey APIs to bind tokens and credentials to your client.
(SSO): Cross-application SSO across native apps requires shared session state. Native to Web SSO lets a native app share a session with a web application. Sharing tokens directly across native apps via a shared keychain is not aligned with the OAuth 2.0 specifications.
Implementation effort: A custom credential form can take more time to implement than the system browser flow that ships with the Auth0 native SDKs. Similarly, when we release new features that affect the login UI, you must add them to the app and ship the update to users.
OAuth 2.0 best practices (RFC 8252): RFC 8252 recommends external user-agents for browser-mediated OAuth flows in native apps.
Modern embedded paths, such as Passkey APIs and Native Social Login, are protocol-compliant token exchanges and avoid most of these trade-offs.
Limits are only applied to requests related to the Native Social Login flows, which are identified based on the body of the requests with the following initial criteria: