PingOne

Triggering an MFA authentication request

After configuring all the basic settings, you are ready to test the initial setup. Trigger an authentication request to verify the configuration.

  • Console

  • API

Triggering an MFA authentication request using the admin console

Steps

  • Make an OpenID Connect (OIDC) request for the web application.

    This evaluates the multi-factor authentication (MFA)-only policy.

    If you trigger the OIDC request through a browser, it invokes the authentication flow’s UI.

    If you set MFA to be the default sign-on policy (the default and only behavior in PingOne MFA), then the admin must go through MFA when signing on to the admin UI, and users will need to go through MFA when signing on to the MyAccount UI.

Next steps

Triggering an MFA authentication request API alternative

Steps

  • To avoid being prompted for a username, provide the user ID in the OIDC request, using the login_hint_token request parameter.

    You will not be asked for a password because the MFA-only policy doesn’t include a sign on step.

    The login_hint_token is a JSON Web Token (JWT) that must be signed using the web app’s Client Secret, which you can find in the app’s Configuration tab. For information on the login_hint_token parameter, see Authorize (Browserless and MFA flows) in the API reference.

    Example:

    The OIDC authentication request looks like the following, where the login_hint_token parameter has been bolded:

    https://auth.pingone.com/{{envId}}/as/authorize?scope=profile&client_id={{webAppId}}&redirect_uri=https://www.example.com&response_type=code&grant_type=authorization_code&login_hint_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkOTA4ODQ3ZC01MzI5LTQxZWEtODAzZi1kN2IyZTBlOTczMTYiLCJzdWIiOiJmNTg0NDFmYy1iZGY3LTRiYjYtODA1OC1iYTkyOGEzM2NhYjEiLCJhdWQiOiJodHRwczovL2F1dGgucGluZ29uZS5jb20vODlmYmNjZjMtMjJlNS00NjhkLTk4OWYtMDI0NzRlMDViNzcxL2FzIn0.c3tJN0pp6yx2xNopozCN83WSEG-h70cJqcYlom63ZQg
  • To trigger browserless authentication, add an additional response_mode parameter with the value set to pi.flow, and then continue the flow, as described in the Flows section of the API reference.

    The only difference in invoking the flow from a backchannel for browserless authentication is the additional response_mode paremeter. Instead of being redirected to the flow’s UI, you get a flow object in the response.

    Example:

    The authentication request looks like the following, where the addition of the response_mode parameter has been bolded at the end of the URL:

    https://auth.pingone.com/{{envId}}/as/authorize?scope=profile&client_id={{webAppId}}&redirect_uri=https://www.example.com&response_type=code&grant_type=authorization_code&login_hint_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJkOTA4ODQ3ZC01MzI5LTQxZWEtODAzZi1kN2IyZTBlOTczMTYiLCJzdWIiOiJmNTg0NDFmYy1iZGY3LTRiYjYtODA1OC1iYTkyOGEzM2NhYjEiLCJhdWQiOiJodHRwczovL2F1dGgucGluZ29uZS5jb20vODlmYmNjZjMtMjJlNS00NjhkLTk4OWYtMDI0NzRlMDViNzcxL2FzIn0.c3tJN0pp6yx2xNopozCN83WSEG-h70cJqcYlom63ZQg&response_mode=pi.flow

Next steps