--- title: Applications operations description: Applications represent the protected web applications and APIs that receive client requests. component: pingaccess version: 9.0 page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_applications_operations canonical_url: https://docs.pingidentity.com/pingaccess/9.0/pingaccess_user_interface_reference_guide/pa_applications_operations.html revdate: August 8, 2025 section_ids: application-types: Application types protecting-applications: Protecting applications spa-support: SPA Support section_cwr_4dm_d2b: About SPA support benefits-of-spa-support: Benefits of SPA support enabling-spa-support: Enabling SPA support documentation-scope: Documentation scope --- # Applications operations Applications represent the protected web applications and APIs that receive client requests. Applications: * Correspond to a single target site. * Have a common virtual host and context root. | | | | - | ------------------------------------------------------------------------------------- | | | The combination of virtual host and context root must be unique for each application. | * Use a common web session and identity mapping. * Consist of one or more resources. Each application contains at least a root resource. Use resources to partition the application into areas requiring distinct access control. ## Application types There are three application types: 1. **Web** 2. **API** 3. **Web+API** **Web+API** applications allow administrators to configure both **Web** and **API** settings for an application. These applications are able to switch between web and API processing behaviors on the fly based on whether the inbound request contains a web session cookie (**Web**) or an OAuth *(tooltip: \
\

A standard framework that enables an application (OAuth client) to obtain access tokens from an OAuth authorization server for the purpose of retrieving protected resources on a resource server.\

\
)* token (**API**). If the inbound request contains neither, PingAccess uses the method you specify as the fallback type for the application. ## Protecting applications Applications can be protected by a PingAccess gateway or a PingAccess agent: * In a gateway deployment, the target application is specified as a site. * In an agent deployment, the application destination is an agent. To protect applications, you can apply access control and request processing rules on the ***\* Policy** tab of the application configuration. ## SPA Support ### About SPA support Single-page application (SPA) support merges the conventional `401` unauthorized response of an **API** application with the traditional `302` redirect response of a **Web** application, returned when a client request does not contain an authentication token. The SPA supported result is a `401` response containing a JavaScript body that can initiate a `302` redirect. API clients will ignore the JavaScript body and react appropriately to the `401` response. However, browser clients will disregard the `401` response and execute the JavaScript body, resulting in a redirect to the token provider to authenticate. Since clients self-select the portion of the response they're prepared to process, the result is a seamless authentication experience regardless of the client type. ### Benefits of SPA support When SPA support is enabled for **Web+API** applications, where a variety of client types are expected to communicate with the application, a fallback type is no longer required. This is because both web and API clients are properly redirected to authenticate by the same response. For **Web** applications, authentication challenge responses fulfill the same role. You can find more information in [Authentication](pa_authentication.html). It might also benefit **Web** or **API** application types, for example, if a new version of a **Web** application contains JavaScript framework components to call APIs. In this case, SPA support can help mitigate issues in responding to different client types for authentication, but it won't enable the full features of the other application type. You would need to migrate the application to a **Web+API** configuration to take advantage of the full functionality, such as for authentication, rules, or identity mapping. ### Enabling SPA support SPA support is enabled by default for **Web** applications. If you want to modify SPA support for **Web** applications, do so using an authentication challenge policy. For **API** and **Web+API** applications, you can configure SPA support directly. You can find additional guidance on preparing a SPA to work with PingAccess in the [SPA developer's guide](https://github.com/pingidentity/pa-spa-guide-react) on [GitHub](https://github.com/pingidentity?q=pa-). This guide contains a sample application before and after onboarding. ## Documentation scope This guide covers the following topics: * [Adding an application](pa_adding_an_app.html) * [Application field descriptions](pa_application_field_descriptions.html) * [Editing an application](pa_editing_an_app.html) * [Deleting an application](pa_deleting_an_app.html) * [Authentication challenge responses](pa_authentication_challenge_responses.html) * [Application resources](pa_application_resources.html) * [Applying extended properties to applications](pa-applying-extended-properties-to-applications.html)