Push OTP

For comparative information about MobilePASS and MobilePASS+, migration details, deployment considerations, and MobilePASS+ FAQ (such as ordering, licensing, allocation, and token enrollment), see the Push OTP Planning Guide.

Improved user experience

The Push OTP solution leverages out-of-band communication channels to provide a frictionless user experience around two-factor authentication with a mobile phone.

It’s likely that most users already own and always carry a device that they can use as a second factor of authentication. Using the mobile phone as an authenticator replaces the need for a user to carry any additional hardware. The addition of out-of-band delivery of passcodes takes convenience one step further. It means users no longer have to manually find the application to open it and then type anything in. With Push OTP, a user can:

• Receive authentication requests in real time via push notifications to their smart phone.

• Assess the validity of the request with the information displayed on the screen.

• Respond quickly with a one-tap response to approve or deny the authentication.

How does login with push OTP work?

When a user wants to access an application that supports Push OTP, they make the choice to login with push OTP either by selecting the option, or by leaving the OTP field empty or typing a 1-character passcode. (Refer to Triggering push notifications in the agent.) This cues STA to send an out-of-band push notification to the user’s mobile device requesting login authorization. When the push notification arrives on the user’s mobile device, they can respond to the request directly on the push notification, or tap the notification to load additional request details within the MobilePASS+ application, and then respond.

The login method depends on the integration. Refer to Configure applications for push OTP.

The STA login request requires the user to either accept or reject the notification. Accepting the notification automatically generates an OTP and sends it to STA via a secure out-of-band communication channel. (The ability to respond directly on the push notification is largely dependent on the operating system of the mobile device. Later versions of the OS have this capability, while earlier ones may not.) After the OTP authentication is validated by STA, access to the requesting application is automatically granted.

Automatic out-of-band OTP delivery

Using out-of-band (OOB) authentication provides improved usability compared to traditional offline or disconnected authentication methods, without compromising security.

With Push OTP, users no longer need to manually type in a 6- or 8-digit OTP to access a protected application every time. A user can verify the validity of a pending authentication request directly on their mobile device, and approve it with one tap. Approval automatically triggers an OTP to be delivered to STA through an OOB channel. 

Push OTP authentication flow

The image below describes the Push OTP authentication flow. Some applications work by leaving the OTP field empty or by typing a 1-character passcode. Other applications work by presenting the user with a choice on the login screen. The authentication flow varies, based on the integration. (Refer to Triggering push notifications in the agent.)

1. The user wants to access an application that requires two-factor authentication (for example, Microsoft 365). They provide their user name and password, and then click the Sign In button.

2. The application sends the login requests to the server, which identifies the user and their mobile device.

3. The server directly triggers an on-the-go authentication request. If push is used, the user receives a push notification on their mobile device to indicate that a login request is pending.

   The integrated application (for example, Microsoft 365) determines whether it supports push. If it does, then a push is triggered.

4. The user taps on the notification to view the login request details, and responds with a tap to approve or deny the request. (In some cases, the user might need to provide an additional PIN before they are permitted to view and respond to the login request.) The response (with a passcode attached) is sent back to the server, where it is validated. When the authentication succeeds, the application is automatically refreshed, and access is granted to the user.