--- title: Authentication challenge response generator descriptions description: This table describes the challenge response generators you could configure on the New Authentication Challenge Policy page: component: pingaccess version: 9.1 page_id: pingaccess:pingaccess_user_interface_reference_guide:pa_acr_generator_descriptions canonical_url: https://docs.pingidentity.com/pingaccess/9.1/pingaccess_user_interface_reference_guide/pa_acr_generator_descriptions.html revdate: June 15, 2026 section_ids: browser: Browser-handled OIDC Authentication Request device: Device Authorization Challenge device-authorization-grant-flow: Device authorization grant flow html: HTML OIDC Authentication Request ms-ofba: MS-OFBA Authentication Request Redirect oidc: OIDC Authentication Request Redirect pingfed: PingFederate Authentication API Challenge redirect: Redirect Challenge templated: Templated Challenge --- # Authentication challenge response generator descriptions This table describes the challenge response generators you could configure on the **New Authentication Challenge Policy** page: ## **Browser-handled OIDC Authentication Request** Generates an HTML or `302` redirect response as described by the [Authentication challenge responses](pa_authentication_challenge_responses.html) tables when single-page application (SPA) support is disabled. ## **Device Authorization Challenge** Generates a response based on a default HTML template that begins the device authorization grant flow. You can select a response code and modify the template in the [Device authorization challenge ACR generator](pa-managing-acps.html) configuration steps. ### Device authorization grant flow 1. When an unauthenticated user tries to access a protected application or resource associated with this ACP, PingAccess shows them the **Continue on another device** page. This page provides the user with a QR code and continually polls for authentication as described in the [/pa/oidc/deviceAuthzGrantPoll](../reference_guides/pa_oidc_endpoints.html#oidc-deviceAuthz) endpoint reference. 2. The user scans the QR code or enters the associated link into a browser on a secondary device. This link is usually the token provider's **Issuer** field followed by the device authorization grant endpoint. For example, if PingFederate is the token provider, use https\://*\*:*\*/as/user\_authz.oauth2 as the URL. The default PingFederate traffic port is 9031. Learn more in [Port requirements](../installing_and_uninstalling_pingaccess/pa_installation_requirements.html#port-reqs). | | | | - | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | The exact link to the **Connect a device** page depends on the token provider you've configured. You should review your token provider's documentation on device authorization grant types to confirm what link to use. | 3. The token provider prompts the user to authenticate. 4. If the user authenticates successfully, the token provider shows the **Connect a device** page. This page provides the user with a pre-filled **Activation Code** field. 5. The user confirms the **Activation Code**, then clicks **Submit**. 6. The token provider shows an error or confirmation message on the **Connect a device** page. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | If using PingFederate as the token provider, PingFederate presents the user with an expired token error if ten minutes elapse with no response. This is a default value that you can change in the PingFederate configuration. Learn more in [Device authorization grant settings](https://docs.pingidentity.com/pingfederate/latest/administrators_reference_guide/help_authorizationserversettingstasklet_oauthauthorizationserversettingsstate.html#device-authorization-grant-settings). | ## **HTML OIDC Authentication Request** Generates a response with a `401` response code. The response body is an HTML document that automatically issues the OpenID Connect (OIDC) *(tooltip: \
\

An authentication protocol built on top of OAuth that authenticates users and enables clients (relying parties) of all types to request and receive information about authenticated sessions and users. OIDC is extensible, allowing clients to use optional features such as encryption of identity data, discovery of OpenID Providers (OAuth authorization servers), and session management.\

\
)* authentication request using JavaScript. The HTML always attempts to preserve the fragment of the current browser URL and preserves a POST body if the `Content-Type` is `application/x-www-url-formencoded`. ## **MS-OFBA Authentication Request Redirect** Adds two response headers to an HTTP request: * `X-FORMS_BASED_AUTH_REQUIRED` * `X-FORMS_BASED_AUTH_RETURN_URL` This enables you to open Microsoft (MS) Office documents protected by PingAccess in an in-app browser that redirects to the OpenID Provider (OP) *(tooltip: \
\

In OAuth terms, an authorization server (AS). The OP/AS issues access tokens to protected resources for approved clients (relying parties). The clients use the access token to access the protected resources hosted by the OAuth resource server.\

