When you add an application, PingOne creates a client ID for the application, which is a unique identifier for the application and cannot be changed.

PingOne supports several application types. Use the application type that best fits your requirements.

SAML application
A browser-based application with a server-side component, such as .NET web apps, JSP/Java, Node.js, or Ruby on Rails. SAML applications typically have functions similar to desktop applications, and use SAML for authentication.
OIDC Web application
A browser-based application with a server-side component, such as .NET web apps, JSP/Java, Node.js, or Ruby on Rails. OIDC web applications typically have functions similar to desktop applications, and use OIDC for authentication.
Native application
An application that's installed and run directly on the local operating system, like Java, Objective-C, Swift, or React. Native applications are typically intended for mobile devices. Native applications use OIDC for authentication. A native application can be used as both an accessing application and as an authenticating application for MFA.
Single page application
A browser-based application that runs on the front-end with no server-side component, such as Sencha Touch, AngularJS, and React. A single page application runs on the client side after it loads, so it can't keep a client secret. Single page applications use OIDC for authentication.
Device authorization
An application that allows a device to obtain authorization from the user through a second device, such as a smartphone. Device authorization is typically used for applications that run on an input-constrained, Internet-connected device, such as a smart TV.
Worker
An administrator application that can have the same roles as human administrators. Worker applications are configured with the client credentials grant type by default, but can be configured to support multiple grant/response types, just like the other application types. Worker applications use OIDC for authentication.

You can use Worker applications to create a userless service application that can perform administrator functions. The role assignments determine which functions the application can do. The Worker application can also perform administrator functions with the role of its user. To do this, give the application an additional grant type, which is used instead of the role assignments.

Worker applications can use a user-based grant type (implicit or authorization_code). With this configuration, you can assign only OIDC scopes to the application. When getting a token using a user-based grant type, the user's role assignments are used. When getting a token using the client_credentials grant type, the application's role assignments are used.

Note:

Worker apps cannot be used to facilitate end-user sign ons, but they can be used to sign on users that have roles.