OpenID Connect (OIDC) supports three login types that define how the user’s identity is verified based on authentication performed by an OpenID Provider (OP)OpenID Provider (OP)OP 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., and how additional profile claims are obtained. Three OIDC sign-on profiles are supported: Code, POST, and x_post.

Login type Description


A standard OIDC login flow that provides confidentiality for sensitive user claims. In this profile the relying party, PingAccess, makes multiple back-channel requests to exchange an authorization code for an ID token. Then PingAccess exchanges an access token for additional profile claims from the UserInfo endpoint at the provider, PingFederate. This login type is for maximum security and standards interoperability.


A login flow that uses the form_post response mode. This flow follows the OAuth 2.0 Form Post Response Mode draft specification. This option requires PingFederate 7.3 or later.

A form auto-POST response containing the ID token, including profile claims, is sent to PingAccess from PingFederate through the browser after authentication. Backchannel communication between PingAccess and PingFederate is required for key management in order to validate ID tokens. This login type is for maximum performance in cases where the exchanged claims do not contain information that should be hidden from the end user.

Select the Implicit grant type when configuring the OAuth Client within PingFederate. For more information, see Configuring a Client. The ID token-signing algorithm in PingFederate must be set to either one of the ECDSA algorithms or one of the RSA algorithms.


A login flow based on OIDC that passes claims from the provider through the browser. Select the Implicit grant type and use either one of the ECDSA algorithms or one of the RSA algorithms as the ID token-signing algorithm.


If you are using PingFederate 7.3 or later in the environment, use POST rather than x_post, which was defined by Ping Identity prior to the development of the OAuth 2.0 Form Post Response Mode draft specification.