Ping Orchestration SDKs 2.0

One SDK family for DaVinci, AIC/PingAM journeys, and OIDC across web and native. Here's what changed, what it means for your apps, and how to get started.

Ping Orchestration SDKs 2.0 are our next generation of client-side SDKs for JavaScript, iOS, and Android! They give you one unified way to connect your apps to PingOne DaVinci flows, PingOne Advanced Identity Cloud / PingAM journeys, and OIDC redirect with any OIDC-compliant server. You integrate once, then evolve journeys and flows on the server without constantly rewriting your app.

Want to get started now? Jump to Getting Started!

Key features

The SDKs handle multi-client orchestration for you. A single app can work with multiple OAuth clients simultaneously, such as one for primary login and another for step-up or high-risk actions. The SDK manages tokens and clients so your code can focus on business logic rather than OAuth details.

They also integrate Ping’s universal services through the orchestration layer. The SDK can collect device and behavioral context (for example, with PingOne Protect) and feed that into your DaVinci flows or AIC/PingAM journeys so you can drive risk-based decisions from a single place. As we add more services, like PingOne MFA for PingOne or privacy-preserving biometrics with PingOne Keyless, they appear through the same orchestration model instead of new one-off integrations.

Across JavaScript, Android, and iOS, the orchestration model is consistent. Teams can reuse patterns across web and native apps, and new developers can ramp up faster because the concepts look and feel the same on each platform.

Why Orchestration 2.0?

Historically, DaVinci flows and AIC/PingAM journeys had separate SDK stories. Orchestration 2.0 brings them together into one orchestration-first family across JS, Android, and iOS.

The older ForgeRock SDKs evolved into several large libraries. Orchestration 2.0 replaces that with a modular, pluggable design with networking, journeys, FIDO/passkeys, MFA, device binding, device ID/profiling, and more, so you only include what you need and stay aligned with modern Kotlin, Swift, and JS practices. This single orchestration plane is where we focus on performance, security, and new capabilities.

Benefits vs. ForgeRock SDKs

If you use the ForgeRock JS, Android, or iOS SDKs today, Orchestration 2.0 gives you one SDK family for both DaVinci and journeys. The same core ideas apply whether you’re building SPAs or native apps with AIC/PingAM.

The architecture is more modular: journey orchestration, FIDO2/passkeys, OATH and Push MFA, device binding, migration helpers, device ID/profiling, jailbreak/root detection, and reCAPTCHA Enterprise are all focused modules. You import only what you need, which helps with footprint and security. The orchestration model also adds built-in multi-client support, so scenarios like primary login plus step-up are handled by the SDK instead of custom token juggling. Everything sits on modern JavaScript, Android, and iOS foundations.

Why new SDKs vs. evolving ForgeRock SDKs

The ForgeRock SDKs assumed separate paths for DaVinci and AIC/PingAM and concentrated a lot of behavior into a small number of libraries. That made it hard to keep adding features, support richer token patterns, and plug in new services without extra complexity.

With Orchestration 2.0, we refactored orchestration into a new architecture, split cross-cutting concerns (networking, storage, device binding, FIDO, MFA, and so on) into modules, and made these SDKs the contract for all new integrations and universal services. The goal is that app development feels simpler and more consistent, even as the platform becomes more powerful behind the scenes.

If you use ForgeRock SDKs with PingOne AIC/PingAM

The ForgeRock JS, Android, and iOS SDKs are now deprecated. They’ll receive critical security and bug fixes for about two years after Orchestration 2.0 GA, until 15 April 2028. After that, they won’t be updated, and the expectation is that customers move to the Orchestration SDKs.

For most AIC/PingAM customers, treat migration as a structured project. Start with the detailed guides to understand how to migrate from the ForgeRock SDKs to the Ping Orchestration SDKs. These guides provide concrete examples of how to migrate existing ForgeRock integrations to the new SDKs and make it easier to map journey callbacks, device behavior, MFA flows such as OATH, and Push.

