Native Login

Learn about the different login options for native mobile applications.

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

• Android Quickstart
• iOS Swift Quickstart

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:

• Lock.swift
• Lock.Android

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 Client ID 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 access tokens. Mitigations include using DPoP and Passkey APIs to bind tokens and credentials to your client.

• Single sign-on (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 identity providers natively, within the application:

Facebook Login:

• Add Facebook Login to Native Apps
• Android - Facebook Login
• iOS Swift - Facebook Login

Sign In with Apple:

• iOS Swift - Sign In With Apple
• Add Sign In with Apple to Native iOS Apps

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 Type	Body
grant_type	urn:ietf:params:oauth:grant-type:token-exchange
subject_token_type	http://auth0.com/oauth/token-type/apple-authz-code

Limits for production tenants of paying customers

Endpoint	Path	Limited By	Rate Limit
Get Token	/oauth/token	Any native social login request	50 per minute with bursts up to 500 requests

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

Endpoint	Path	Limited By	Rate Limit
Get Token	/oauth/token	Native social login requests and IP	30 per minute