Introducing the Ping SDKs

The Ping SDKs can leverage authentication journeys. Use the SDKs to easily step through each stage of an authentication tree by using callbacks.

For more information, refer to Supported callbacks.

For example, let’s say you want to use this authentication flow:

You can use the SDK to make each callback call the next step in the tree. You don’t have to traverse the REST APIs to call the next step.

The Ping SDKs empower developers to build applications that can handle the changes to your authentication journeys in real time, without having to redeploy your app.

The Ping SDKs use the OAuth 2.0 auth code flow, and support PKCE.

This method is the best practice for first-party applications. The SDK automatically handles token exchange for you, and also securely stores the tokens. Token refresh is automatically handled by the SDK, so you don’t have to think about it.

The Ping SDKs also support obtaining OAuth 2.0 tokens from a PingOne or PingFederate server. To learn more, refer to the tutorials.

In some scenarios, your company may have multiple native applications that customers have installed on their devices. You can use the SDK to seamlessly sign users in to multiple applications on a device. When the customer signs in to one application, they are automatically signed in to a second application on that device—​without having to authenticate again.

The Ping SDKs can help you integrate push authentication or one-time password (OTP) capabilities into your mobile applications so your end users don’t have to download and use a dedicated Authenticator application. The SDK’s Authenticator module can support:

The SDK has a modular architecture and is designed with flexibility in mind. Don’t want to use our method for jailbreak detection? No problem! Just plug in your own method, or use any 3rd-party plug-in instead.

Using the SDK, you have the option to collect device profile information to use in your authentication flows. You might use this data to compare a user sign-in to a prior sign-in event. If the device profile has changed too much from the prior event, you can deny the sign-in.

Detecting whether a device is jailbroken or rooted assures developers that a device is managed by the authorized device owner. Jailbroken devices may be running outdated OS versions, or could be missing security patches. Detecting whether a device is jailbroken can provide valuable insight into the security posture of a device. You can feed that insight into authentication flows.

The iOS and Android SDKs generate a score to determine if a device is jailbroken or rooted. There are a number of factors that go into creating this score. The score ranges from 0 to 1.0, where 1 indicates the device is an emulator.

You can use this information as part of an authentication flow to ask the user for another factor, or to deny access entirely.

Ping SDKs can automatically generate a device ID for you. You can use the ID with PingIDM or PingAM to allow your users to manage their devices.

For example, you can insert the device ID and associated data into a user’s profile. This lets them view their devices and set the devices as trusted. You can also decide to use a recognized device in an authentication flow to avoid asking a user for another factor.

You can collect latitude and longitude information from your users via the Android and iOS SDKs. Apps that use location services must request location permissions from users.

The Ping SDKs have a sample user interface that can be used for rapid prototyping, or as a reference implementation for building your own UI. Let’s say you want to get an authentication experience in front of some of your users or business stakeholders. You can easily build an authentication journey and display the results immediately in your application.

The Ping SDK for JavaScript supports web biometrics functionality provided by PingAM.

Web biometrics lets users authenticate by using an authenticator device; for example, the fingerprint scanner on their laptop or phone, or a USB key such as those provided by Yubico, or Google’s Titan security keys.

Communication with authentication devices is handled by the SDK. PingAM requests that the SDK activates authenticators with certain criteria; for example, it must be built-in to the platform, or is a cross-platform roaming USB device. You can also specify that the device must verify the identity of the user, rather than simply that a user is present.

The Ping SDKs have two methods for handling web biometrics: one for registering devices, and another for authenticating using a registered device.

For more information, refer to Web biometrics.

Mobile biometric authentication lets users authenticate by using a mobile device’s biometric authentication. Communication with the platform authenticator, for example, with a fingerprint reader or facial recognition system, is handled by the Ping SDK.

The Ping SDK communicates with PingAM to perform biometric registration and authentication using the WebAuthn nodes. Similar to WebAuthn with the Ping SDK for JavaScript, you can configure the nodes in PingAM to request that the SDK activates authenticators with certain criteria.

The Ping SDKs enable passkey support on supported platforms. Passkeys can be synchronized across a user’s devices and browsers, simplifying device registration and enabling passwordless flows.

This feature is available in the ForgeRock SDK for Android 3.0 and the ForgeRock SDK for iOS v3.0 or later. It requires PingOne Advanced Identity Cloud, or PingAM 7.1 or later.

For more information, refer to What are mobile biometrics?.

You can authenticate by using a trusted Identity Provider (IdP), like Apple, Facebook, Google, and many others. These IdPs are used for authentication and identity verification. This is often referred to as Social Login or Social Authentication. These IdPs return the necessary information to integrate user information into your user’s profile.

Depending on the device platform (Android, Web or iOS), the user is redirected from the current web application or login page to the IdP’s authorization server. Or, if on a native mobile app, the user is directed to the IdP’s authentication SDK, if available. Once on the IdP via a web page or SDK, the user will authenticate and provide the necessary consent required for sharing the information. When complete, the user is redirected back to your app or to your server to complete the authentication journey.

For more information, refer to Set up social login.