\
)* for user authentication. After the user authenticates, PingAccess establishes a [web session](pa_web_sessions.html) and redirects the user to the corresponding MS Office application (for example, spreadsheets open in MS Excel). | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | This response generator doesn't work with MS Office applications running on macOS, as the macOS in-app browser is much more restrictive. It can't set the nonce cookie that PingAccess requires before redirecting a user.Additionally, Internet Explorer configurations can dictate the behavior of the in-app browser in some environments. If the document you requested fails to download, ensure that **Do not save encrypted pages to disk** is disabled in **Internet Explorer > Internet Options > Advanced > Settings > Security**. | | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | PingAccess provides an MS-OFBA ACP that's configured automatically on initial setup. The **MS-OFBA** challenge response mapping is meant to address edge cases as they come up.Learn more about the system-provided ACP in [MS-OFBA](pa_authentication.html#ms-ofba). | ## **OIDC Authentication Request Redirect** Generates a response with a `302` response code. The response body directs the browser to send an OIDC authentication request to the OP. ## **PingFederate Authentication API Challenge** Generates a response with a `401` response code. The body is a JavaScript Object Notation (JSON) *(tooltip: \
\

An open, lightweight data-interchange format that uses human-readable text to store and transmit data.\

\
)* object that directs the application to connect to the PingFederate redirectless authorization API. The JSON object contains three strings: * authorizationUrl Represents the OIDC authentication request. * method Indicates the HTTP method for the request to the PingAccess OIDC callback endpoint *(tooltip: \
\

One end in a communication channel, typically a URI.\

\
)*. * oidcAuthnResponseEndpoint The location of the PingAccess OIDC callback endpoint. You can find more information about the required PingFederate configuration in [PingFederate authentication API](https://docs.pingidentity.com/pingfederate/latest/developers_reference_guide/pf_authentication_api.html) in the PingFederate documentation. You can find more information about configuring the JavaScript widget to enable this challenge response in the [Redirectless support](https://github.com/pingidentity/pf-authn-js-widget/blob/master/docs/redirectless.md#configuration-object) page on Github. ## **Redirect Challenge** Generates a response with the specified response code that redirects the user to a specified URL. Optionally, select the **Append Redirect Parameters** checkbox to append PingFederate Authentication API parameters and the URL of the protected resource the user tried to access within the query string of the redirect URL you specified. This lets you initiate PingFederate's redirectless OIDC flow from your own sign-on page when an unauthenticated user tries to access a protected resource. The appended parameters are: * authzUrl The OIDC authentication request, similar to `authorizationUrl` from the **PingFederate Authentication API Challenge** response generator. Contains parameters necessary to access the requested resource, such as specific OIDC scopes. * authnResponseMethod The HTTP method used to interact with the PingAccess callback endpoint. For example, `GET`. * resourceUrl The URL of the resource requested by the user. For example, `https://localhost:3000`. * authnResponseEndpoint The PingAccess callback endpoint. For example, `https://localhost:3000/pa/oidc/cb`. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | When **Append Redirect Parameters** is selected, PingAccess provides the information necessary to complete an OIDC flow within the redirect URL's query string, but it doesn't automatically redirect the user to the PingFederate authorization endpoint. As such, this setting is best used with the redirectless [PingFederate authentication API](https://docs.pingidentity.com/pingfederate/latest/developers_reference_guide/pf_authentication_api.html), which reports the current state of an end user's PingFederate authentication policy flow so an external web application can manage authentication requests.Regardless of whether you use the Authentication API, you must send a request to the `authzUrl` to start a redirectless sign-on flow with the credentials entered into your sign-on form. This endpoint returns an OIDC token, which you must send to the `authnResponseEndpoint` using the `authnResponseMethod` so PingAccess can establish a session with the protected resource. After the session is established, you must redirect the user to the `resourceUrl`. | ## **Templated Challenge** Generates a response with the specified response code based on a specified template. Possible template variables include: * *\* (string) The name of the requested application. * *\* (string) The 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.\

\
)* realm associated with the application. If the realm isn't defined by the application, it's assumed to be the requested authority and the application's context root. * *\* (string) Use this variable to add a nonce attribute to any inline JavaScript. * *\* (string) The ID of the current transaction. * *\* (object) The PingFederate OIDC authentication request. Contains parameters necessary to access the requested resource, such as specific OIDC scopes. | | | | - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | Use this variable alongside the following three variables to initiate PingFederate's redirectless OIDC flow from your own sign-on page when an unauthenticated user tries to access a protected resource, as described in the **Redirect Challenge** response table entry. | * *\* (string) The PingAccess callback endpoint, such as `https://localhost:3000/pa/oidc/cb`. * *\* (string) The HTTP method used to interact with the PingAccess callback endpoint, such as `GET`. * *\* (string) The URL of the resource requested by the user, such as `https://localhost: 3000`. * *\* (string) The name of the requested resource.