Use AI Coding Agents (GitHub Copilot, Cursor, Claude Code, etc) to expedite migration:

  • Context-ready: We’ve included structured migration.md files for the ping-android-sdk and the ping-ios-sdk. You can feed these files directly into your AI’s context to help it automatically map old ForgeRock classes to the new Orchestration 2.0 modules.
  • Automated Refactoring: Use prompts to help the agent rewrite your networking and journey logic, significantly reducing the manual effort of updating callback handlers and device binding code.
  • Coming Soon: We are currently developing a dedicated Agent Skill that will act as a migration specialist, providing real-time, project-specific guidance for moving your unique identity flows into the new orchestration plane.

A common pattern is to run the new and legacy SDKs side by side. The Orchestration SDKs can coexist with the old ones, and dedicated migration modules for device binding, device ID, and OATH/Push (plus encrypted state helpers) are there to migrate identifiers without forcing most users to re-enroll. After you’re confident in the new model, you initialize the Orchestration SDKs in your apps, move UI and callback handling to the new patterns, and keep most behavior in AIC/PingAM journeys so you can keep iterating without constant app releases.

A typical migration has three phases:

  1. Start with inventory and design: list all apps and journeys using the ForgeRock SDKs, classify the flows they rely on: sign on, registration, self-service, MFA, device binding, passkeys, and so on, and call out any reliance on Transactional Authorization or the Token Vault.
  2. From there, you run a pilot on one representative mobile or web app. You integrate the Orchestration SDKs in a feature branch, use the migration guides and sample apps (with or without AI assistance) to map journeys to the new orchestration model, and validate device binding and device ID migration in a non-production environment.
  3. After you feel confident, you move into rollout: promote the pilot to production, extend the new SDKs to other apps and platforms, and then remove the legacy SDK dependencies when you have full coverage.

In the Orchestration 2.0 release, Transactional Authorization and the JavaScript Token Vault are not included. If you rely on either in production, contact your Ping representative and open a support case so we can work through options with you rather than attempting a direct, like-for-like migration.

Docs, Login Widget, and resources

DaVinci SDK docs have been folded into the Orchestration SDK documentation. DaVinci-focused guides and tutorials now live there, and older DaVinci-only pages will redirect or point you to the new docs. If you used the “DaVinci module” docs before, the Orchestration SDK JavaScript, Android, and iOS docs are now your primary reference.

The Login Widget will soon live in its own repository, allowing it to evolve independently while remaining part of the orchestration story. It will be referenced from both the deprecated ForgeRock SDK docs and the Orchestration SDK docs as one of the available integration options alongside a fully custom UI.

Sample applications for JavaScript, Android, and iOS SDK and the SDK repositories and packages are all linked from the Ping Developer Portal. The portal acts as the central entry point for Orchestration SDK documentation, API references, tutorials, so you can find everything in one place.

Getting Started

To get started with the Orchestration SDKs:

  1. Reference our tutorials for DaVinci or AIC/PingAM.
  2. Clone our SDK sample apps repository and enter relevant server details to understand the fundamentals and walk through core orchestration flows end to end, so you can compare a working reference to your current setup before touching production or wondering how to integrate authentication flows into your existing mobile and web apps.
  3. Integrate into your existing app.

The SDKs are available from standard locations: JavaScript on GitHub and NPM, Android on GitHub and Maven, and iOS on GitHub and Swift Package Manager. The Ping Developer Portal will be the main entry point, bringing together orchestration docs, sample apps, and API references in one place.

ℹ️ Note: Soon you’ll see AI-powered Agent Skills and tools to help integrate into existing apps or set up sample apps quickly!

References

Do you have thoughts or questions on this article? Join the discussion on the Ping Identity developer community!

Tags

Developer Tools & SDKs #SDKs #PingOne DaVinci #AIC #Advanced Identity Cloud #PingAM #OAuth #mobile #identity #developer experience