PingFederate Server

CIBA by poll

The OAuth Client Initiated Backchannel Authentication (CIBA) grant by poll process takes place between the client, user, authentication device, PingFederate, and resource server (RS).

After receiving an authentication request acknowledgment, the client starts polling the OpenID Provider (OP)'s token endpoint on a regular interval to obtain the authorization results. When the OP receives the authorization granted by the user through the authentication device, it returns an access token to the client.

Flowchart depicting the CIBA by poll process between the Client, User, Authentication Device, AS/OP and RS.
OAuth CIBA grant by poll

Processing steps

  1. The client sends an authentication request to PingFederate at its client-initiated backchannel authentication endpoint. The client must include in its authentication request the desired scope of permissions and one identity hint for PingFederate to identify the user. When providing an identity hint, the client has three options:

    • login_hint

    • login_hint_token

    • id_token_hint

    The client can include a user code using the user_code parameter in the authentication request, transmit all request parameters of the authentication request in a signed request object, or do both.

  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. The response contains the identifier, auth_req_i, that PingFederate assigns to the authentication request.

  4. The client starts polling PingFederate at its token endpoint to check whether the user has completed the authorization process.

    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.

    For each token request it receives, PingFederate returns a token response. The payload varies depending on the authorization status.

  5. 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.

  6. The authentication device presents the information and works with the user to obtain authorization.

  7. The user reviews the information presented by the authentication device and then approves or denies the scopes requested by the client.

  8. The authentication device sends the authorization result back to PingFederate.

  9. The client continues polling PingFederate for an authorization result.

  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 RS to access protected resources.

  12. The RS validates the access token.

  13. The RS provides the requested data to the client.