Instructions for

On this page

Build a custom sign-in UI in your mobile app

Note: This document is written for Okta Classic Engine. If you are using Okta Identity Engine, contact your Okta account team for guidance or ask on our forum. See Identify your Okta solution to determine your Okta version.

You can connect your mobile app to Okta and sign users in by opening a browser. However, if you prefer that users not leave your app, build a custom sign-in UI with platform-specific controls and screens instead.

Use this guide to build a customized sign-in experience inside your mobile app.

Note: We strongly advise against using WebViews for authentication on mobile apps as this practice exposes users to unacceptable security risks. See OAuth 2.0 for Native Apps. Consider using Okta's native SDKs instead.

Note: If the browser sign-in method works for your app, Okta recommends using that because building a custom sign-in UI takes more effort and development time.


Learning outcome

Customize the sign-in experience with a mobile sign-in UI.

What you need

Sample code


Create an Okta app

Before you can sign a user in, you need to create an Okta app that represents your mobile app.

Use the Okta app that you created when you walked through the Sign users into your mobile app using the redirect model guide.

Add and configure packages

To build the custom sign-in UI, you need to install and configure a platform-specific Okta SDK to your app.

You should already have added and configured packages when you walked through the Sign users into your mobile app using the redirect model guide.

In addition, you need to install the platform-specific Okta Authentication SDK. This SDK works together with the OpenID Connect SDK that you have already installed to make authentication requests to Okta.

Build the primary authentication form

The Okta Authentication SDK is built around a state machine. Review the available states before you use this library.

You can implement an authentication flow using one screen or using multiple screens. When you use multiple screens, you can split responsibilities across screens and then inject related data as a dependency.

For example, multiple screens could handle:

  • Sign-in/password input
  • Multifactor enrollment
  • Factor selection
  • Multifactor verification

Handle authentication responses

Every authentication transaction starts with primary authentication, which validates a user's password. The password policy, MFA policy, and sign-on policy are evaluated during primary authentication. The policies are evaluated to determine if the user's password is expired, a factor should be enrolled, or additional verification is required. The transaction state of the response depends on the user's status, group memberships, and assigned policies.

Note: Custom sign-in only works with Org MFA. This means that before you exchange the session token for an access token, you must ensure that App-Level MFA (opens new window) is disabled for the application.

Note: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy (opens new window).

Next steps

When a user signs in, their profile information (stored in Okta) is made available to your application. Use this information to personalize your app's UI for the user. See Get info about the user for details.