After receiving an authentication request acknowledgement, the client starts polling the 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.

OAuth CIBA grant by poll

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 and one hint for PingFederate to identify the user. When providing an identity hint, the client has three options: login_hint, login_hint_token, or id_token_hint.

    The client may include a user code (user_code) 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. Among other parameters, the response contains an identifier (auth_req_id) 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 resource server (RS) to access protected resources.
  12. The RS validates the access token.
  13. The RS provides the requested data to the client.