> ## Documentation Index
> Fetch the complete documentation index at: https://auth0-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Learn about the different login options for native mobile applications.

# Native Login

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](/docs/authenticate/database-connections/passkeys) or [Native Social Login](/docs/authenticate/identity-providers/social-identity-providers) for re-authentication, factor enrollment, or step-up authentication inside the application.

## Browser-based login

* [Android Quickstart](/docs/quickstart/native/android)
* [iOS Swift Quickstart](/docs/quickstart/native/ios-swift)

## 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](/docs/libraries/lock-swift)
* [Lock.Android](/docs/libraries/lock-android)

### Passwordless

[Embedded Passwordless Login in Native Applications](/docs/authenticate/passwordless/implement-login/embedded-login/native)

### 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 <Tooltip tip="Client ID: Identification value given to your registered resource from Auth0." cta="View Glossary" href="/docs/glossary?term=Client+ID">Client ID</Tooltip> 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 <Tooltip tip="Access Token: Authorization credential, in the form of an opaque string or JWT, used to access an API." cta="View Glossary" href="/docs/glossary?term=Access+Tokens">access tokens</Tooltip>. Mitigations include using [DPoP](/docs/secure/sender-constraining/demonstrating-proof-of-possession-dpop) and Passkey APIs to bind tokens and credentials to your client.

* **<Tooltip tip="Single Sign-On (SSO): Service that, after a user logs into one applicaton, automatically logs that user in to other applications." cta="View Glossary" href="/docs/glossary?term=SSO">Single sign-on</Tooltip> (SSO):** Cross-application SSO across native apps requires shared session state. [Native to Web SSO](/docs/authenticate/single-sign-on/native-to-web) 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](https://tools.ietf.org/html/rfc8252)):** RFC 8252 recommends external user-agents for browser-mediated OAuth flows in native apps.

Modern embedded paths, such as [Passkey APIs](/docs/authenticate/database-connections/passkeys) and [Native Social Login](/docs/authenticate/identity-providers/social-identity-providers), 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 <Tooltip tip="Identity Provider (IdP): Service that stores and manages digital identities." cta="View Glossary" href="/docs/glossary?term=identity+providers">identity providers</Tooltip> natively, within the application:

Facebook Login:

* [Add Facebook Login to Native Apps](/docs/authenticate/identity-providers/social-identity-providers/facebook-native)
* [Android - Facebook Login](/docs/quickstart/native/android-facebook-login)
* [iOS Swift - Facebook Login](/docs/quickstart/native/ios-swift)

Sign In with Apple:

* [iOS Swift - Sign In With Apple](/docs/quickstart/native/ios-swift)
* [Add Sign In with Apple to Native iOS Apps](/docs/authenticate/identity-providers/social-identity-providers/apple-native)

### 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 |