PingID multifactor authentication (MFA)

Most organizations have a traditional first factor authentication flow, in which the native application authenticates via an authentication server using the user's username and password. Implementation of PingID SDK requires minimal changes to this paradigm.

Multifactor authentication (MFA) is a security measure that requires more than one method of authentication from independent categories of credentials, to verify the user’s identity for a login or for other transactions. A device must be paired with the PingID SDK server, in order for MFA to be performed.

Supported multifactor authentication (MFA) methods

PingID SDK’s multifactor authentication mechanism includes:

MFA using the PingID SDK component

In PingID SDK, MFAs are implemented by the native mobile app’s PingID SDK component, creating and passing a payload to the customer server, and from there to the PingID SDK server. PingID SDK provides a configuration option for adding an extra out of band element of device verification. PingID SDK also supports transaction approval for application contexts which require elevated security.

Device authorization

Device authorization is a seamless MFA, executed in the background, that does not influence the user experience. It’s comprised of a payload, a small packet of data that identifies the device, which is passed from the native application to the authentication server, and then onwards to the PingID SDK server. This enables performing MFA as part of the regular authentication flow, with minimal impact in terms of code changes and performance, and no impact on user experience.

A payload is a string produced by the PingID SDK component for the customer mobile application.

  • The customer mobile application passes the payload to the authentication server when the user logs into the application.
  • The authentication server then passes the payload to the PingID SDK server in order to complete the MFA.
  • The MFA verification result is returned to the authentication server, which in turn, uses the MFA verification result to approve or deny the device’s login request.

Adding an out of band (OOB) MFA element to the authentication

Out of band (OOB) MFA is an optional extension to payload based MFA, so that it incorporates a separate communications channel to verify the user’s device. This makes it more difficult for fraudsters to bypass or tamper with the authentication process. Out of band MFA provides a superior level of security, which may add several seconds (a configurable timeout will be featured in the future) to the duration of the authentication flow.

In PingID SDK, out of band authentication can be configured so that in parallel to the payload based verification, a push message will be sent (via FCM or APNS) to the device and will provide an additional authentication measure. The push mechanism is on the basis of “best effort”, meaning that if the push is not received or is not successful, the transaction is not canceled or denied. Rather, PingID SDK returns all the information to the customer server, whose logic will determine whether to cancel or deny the transaction, or alternatively, how to progress.

Transaction approval using PingID SDK

Transaction approval (also known as step up authentication) is elevated security for a high value or high risk resource or service, within the particular context of an application, which requires authentication using a higher assurance credential than previously required for general access of the application.

In some applications, it makes sense not to use the second factor authentication capabilities during the login process, but activate it during certain user actions, such as a payments or bank transfers. These actions are referred to as transaction approvals, as they elevate the user’s security context only when required by the business logic.

PingID SDK enables the developer to incorporate transaction approval flows and authentications into native applications quickly and easily. In PingID SDK, transaction approvals are regular authentications which are implemented in exactly the same way, and can be customized by the customer’s developer. A string containing information about the transaction can be sent as part of the authentication, and the native app can use it to show the transaction information, or to display different behavior during the authentication.