After receiving an authentication request acknowledgement, the client waits for a ping callback message from the OP. When the OP receives the authorization granted by the user through the authentication device, it sends a ping callback message to the client's notification endpoint. The client then sends a token request to retrieve an access token.

OAuth CIBA grant by ping
ClientClientUserUserAuthentication DeviceAuthentication DevicePingFederate AS/OPPingFederate AS/OPRSRS1Authentication request2Identifies the userbased on the hintprovided in the requestand validates the request3Authentication request acknowledgement4Information to obtain authorization5Information to obtain authorization6Authorization grant7Authorization grant8Ping callback9Token request10Access token11Request to access protected resources with the access token12Validates access token13Requested data

Processing steps

  1. The client sends an authentication request to PingFederate (the OP) at its client-initiated backchannel authentication (CIBA) endpoint.

    The client must include in its authentication request the requested scope of permissions, one hint for PingFederate to identify the user, and a bearer token that PingFederate can use to authenticate the ping callback message. When providing an identity hint, the client has three options: login_hint, login_hint_token, or id_token_hint. For the bearer token, the client must follow the syntax as defined in RFC 6750, section 2.1 (tools.ietf.org/html/rfc6750#section-2.1) and transmit it by using the client_notification_token parameter.

    The client may include a user code (user_code), transmit all request parameters of the authentication request in a signed request object, or do both.

    Also per specification and based on mutual agreement, the authentication request can be signed or unsigned.

  2. PingFederate validates the authentication request and identifies the user based on the hint provided by the client.
  3. PingFederate returns an authentication request acknowledgement to the client. Among other parameters, the response contains an identifier (auth_req_id) that PingFederate assigns to the authentication request.
  4. PingFederate invokes a CIBA authenticator based on the applicable CIBA request policy to reach out to the user with the information (for example, the requested scopes) that the user needs to obtain authorization.
  5. The authentication device presents the information and works with the user to obtain authorization.
  6. The user reviews the information presented by the authentication device and then approves (or denies) the scopes requested by the client.
  7. The authentication device sends the authorization result back to PingFederate.
  8. PingFederate sends a ping callback message via the HTTP POST method to the client at its notification endpoint.

    Per specification, PingFederate includes the client_notification_token value in the Authorization HTTP request header and the auth_req_id value in the message body.

  9. The client sends a token request to PingFederate at its token endpoint.

    The client must include in its token request the CIBA grant type (urn:openid:params:grant-type:ciba) and the corresponding auth_req_id value.

  10. PingFederate returns an access token in a token response to the client.

    (If the user denies the requested scopes, PingFederate provides the client with a relevant error message in the token response.)

  11. The client provides the access token to the resource server (RS) to access protected resources.
  12. The RS validates the access token.
  13. The RS provides the requested data to the client.