The PingOne Authentication API provides services to configure and run authentication workflows. An authentication workflow can be configured to include local authentication actions (login), multi-factor authentication actions, and other external actions. The Authentication API includes the flow orchestration and action services needed to configure an authentication workflow.

PingOne Authentication API model

The PingOne Authentication API includes the following entities.

API Model

Authorization server

The PingOne authorization server (as) service configures the authorization grants that are used to authenticate users and provide access to resources. This service includes the following entities:

For more information, see OpenID Connect/OAuth 2 and Application authorization and authentication.


The PingOne flow orchestration service configures the steps required to authenticate the application or user that initiated the authentication request. The service is responsible for initiating the authentication session and making calls to specific actions required by the authentication workflow.

For more information, see Flows and PingOne flow states.

SAML 2.0

The SAML service provides support for the SAML protocol to authorize clients and allow clients to obtain a requestor’s authentication state. The SAML service implements functions to initiate SAML 2.0 single sign-on and single logout authentication flows.

For more information, see SAML 2.0.

OAuth 2 and OpenID Connect

OpenID Connect is an authentication protocol that PingOne connected applications can use to authenticate users and get user data through claims. PingOne can also act as an OAuth 2 authorization server to authorize clients to access protected resources using access tokens. For example, PingOne uses OAuth 2 to protect access to PingOne management APIs.

The OAuth 2 framework defines several methods by which a client can obtain authorization to access protected resources using an access token. The access token represents authorization granted to the client for a set of scopes. Scopes are string identifiers understood by both the authorization server and the resource server to represent the specific boundaries of access. The client can use the access token as a credential for accessing data on a resource server.

For more information about access tokens, see Access tokens.

SAML 2.0 protocol

The PingOne Authentication API also supports the SAML protocol to authorize clients for data access and allow clients to obtain a requestor’s authentication state. SAML 2.0 uses security tokens, which contain assertions about the requestor, to pass authentication and authorization information about the requestor between the identity provider and the resource provider.

Application connections configured in PingOne that use the SAML protocol must define the following SAML settings in the application connection request:

SAML authorization requests

A SAML authorization request uses the following authorization flow:

  1. The client (browser) initiates a login action to access a protected resource.
  2. The identity provider issues an <AuthnRequest> message to be delivered by the user agent to the SAML service endpoint using either HTTP Redirect or HTTP POST.
  3. The SAML service validates the request and creates an authentication flow with the flow orchestration service.
  4. The SAML service indicates user interaction is required to perform the authentication flow.
  5. The browser is redirected to the PingOne hosted authentication UI or the per application configured URL of a custom UI, passing in the environmentId and flowSessionId query parameters. The authentication UI uses flow orchestration and action services endpoints to complete the authentication flow. The authentication API checks on every call to ensure that the session token cookie contains the current token for the session associated with the flow. On successful completion of the flow, a new session token is generated for the session and set in the cookie.
  6. The browser is redirected to the resume endpoint of the SAML service.
  7. The SAML service retrieves and deletes the authentication flow from the flow orchestration service.
  8. The SAML service generates the appropriate tokens and issues a <Response> message delivered by the user agent to the identity provider using HTTP POST.

The following is a sample SAML assertion generated for an authorization <AuthnRequest> request:

<urn:AuthnRequest ID="hf783f3849f3fh3f34fh8h" IssueInstant="2018-10-12T12:10:14.921-07:00" Version="2.0" xmlns:urn="urn:oasis:names:tc:SAML:2.0:protocol">
    <urn1:Issuer xmlns:urn1="urn:oasis:names:tc:SAML:2.0:assertion">ServiceProvider_7d0a3bfe-3298-47e3-ba42-4a88653b5f5c</urn1:Issuer>

The following is a sample SAML authorization assertion response:

<samlp:Response Destination="" ID="id-628d6ecf-bd0b-4be4-89eb-4979c5d49d28" InResponseTo="hf783f3849f3fh3f34fh8h" IssueInstant="2018-10-22T17:16:19.972Z" Version="2.0" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"></saml:Issuer>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:1.0:cm:bearer">
                <saml:SubjectConfirmationData InResponseTo="hf783f3849f3fh3f34fh8h" NotOnOrAfter="2018-10-22T17:31:19.877Z" Recipient=""/>
        <saml:Conditions NotOnOrAfter="2018-10-22T18:56:20.049Z">
        <saml:AuthnStatement AuthnInstant="2018-10-22T17:16:19.854Z" SessionIndex="c578e632-c61e-461c-96cb-fdf90d630657" SessionNotOnOrAfter="2018-10-22T17:31:19.877Z">
            <saml:Attribute Name="saml_subject" xmlns:xs="">
                <saml:AttributeValue xmlns:xsi="" xsi:type="xs:string">50ba0cd5-8403-4eff-b030-1a80cfea9c75</saml:AttributeValue>
            <saml:Attribute Name="username" xmlns:xs="">
                <saml:AttributeValue xmlns:xsi="" xsi:type="xs:string">samluser</saml:AttributeValue>

For more information about the SAML service, and for details about the single logout flow, see SAML 2.0.