Skip to main content

Documentation Index

Fetch the complete documentation index at: https://auth-test.auth0-mintlify.app/llms.txt

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.

Browser-based login

Native embedded login

If you prefer to embed your own login pages within your native/mobile app, you can implement our login widget, Lock, directly into your app with:

Passwordless

Embedded Passwordless Login in Native Applications

Considerations

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.

Native social login

You can add functionality to your native app letting users authenticate with social natively, within the application: Facebook Login: Sign In with Apple:

Rate limits

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:
Request TypeBody
grant_typeurn:ietf:params:oauth:grant-type:token-exchange
subject_token_typehttp://auth0.com/oauth/token-type/apple-authz-code

Limits for production tenants of paying customers

EndpointPathLimited ByRate Limit
Get Token/oauth/tokenAny native social login request50 per minute with bursts up to 500 requests

Limits for non-production tenants of paying customers and all tenants of free customers

EndpointPathLimited ByRate Limit
Get Token/oauth/tokenNative social login requests and IP30 per minute